usecallmanagernz / patches

Patches for Asterisk.
GNU General Public License v2.0
37 stars 7 forks source link

Conference hangs after 32 seconds #6

Closed jama00 closed 1 year ago

jama00 commented 1 year ago

Good day! I have Asterisk 18.16.0, patched with 18.15 patch, but it applied without any warnings, so i think it's doesnt matter. And three phones, connected to it - Cisco 7965, 7811 and 8851. debian-pbx*CLI> sip show peers

Name/username Host Dyn Forcerport Comedia ACL Port Status Description 1001/1001 10.0.101.165 D No No 50671 Unmonitored T.T. Testov <-- This is Cisco 7965 1002/1002 10.0.101.155 D No No 49768 Unmonitored Cisco 8851 1003/1003 10.0.101.157 D No No 51500 Unmonitored Cisco 7811 3 sip peers [Monitored: 0 online, 0 offline Unmonitored: 3 online, 0 offline]

It has no issues with generic calls, but when i make conference, it is terminating after 32 sec.

in SIP debug (and pcap) there is a 503 Unavailable error, which replied to this INVITE message from phone:

debian-pbx*CLI> 
[Feb  1 12:46:42] 
[Feb  1 12:46:42] <--- SIP read from TCP:10.0.101.165:50671 --->
[Feb  1 12:46:42] INVITE sip:1003@10.0.100.100:5060;transport=tcp SIP/2.0
[Feb  1 12:46:42] Via: SIP/2.0/TCP 10.0.101.165:50671;branch=z9hG4bK90345392
[Feb  1 12:46:42] From: "T.T. Testov" <sip:1001@10.0.100.100>;tag=10bd18dd03cc0045c1e897b7-8b479685
[Feb  1 12:46:42] To: <sip:1003@10.0.100.100>;tag=as7c34c6d3
[Feb  1 12:46:42] Call-ID: 10bd18dd-03cc000c-9436db0b-9df4f0c1@10.0.101.165
[Feb  1 12:46:42] Max-Forwards: 70
[Feb  1 12:46:42] Date: Wed, 01 Feb 2023 09:46:42 GMT
[Feb  1 12:46:42] CSeq: 103 INVITE
[Feb  1 12:46:42] User-Agent: Cisco-CP7962G/9.3.1
[Feb  1 12:46:42] Contact: <sip:1001@10.0.101.165:50671;user=phone;transport=tcp>
[Feb  1 12:46:42] Authorization: Digest username="1001",realm="asterisk",uri="sip:1003@10.0.100.100;user=phone",response="7c90a9479b9ac4535de6491a85e72d5d",nonce="77b0efef",algorithm=MD5
[Feb  1 12:46:42] Accept: application/sdp
[Feb  1 12:46:42] Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
[Feb  1 12:46:42] Remote-Party-ID: "T.T. Testov" <sip:1001@10.0.100.100>;party=calling;id-type=subscriber;privacy=off;screen=yes
[Feb  1 12:46:42] Call-Info: <urn:x-cisco-remotecc:hold>
[Feb  1 12:46:42] Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.0,X-cisco-xsi-8.5.1
[Feb  1 12:46:42] Allow-Events: dialog
[Feb  1 12:46:42] RTP-RxStat: Dur=1,Pkt=77,Oct=13244,LatePkt=0,LostPkt=0,AvgJit=0,VQMetrics="MLQK=0.0000;MLQKav=0.0000;MLQKmn=0.0000;MLQKmx=0.0000;MLQKvr=0.95;CCR=0.0000;ICR=0.0000;ICRmx=0.0000;CS=2;SCS=1"
[Feb  1 12:46:42] RTP-TxStat: Dur=1,Pkt=4,Oct=688
[Feb  1 12:46:42] Content-Length: 352
[Feb  1 12:46:42] Content-Type: application/sdp
[Feb  1 12:46:42] Content-Disposition: session;handling=optional
[Feb  1 12:46:42] 
[Feb  1 12:46:42] v=0
[Feb  1 12:46:42] o=Cisco-SIPUA 14131 3 IN IP4 10.0.101.165
[Feb  1 12:46:42] s=SIP Call
[Feb  1 12:46:42] t=0 0
[Feb  1 12:46:42] m=audio 28238 RTP/AVP 0 8 18 102 116 101
[Feb  1 12:46:42] c=IN IP4 10.0.101.165
[Feb  1 12:46:42] a=rtpmap:0 PCMU/8000
[Feb  1 12:46:42] a=rtpmap:8 PCMA/8000
[Feb  1 12:46:42] a=rtpmap:18 G729/8000
[Feb  1 12:46:42] a=fmtp:18 annexb=no
[Feb  1 12:46:42] a=rtpmap:102 L16/16000
[Feb  1 12:46:42] a=rtpmap:116 iLBC/8000
[Feb  1 12:46:42] a=fmtp:116 mode=20
[Feb  1 12:46:42] a=rtpmap:101 telephone-event/8000
[Feb  1 12:46:42] a=fmtp:101 0-15
[Feb  1 12:46:42] a=sendonly
[Feb  1 12:46:42] <------------->
debian-pbx*CLI> 
[Feb  1 12:46:42] --- (22 headers 16 lines) ---
[Feb  1 12:46:42] Sending to 10.0.101.165:50671 (no NAT)
[Feb  1 12:46:42] Using INVITE request as basis request - 10bd18dd-03cc000c-9436db0b-9df4f0c1@10.0.101.165
debian-pbx*CLI> 
[Feb  1 12:46:42] NOTICE[118197][C-0000003d]: chan_sip.c:30883 handle_request_invite: Unable to create/find SIP channel for this INVITE
[Feb  1 12:46:42] 
[Feb  1 12:46:42] <--- Reliably Transmitting (no NAT) to 10.0.101.165:50671 --->
[Feb  1 12:46:42] SIP/2.0 503 Unavailable
[Feb  1 12:46:42] Via: SIP/2.0/TCP 10.0.101.165:50671;branch=z9hG4bK90345392;received=10.0.101.165
[Feb  1 12:46:42] From: "T.T. Testov" <sip:1001@10.0.100.100>;tag=10bd18dd03cc0045c1e897b7-8b479685
[Feb  1 12:46:42] To: <sip:1003@10.0.100.100>;tag=as7c34c6d3
[Feb  1 12:46:42] Call-ID: 10bd18dd-03cc000c-9436db0b-9df4f0c1@10.0.101.165
[Feb  1 12:46:42] CSeq: 103 INVITE
[Feb  1 12:46:42] Server: Asterisk PBX 18.16.0
[Feb  1 12:46:42] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Feb  1 12:46:42] Supported: replaces,timer,X-cisco-sis-10.0.0
[Feb  1 12:46:42] Call-Info: <urn:x-cisco-remotecc:callinfo>; orientation=to; security=NotAuthenticated
[Feb  1 12:46:42] Content-Length: 0
[Feb  1 12:46:42] 
[Feb  1 12:46:42] 
[Feb  1 12:46:42] <------------>
[Feb  1 12:46:42] Scheduling destruction of SIP dialog '10bd18dd-03cc000c-9436db0b-9df4f0c1@10.0.101.165' in 32000 ms (Method: INVITE)

The situation is reproduced when organizing a conference from any of the three phones.

sip_debug_cisco_conf_008.txt conf_cisco_sip_008_sip.zip this is the debug log and tcpdump session of this

Is it some issue with INVITE parsing or something other?

gareth-palmer commented 1 year ago

Hello,

The log shows that Asterisk does not think it received a response to the INVITE:

[Feb 1 12:47:13] WARNING[115405]: chan_sip.c:4342 retrans_pkt: Retransmission timeout reached on transmission 10bd18dd-03cc000b-151283d7-aef882e5@10.0.101.165 for seqno 103 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 32000ms with no response [Feb 1 12:47:13] WARNING[115405]: chan_sip.c:4366 retrans_pkt: Hanging up call 10bd18dd-03cc000b-151283d7-aef882e5@10.0.101.165 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).

The phone does send an ACK, but for some reason chan_sip does not match the dialog. You may be able to work-around the issue by setting canreinvite=no on those peers so Asterisk doesn't have to re-INVITE them to change the RTP destinations.

jama00 commented 1 year ago

Hello, this helped, but all RTP is now routed through Asterisk. Is it possible to make directmedia working in this case?

jama00 commented 1 year ago

And also interesting, that reinvites works when there is a direct call, without conferencing. At least, swithing to MOH and back does not belongs to breaking call.

And answering own question, canreinvite=update option (or directmedia=update) resolves this issue. RTPs are routed between phones directly and conferences are working too.

gareth-palmer commented 1 year ago

Thanks for testing that. I will update the site's documentation.