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

Richard Mudgett (JIRA) noreply at issues.asterisk.org
Fri Sep 16 17:04:01 CDT 2016 

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett updated ASTERISK-26386:
---------------------------------------

    Description: 
per RFC protocol (https://tools.ietf.org/html/rfc3261#page-129) 
the generated ACL 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.

  was:
per RFC protocol (https://tools.ietf.org/html/rfc3261#page-129) 
the generated ACL 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
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
Note contact has a +prefixed above and below ACK generated by the system.
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
this is causing issues with some SIP providers. Complete log is attached.


> 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
>    Affects Versions: 13.11.2
>         Environment: 64bit Linux
>            Reporter: Rajiv Duggal
>         Attachments: sip.log
>
>
> per RFC protocol (https://tools.ietf.org/html/rfc3261#page-129) 
> the generated ACL 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