Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

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

Discussion in '3CX Phone System - General' started by Ravaka, Aug 27, 2017.

Thread Status:
Not open for further replies.
  1. Ravaka

    Joined:
    Aug 25, 2017
    Messages:
    10
    Likes Received:
    0
    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 : caller@subdomain.onsip.com
    proxy : @domain.onsip.com

    Callee
    address : 00001@subdomain.3cx.fr
    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.
     

    Attached Files:

  2. Ravaka

    Joined:
    Aug 25, 2017
    Messages:
    10
    Likes Received:
    0
    Does anyone have encoutered this issue ?
     
  3. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,375
    Likes Received:
    84
    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[DirSip:DirectSIP<<"Caller" <sip:caller@subdomain.onsip.com>;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:caller@subdomain.onsip.com>;tag=8ohssgo3ov
    From: "00004"<sip:00004@subdomain.3cx.fr: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.
     
  4. Ravaka

    Joined:
    Aug 25, 2017
    Messages:
    10
    Likes Received:
    0
    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:bnv0o4em@197.149.22.185: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*XXX.XXX.XXX.XXX!5060@199.7.175.102;gr>
    To: "Caller" <sip:caller@subdomain.onsip.com>;tag=143lbr8t2b
    From: "Callee"<sip:00004@subdomain.3cx.fr: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-pwd:D5ERFp9edXXXTy4RtCQec3sdYn
    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:eek:rnp9r5q@197.149.22.185: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*XXX.XXX.XXX.XXX!5060@199.7.175.102;gr>
    To: "Caller" <sip:caller@subdomain.onsip.com>;tag=mvm9tccr72
    From: "Callee"<sip:00004@subdomain.3cx.fr: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]
     
  5. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,375
    Likes Received:
    84
    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.
     
Thread Status:
Not open for further replies.