BUG??? Call Queues + "Record all calls" option checked result in a call dropped

[Ravaka]

Hi Community,

Currently we are testing the following topology that works fine, ONLY IF the option *Record all calls* remain unchecked on Call Queue Agents.

-- Softwares used

Firefox v55.0.3 (32 bits)
SIPjs v0.78
3CX Phone System Professional Edition v15.0.0
3CXPhone for Windows v15.5.3849.1

-- Call Topology (DirectSIP)

Caller (from SIPjs running Firefox)
address : [email protected]
proxy : @domain.onsip.com

Callee
address : [email protected]
proxy : @subdomain.3cx.fr

--- Call Queue

Extension : 80000
polling strategy : Prioritized Hunt
Agents : 00004 and 00003

-- Agents Status

00001 is unregistered, and all forwarding rules set to: forward to Extension 80000 Call Queues
00004 Current Status : Avalaible, Queues Status : LoggedIn
00003 Current Status : Avalaible, Queues Status : LoggedIn

-- Test 1 : *Record all calls* is unchecked for ext. 00004

>>> Call is successfully forwarded to 00004
>>> When 00004 pick up ringing phone as audio (and enable video during session), Re-INVITE is succesfully received by SIPjs
>>> No problem, all is ok (audio, video)

-- Test 2 : *Record all calls* is checked for ext. 00004

>>> Call is successfully forwarded to 00004
>>> When 00004 pick up ringing phone as audio, call is dropped after 1 second
>>> Web Page return errors:
>>> DOMException [InvalidSessionDescriptionError: "New remote description has fewer m-sections than the previous remote description."
code: 0
nsresult: 0x0

By comparing remote SDP (on Firefox debug about:webrtc) on both test1 and test 2, we noticed that remote SDP has changed on test 2 when *Record all calls* is checked so it creates the bug.

If you need more details on remote SDP, please check attached 3cx PS activity log file (please read file content from bottom to up).


-- QUESTION

We want *Record all calls* enabled on all our Call Queues Agents, so what would be the workaround to make both Call Forwarding and Record All Calls working together on audio and video call ?

Thanks for helping answers.

 

[Ravaka]

Does anyone have encoutered this issue ?

 

[NickD_3CX]

I tried this scenario with IP Phones, not with SIP.js and it worked OK even with recordings enabled.

I believe this might have something to do with the fact that when you enabled recordings, the PBX must be able to decode the audio so the codec being used must be supported by 3CX. The reason why the call though is being dropped in the case where recording are enabled is that in this message:

08/27/2017 7:17:46 PM - Offer is rejected on Leg L:603.1[DirSipirectSIP<<"Caller" <sip:[email protected]>;tag=8ohssgo3ov];
OnOfferRejected Recv 488/INVITE from 199.7.175.102:5060 tid=363ad66616218d64 Call-ID=t5qir744pmfqfeqqkj9c:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bK-524287-1---363ad66616218d64;rport=5060
To: "Caller" <sip:[email protected]>;tag=8ohssgo3ov
From: "00004"<sip:[email protected]:5060>;tag=701fdb07
Call-ID: t5qir744pmfqfeqqkj9c
CSeq: 2 INVITE
Supported: outbound
User-Agent: SIP.js/0.7.8
P-NS: 1
Content-Length: 0

Usually endpoints reject INVITE messages with 488 when they don't have a common codec they can use, and I ma guessing that is what is changing when you enable the recordings, the codecs that 3CX sends to the endpoint.

 

[Ravaka]

Thanks for your answer

I think it is not a codec problem, It is something else that Firefox does not like.

When comparing the two INVITES for both test cases, we notice that some media descriptions are permuted or missing

like audio connection line (c=) and video lines.

Here are the INVITE messages received from 3cx when call is forwarded on both case (RECORD ALL CALLS IS UNCHECKED and RECORD ALL CALLS IS CHECKED)

*** TEST 1 : CALL FORWARDED, RECORD ALL CALLS IS UNCHECKED ****
(this are SIP messages from the moment the 3cx phone start ringing)

INVITE (received from 3cx) --------------------------------------------------------------------------------------------

INVITE sip:[email protected]:6136;transport=wss;ob;nat=yes SIP/2.0
Record-Route: <sip:199.7.175.182:443;transport=wss;r2=on;lr;ftag=eb773576>
Record-Route: <sip:199.7.175.182;r2=on;lr;ftag=eb773576>
Record-Route: <sip:199.7.175.102;lr;ftag=eb773576;did=a64.9b063e71;ns=1;pr=3;pr=3>
Via: SIP/2.0/WSS 199.7.175.182:443;branch=z9hG4bKe943.d240d1a1.0
Via: SIP/2.0/UDP 199.7.175.102:5060;rport=5060;received=199.7.175.102;branch=z9hG4bKe943.a8ccd1a5.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bK-524287-1---4b6f9a702d4d1c63;rport=5060
Max-Forwards: 68
Contact: <sip:00004*[email protected];gr>
To: "Caller" <sip:[email protected]>;tag=143lbr8t2b
From: "Callee"<sip:[email protected]:5060>;tag=eb773576
Call-ID: hhc9rcu9mr38i3hclmps
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CXPhoneSystem 15.0.62928.5 (62293)
Content-Length: 809
v=0
o=3cxPS 540092137472 189599318018 IN IP4 XXX.XXX.XXX.XXX
s=3cxPS Audio call
c=IN IP4 XXX.XXX.XXX.XXX
b=AS:84
t=0 0
a=X-nat:0
m=audio 56232 UDP/TLS/RTP/SAVPF 0 8 18 3 9 96
c=IN IP4 199.7.175.74
b=TIAS:64000
b=AS:84
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=rtcp:56233
a=rtcp-mux
a=setup:actpass
a=fingerprint:sha-1 03:92:4F:B2:3B:A3:F4:8E:A9:A8:9A:3F:17:64:23:40:CF:90:A7:AE
a=ice-ufrag:1WUCtsgS
a=ice-pwd5ERFp9edXXXTy4RtCQec3sdYn
a=candidate:mUdYRUCdN5eiZ04K 1 UDP 2130706431 199.7.175.74 56232 typ host
a=candidate:mUdYRUCdN5eiZ04K 2 UDP 2130706430 199.7.175.74 56233 typ host
m=video 0 UDP/TLS/RTP/SAVPF 31
c=IN IP4 199.7.175.74


**** TEST 2 : CALL FORWARDED, RECORD ALL CALLS IS CHECKED ***
(this are SIP messages from the moment the 3cx phone start ringing)

INVITE (received from 3cx) --------------------------------------------------------------------------------------------

INVITE sip[email protected]:6039;transport=wss;ob;nat=yes SIP/2.0
Record-Route: <sip:199.7.175.182:443;transport=wss;r2=on;lr;ftag=a400db45>
Record-Route: <sip:199.7.175.182;r2=on;lr;ftag=a400db45>
Record-Route: <sip:199.7.175.102;lr;ftag=a400db45;did=c4a.e9273df3;ns=1;pr=3;pr=3>
Via: SIP/2.0/WSS 199.7.175.182:443;branch=z9hG4bK08ab.fc483bd.0
Via: SIP/2.0/UDP 199.7.175.102:5060;rport=5060;received=199.7.175.102;branch=z9hG4bK08ab.b08bada5.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bK-524287-1---e5090377b940206c;rport=5060
Max-Forwards: 68
Contact: <sip:00004*[email protected];gr>
To: "Caller" <sip:[email protected]>;tag=mvm9tccr72
From: "Callee"<sip:[email protected]:5060>;tag=a400db45
Call-ID: 3aopdi778o49fp2424do
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CXPhoneSystem 15.0.62928.5 (62293)
Content-Length: 619
v=0
o=3cxPS 247430381568 408005115905 IN IP4 XXX.XXX.XXX.XXX
s=3cxPS Audio call
c=IN IP4 199.7.175.74
t=0 0
m=audio 56042 UDP/TLS/RTP/SAVPF 9 0 8 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:56043
a=rtcp-mux
a=setup:actpass
a=fingerprint:sha-1 03:92:4F:B2:3B:A3:F4:8E:A9:A8:9A:3F:17:64:23:40:CF:90:A7:AE
a=ice-ufrag:rFyZb8wh
a=ice-pwd:TDCrSy41uHdFltcdRS4SGap6NY
a=candidate:mUdYRUCdN5eiZ04K 1 UDP 2130706431 199.7.175.74 56042 typ host
a=candidate:mUdYRUCdN5eiZ04K 2 UDP 2130706430 199.7.175.74 56043 typ host

By comparing the 2 INVITEs, we notice the following changes :

1. first connection line IP has changed (c=)

c=IN IP4 XXX.XXX.XXX.XXX ==> c=IN IP4 199.7.175.74 ???

2. audio connection line was not found (no c= under media line)

m=audio 56232 UDP/TLS/RTP/SAVPF 0 8 18 3 9 96 ===> m=audio 56042 UDP/TLS/RTP/SAVPF 9 0 8 101
c=IN IP4 199.7.175.74 ===> ???

3. video lines was removed

m=video 0 UDP/TLS/RTP/SAVPF 31 ===> ???
c=IN IP4 199.7.175.74 ===> ???


RESULT :

DOMException [InvalidSessionDescriptionError: "New remote description has fewer m-sections than the previous remote description."
code: 0
nsresult: 0x0]

 

[NickD_3CX]

That is what I was explaining, without recording checked 3CX just passes on the SDP information as is, think like 'pass-through' mode regardless whether it supports the SDP values or not that it received initially because it does not need to decode them.
When recordings are checked, because 3CX has to decode the audio to imprint onto the file, when forwarding the SDP information to the Queue Agent, it sends the SDP values it supports and knows.

As mentioned though, to be sure I tested this with supported endpoints and it seems to work fine.