[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=232571#comment-232571 ] 

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

Hi there,

I think you've been reading the wrong section of RFC3261.

Check out this bit:
{quote}
17.1.1.3 Construction of the ACK Request

   This section specifies the construction of ACK requests sent within
   the client transaction.  A UAC core that generates an ACK for 2xx
   MUST instead follow the rules described in Section 13.
{quote}

The ACK we're dealing with here is an ACK to a 200, not to a final non-2xx.

For ACKs to final 2xx: R-URI = Contact of 2xx \(*)
For ACKs to final non-2xx: R-URI = original R-URI (where you were reading)

\(*)
{quote}
The UAC core MUST generate an ACK request for each 2xx received from
the transaction layer.  The header fields of the ACK are constructed
in the same way as for any request sent within a dialog (see Section
12) \(**)
{quote}
\(**)
{quote}
   The UAC uses the remote target and route set to build the Request-URI
   and Route header field of the request.

etc.. etc.. etc..
{quote}

I see no issue here.

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