Pause does not work with SIP device

[Fabien Joseph]

Hello,

I have a problem with the pause on a SIP device (zenitel intercom).

When I use the hold method, the communication continues (video and audio streams).

Additional problem with the pause: the recording of the conversation is not good (random video size and oddly long, ..).

I tested this SIP device with a soft phone (micro sip), i have no problem with the pause.

ASTERISK HISTORY

PAUSE PO INTERPHONE VIA JANUS HISTORY ASTERISK


00000 1665732373 * <== 172.19.31.253:55509      INVITE sip:172.19.31.253:5060 SIP/2.0
00001 1665732373 * ==> 172.19.31.253:55509      SIP/2.0 200 OK
00002 1665732373 * ==> 172.19.31.201:5060       INVITE sip:3...@172.19.31.201:5060 SIP/2.0
00003 1665732373 * <== 172.19.31.253:55509      ACK sip:172.19.31.253:5060 SIP/2.0
00004 1665732373 * <== 172.19.31.201:5060       SIP/2.0 200 OK
00005 1665732373 * ==> 172.19.31.201:5060       ACK sip:3...@172.19.31.201:5060 SIP/2.0
00006 1665732376 * ==> 172.19.31.201:5060       INFO sip:3...@172.19.31.201:5060 SIP/2.0
00007 1665732376 * <== 172.19.31.201:5060       SIP/2.0 200 OK

<--- History Entry 0 Received from 172.19.31.253:55509 at 1665732373 --->
INVITE sip:172.19.31.253:5060 SIP/2.0
Via: SIP/2.0/UDP 172.19.31.253:55509;rport=55509;received=172.19.31.253;branch=z9hG4bK8memarByF925Q
Max-Forwards: 70
From: "201" <sip:2...@172.19.31.253>;tag=tgFQBr5SrXFer
To: <sip:3...@172.19.31.253>;tag=ae5b3684-0eb4-4bb5-95f4-a4746ec7b456
Call-ID: u4czeNmx3xAq4D6XvSEJx3w
CSeq: 968680276 INVITE
Contact: "201" <sip:2...@172.19.31.253:55509;transport=udp>
User-Agent: Janus WebRTC Server SIP Plugin 0.0.8
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, UPDATE, REFER, MESSAGE, INFO, NOTIFY
Supported: replaces
Authorization: Digest username="201", realm="asterisk", nonce="1665732363/3ea8ccc79f6ee67dff0eae7d612054cc", uri="sip:172.19.31.253:5060", response="6dda19d13af9ca15a00ca50090f99313", algorithm=MD5, cnonce="TTtossY0EjuSwAAMKUJ0ig", opaque="0fabf73717a083f3", qop=auth, nc=00000002
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 3916
Content-Type: application/sdp
Content-Length:  3916

v=0
o=- 7317674052724271893 4953460217620044468 IN IP4 172.19.31.253
s=-
t=0 0
m=audio 38446 RTP/AVP 111 63 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 172.19.31.253
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=sendonly
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=rtcp-fb:111 transport-cc
m=video 39272 RTP/AVP 96 102 127 125 108 124 39 45 98 100 123
c=IN IP4 172.19.31.253
a=rtpmap:96 VP8/90000
a=rtpmap:102 H264/90000
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:127 H264/90000
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:125 H264/90000
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:108 H264/90000
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:124 H264/90000
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:39 H264/90000
a=fmtp:39 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=4d001f
a=rtpmap:45 AV1/90000
a=rtpmap:98 VP9/90000
a=fmtp:98 profile-id=0
a=rtpmap:100 VP9/90000
a=fmtp:100 profile-id=2
a=rtpmap:123 H264/90000
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64001f
a=sendonly
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtcp-fb:39 goog-remb
a=rtcp-fb:39 transport-cc
a=rtcp-fb:39 ccm fir
a=rtcp-fb:39 nack
a=rtcp-fb:39 nack pli
a=rtcp-fb:45 goog-remb
a=rtcp-fb:45 transport-cc
a=rtcp-fb:45 ccm fir
a=rtcp-fb:45 nack
a=rtcp-fb:45 nack pli
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli

<--- History Entry 1 Sent to 172.19.31.253:55509 at 1665732373 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.19.31.253:55509;rport=55509;received=172.19.31.253;branch=z9hG4bK8memarByF925Q
Call-ID: u4czeNmx3xAq4D6XvSEJx3w
From: "201" <sip:2...@172.19.31.253>;tag=tgFQBr5SrXFer
To: <sip:3...@172.19.31.253>;tag=ae5b3684-0eb4-4bb5-95f4-a4746ec7b456
CSeq: 968680276 INVITE
Contact: <sip:172.19.31.253:5060>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-16.0.21.18(18.9.0)
Content-Type: application/sdp
Content-Length:   434

v=0
o=- 3199806229 3360004789 IN IP4 172.19.31.253
s=Asterisk
c=IN IP4 172.19.31.253
t=0 0
m=audio 14804 RTP/AVP 9 0 8 126
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:150
a=recvonly
m=video 12060 RTP/AVP 102
a=rtpmap:102 H264/90000
a=fmtp:102 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F
a=recvonly


<--- History Entry 2 Sent to 172.19.31.201:5060 at 1665732373 --->
INVITE sip:3...@172.19.31.201:5060 SIP/2.0
Via: SIP/2.0/UDP 172.19.31.253:5060;rport;branch=z9hG4bKPj6ddc71d3-5057-4f45-95df-fc8834682cf0
From: "po1" <sip:2...@172.19.31.253>;tag=3b0ea6e6-e2b8-45e4-ab71-e99c0a00bdf8
To: <sip:3...@172.19.31.201>;tag=698684101
Contact: <sip:aste...@172.19.31.253:5060>
Call-ID: ac56c47b-b2ec-4386-8cc2-a30e5310e7d7
CSeq: 12202 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: "po1" <sip:2...@172.19.31.253>
Max-Forwards: 70
User-Agent: FPBX-16.0.21.18(18.9.0)
Content-Type: application/sdp
Content-Length:   476

v=0
o=- 965488137 965488138 IN IP4 172.19.31.253
s=Asterisk
c=IN IP4 172.19.31.253
t=0 0
m=audio 17664 RTP/AVP 9 18 0 8 101
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=video 18144 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F
a=sendonly

<--- History Entry 4 Received from 172.19.31.201:5060 at 1665732373 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.19.31.253:5060;rport;branch=z9hG4bKPj6ddc71d3-5057-4f45-95df-fc8834682cf0
From: "po1" <sip:2...@172.19.31.253>;tag=3b0ea6e6-e2b8-45e4-ab71-e99c0a00bdf8
To: "inter2" <sip:3...@172.19.31.201>;tag=698684101
Call-ID: ac56c47b-b2ec-4386-8cc2-a30e5310e7d7
CSeq: 12202 INVITE
Contact: <sip:3...@172.19.31.201:5060>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
Supported: replaces
Content-Length: 401
Content-Type: application/sdp
Content-Length:   401

v=0
o=ZenitelIPSTATIONv6.4.3.2 7873646 8757565 IN IP4 172.19.31.201
s=-
c=IN IP4 172.19.31.201
t=0 0
m=audio 61000 RTP/AVP 9 18 0 8 101
a=sendrecv
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
m=video 65148 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=428014;packetization-mode=0

Thank you for your help.

I tested with version 0.13.0 of janus.

[Lorenzo Miniero]

There's no such thing as "pause" in the SIP plugin. The command to put a call on hold is "hold":

{
    "request" : "hold",
    "direction" : "<sendonly, recvonly or inactive>"
}

The "unhold" request restores the call.

L.

[Lorenzo Miniero]

Apologies, just checked the messages and it looks like it's what you're doing already. Anyway, Janus is doing what it should, since I see a sendonly in the INVITE it sends, and a recvonly in the 200 OK it gets back. It's the other component (FreePBX?) that's generating sendrecv on the other side.

L.

[Lorenzo Miniero]

I've given it some thought, and I think that the fact your B2BUA is negotiating sendrecv on the other side is what's causing this problem: in fact, when we put the call on hold we don't change our checks on whether we should send or receive media (we blindly trusted the endpoints).

I've prepared a quick PR that should fix this: https://github.com/meetecho/janus-gateway/pull/3087

Please test that branch and let me know if it fixes the problem for you. Please also let us know if it causes anything else to break though, as I haven't tested this yet.

L.

[Lorenzo Miniero]

Fabien, have you tested the proposed fix?

Thanks,

L.

[Lorenzo Miniero]

I wonder why people even bother asking things if they don't care about the answer.

L.

[Fabien Joseph]

hello,

I hadn't seen your answers.

 I will test your fix.

Thanks,

Fabien

[Fabien Joseph]

Hello Lorenzo,

I tested your fix.

With your fix, if I do not activate the recording (janus), I have the audio and video which are cut during my sip hold. And when I resume, I have the video and the audio again, so your fix works for me.

On the other hand, if I activate the recording (janus).

I just use your method recording to start at the beginning of the call.

var body_record = {
                                    request: "recording",
                                        "action": "start",
                                        "audio": true,
                                        "video": true,
                                        "peer_audio": true,
                                        "peer_video": true,
                                         "filename": "/opt/janus/share/janus/siprec/"+sipRecordId
                                      };
                                      Janus.debug("Record", body_record);
                                      sipcall.send({
                                        "message": body_record,
                                        "jsep": jsep
                                      });

Audio and video live chats seem to cut out.

But when I watch recorded videos and recorded audio, the videos and audio seem to continue during my pause.

Thank you for your help.