[asterisk-bugs] [JIRA] (ASTERISK-26386) chan_sip: ACK being sent is referencing the contact on the Request-URI instead of To

[Walter Doekes (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232724#comment-232724 ] 

Walter Doekes commented on ASTERISK-26386:
------------------------------------------

(1) You originally described a problem with the ACK being sent to the wrong place, and then you've captured an *inbound* call, where Asterisk doesn't need to send any ACK (call_18886789208_form_cell_works.txt) -- Asterisk is the UAS for both transactions in that call...
(2) Call setup/teardown appears fine in call_18886789208_from_int_silence.txt
(3) As the SIP seems fine, your problem is probably SDP/RTP related, but call_18886789208_from_int_silence.txt is missing lots of SDP info, particularly *all* SDP from  65.254.44.194. Because you used grep -C10 on the logs instead of the tcpdump filters: tcpdump -r allcaptured.pcap -nnvls0 host 65.254.44.194
(4) If the call stays silent, you should attempt to debug with 'rtp set debug on' and 'sip set debug on' in the asterisk console. Those two should show enough (assuming your logger.conf settings are set up properly).

In short:
- as you've said yourself: these dumps have nothing to do with the original problem you've described
- the routing appears just fine, if there is anything you should look at, it would be RTP flow startup or lack thereof (wrong IPs? or both parties waiting for the other to start sending? or NAT issues?)

Closing out as not-a-bug. Support can be found in other places like the forum or the asterisk-users list.

Good luck!

> chan_sip: ACK being sent is referencing the contact on the Request-URI instead of To
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26386
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26386
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Channels/chan_sip/Interoperability
>    Affects Versions: 13.2.0
>         Environment: 64bit Linux
>            Reporter: Rajiv Duggal
>            Assignee: Unassigned
>         Attachments: call_18886789208_form_cell_works.txt, call_18886789208_from_int_silence.txt, sip.log
>
>
> per RFC protocol (https://tools.ietf.org/html/rfc3261#page-129) 
> the generated ACK should use the TO from the response being acknowledged
> This is causing call disconnects and continuous invites from some SIP providers who receive a contact from upstream which is not identical to the TO part of the header.
> This can be replicated for phone # 15033277805.
> received header per below
> {noformat}
> 17:03:36.856392 IP (tos 0x0, ttl 53, id 37874, offset 0, flags [none], proto UDP (17), length 1057)
> 65.254.44.194.sip > 10.2.1.40.sip-tls: [udp sum ok] SIP, length: 1029
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 100.32.192.11:5061;received=100.32.192.11;branch=z9hG4bK3da029f8;rport=5061
> From: <sip:8053881711 at gw1.sip.us:5061>;tag=as28725f49
> To: <sip:15033277805 at gw1.sip.us:5060>;tag=gK0ce47da4
> Call-ID: 0e760a970d24e31e22afca333f10989e at gw1.sip.us
> CSeq: 103 INVITE
> Record-Route: <sip:67.231.0.87:5060;lr=on;ftag=as28725f49>
> Record-Route: <sip:65.254.44.194:5060;lr=on;ftag=as28725f49;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADo1MDYx;proxy_media=yes;dlgcor=018.b1f>
> Accept: application/sdp
> Contact: <sip:+15033277805 at 192.168.16.8:5060>
> Allow: INVITE,ACK,CANCEL,BYE,REFER,PRACK,OPTIONS
> Supported: timer
> Session-Expires: 1800;refresher=uas
> Content-Length: 258
> Content-Disposition: session; handling=required
> Content-Type: application/sdp
> {noformat}
> Note contact has a +prefixed above and below ACK generated by the system.
> {noformat}
> 17:03:36.857085 IP (tos 0x60, ttl 64, id 26156, offset 0, flags [none], proto UDP (17), length 629)
> 10.2.1.40.sip-tls > 65.254.44.194.sip: [udp sum ok] SIP, length: 601
> ACK sip:+15033277805 at 192.168.16.8:5060 SIP/2.0
> Via: SIP/2.0/UDP 100.32.192.11:5061;branch=z9hG4bK148ab810;rport
> Route: <sip:65.254.44.194:5060;lr=on;ftag=as28725f49;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADo1MDYx
> ;proxy_media=yes;dlgcor=018.b1f>,<sip:67.231.0.87:5060;lr=on;ftag=as28725f49>
> Max-Forwards: 70
> From: <sip:8053881711 at gw1.sip.us:5061>;tag=as28725f49
> To: <sip:15033277805 at gw1.sip.us:5060>;tag=gK0ce47da4
> Contact: <sip:8053881711 at 100.32.192.11:5061>
> Call-ID: 0e760a970d24e31e22afca333f10989e at gw1.sip.us
> CSeq: 103 ACK
> User-Agent: FPBX-AsteriskNOW-12.0.76.4(13.2.0)
> Content-Length: 0
> {noformat}
> this is causing issues with some SIP providers. Complete log is attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)