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

Tue Oct 11 11:49:01 CDT 2016

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

Rajiv Duggal commented on ASTERISK-26386:
-----------------------------------------

Hi Walter,

I am sorry if my analysis caused you grief. I am trying to bridge the gap between what my sip provider is doing and way asterisk 11 vs 13 is working. Intention was to dive into details to uncover bug that if fixed will help the community.
I am not stating that the contact header should not be used, just that it plays a role where a dialog is setup and established.

I do thank you for the details you have provided and I have sent the information to my provider for final response on this issue. I believe they are also waiting on access to JIRA account, provider being SIP.US. I am trying to drive consensus between the 2 teams.

My opinion is that sip.us is changing the contact in when it should not be changed. The next question was should that be non-consequential because its value should not be referenced as it is not a target refresh request. At the end of the day it seems to work with Asterisk11 but not 13 that leads me to believe something more is happening.

You reasoning is well received and I would like to come back with a reasoning  as applicable. Again the intention is not to contradict you.

thanks.
Rajiv

. 

> 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)