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

[Rajiv Duggal (JIRA)]

Rajiv Duggal created ASTERISK-26386:
---------------------------------------

             Summary: CK 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


er 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)