[asterisk-bugs] [JIRA] (ASTERISK-26386) chan_sip: ACK being sent is referencing the contact on the Request-URI instead of To
Rajiv Duggal (JIRA)
noreply at issues.asterisk.org
Mon Oct 10 17:14:01 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232632#comment-232632 ]
Rajiv Duggal commented on ASTERISK-26386:
-----------------------------------------
Adding more detail per above - see Section 12) (**)
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
2) RFC states per below
--------start of reference----------------
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.
If the route set is not empty, and its first URI does not contain the
lr parameter, the UAC MUST place the first URI from the route set
into the Request-URI, stripping any parameters that are not allowed
in a Request-URI. The UAC MUST add a Route header field containing
the remainder of the route set values in order, including all
parameters. The UAC MUST then place the remote target URI into the
Route header field as the last value.
--------------end reference-----------
thereby In our case the request URI should have returned from remote target rather than the contact.
below are the packets in questions
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
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
> 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: Rajiv Duggal
> 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