[asterisk-bugs] [JIRA] (ASTERISK-26386) chan_sip: ACK being sent is referencing the contact on the Request-URI instead of To
Walter Doekes (JIRA)
noreply at issues.asterisk.org
Wed Oct 12 11:21:01 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232676#comment-232676 ]
Walter Doekes edited comment on ASTERISK-26386 at 10/12/16 11:19 AM:
---------------------------------------------------------------------
Good! Now that we agree that updating the R-URI to the Contact is correct in regular cases, we can move on to your specific issue.
Normally, I would say that this is a support problem that doesn't belong in the issue tracker, but as you say, it apparently behaves differently between Asterisk 11 and 13. That makes me curious enough to find out more.
Can you get us the following:
- a SIP trace of a good call setup (Asterisk 11): including the INVITE, 1xx, 200, ACK, BYE and 200
- a SIP trace of a failing call setup (Asterisk 13): including the INVITE, 1xx, 200, ACK, BYE and 200 (or at least, all packets that are available) and all packets that are duplicated
- the chan_sip config you use for these calls (the device config + relevant general config; passwords and usernames scrubbed of course); using any outboundproxy? nat config? externip/externhost? check the settings in in [general] too
- the Dial-string from your extensions.conf; using an outboundproxy in that string?
Scrub as little as possible, but if you do scrub any details, make sure the replacements don't drop information (e.g. if you replace an IP, replace it everywhere with the same unique identifier).
If possible, get the SIP traces on the outermost router. I think the contact with 192.168.16.8 looks awfully suspicious. And I wonder if there isn't simply some ALG on the way messing things up for you.
was (Author: wdoekes):
Good! Now that we agree that updating the R-URI to the Contact is correct in regular cases, we can move on to your specific issue.
Normally, I would say that this is a support problem that doesn't belong in the issue tracker, but as you say, it apparently behaves differently between Asterisk 11 and 13. That makes me curious enough to find out more.
Can you get us the following:
- a SIP trace of a good call setup (Asterisk 11): including the INVITE, 1xx, 200, ACK, BYE and 200
- a SIP trace of a failing call setup (Asterisk 13): including the INVITE, 1xx, 200, ACK, BYE and 200 (or at least, all packets that are available) and all packets that are duplicated
- the chan_sip config you use for these calls (the device config + relevant general config; passwords and usernames scrubbed of course); using any outboundproxy? nat config? externip/externhost? check the settings in in [general] too
- the Dial-string; using an outboundproxy in that string?
Scrub as little as possible, but if you do scrub any details, make sure the replacements don't drop information (e.g. if you replace an IP, replace it everywhere with the same unique identifier).
If possible, get the SIP traces on the outermost router. I think the contact with 192.168.16.8 looks awfully suspicious. And I wonder if there isn't simply some ALG on the way messing things up for you.
> 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: 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)
More information about the asterisk-bugs
mailing list