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

Tue Oct 11 01:11:01 CDT 2016

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

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

This is getting ridiculous.

{quote}
I would note that per RFC 3261 ss 12.2.1.1 which is what you ultimately refer to 
1)When a UAC receives a 2xx response to a target refresh request, it
MUST replace the dialog's remote target URI with the URI from the
Contact header field in that response, if present.
The issue here is that the contact header being used is not a target refresh request hence it should not change the request URI
{quote}

You're good at finding the wrong bits of RFC to quote.

I said/quoted:
{quote}
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the *remote target* URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including all
parameters.
{quote}

If you ctrl-F the RFC for *remote target* you'll find this:
{quote}
12.1.2 UAC Behavior
...
   requests in this dialog.  The remote target MUST be set to the URI
   from the Contact header field of the response.
{quote}

I don't see how you'd miss that, unless you intentionally skip the parts that disprove your own theory.

But, here, let me point to an example:
https://tools.ietf.org/html/rfc3261#section-16.12.1.1

It says:
{quote}
   The callee at u2 also sets its dialog state's remote target URI to
   sip:caller at u1.example.com and its route set to:
{quote}
That remote target is taken from the Contact from the earlier 200.

Further, if what you say is true -- that the Contact should not be used -- all of my installations with opensips/kamailio proxies using loose_route() would break down. Without a Contact, the proxies would have no idea where to route the ACK and the BYE, because the transactions would contain no mention of the UAS behind the proxy.

It's certainly possible that you have a problem with loose-routing somewhere and that packets are refused for one reason or the other. But your theory that Asterisk should not use the Contact for R-URI is wrong. If you do have an issue, you should pursue a different avenue of investigation; probably starting with the evidence that you do have, and not with snippets of RFC and wild accusations.

I'm done here.
https://xkcd.com/386/

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