[asterisk-bugs] [JIRA] (ASTERISK-23313) ACK sent to wrong destination in CANCEL dialog
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Sun Feb 16 18:39:03 CST 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-23313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215280#comment-215280 ]
Matt Jordan commented on ASTERISK-23313:
----------------------------------------
The problem is, your endpoint changed the Contact address in the 183:
{noformat}
[2014-02-14 13:05:45] VERBOSE[2013] chan_sip.c:
�<--- SIP read from UDP:64.2.142.93:5060 --->
�SIP/2.0 183 Session Progress
�Via: SIP/2.0/UDP 108.244.232.196:5060;rport=5060;received=108.244.232.196;branch=z9hG4bK0deea205
�Record-Route: <sip:64.2.142.93;lr=on>
�From: "BORRELLINET IT L1" <sip:8609150274 at 108.244.232.196>;tag=as7cabff0c
�To: <sip:12032649261 at 64.2.142.93>;tag=as10ab2210
�Call-ID: 461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060
�CSeq: 102 INVITE
�User-Agent: packetrino
�Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
�Supported: replaces
�Contact: <sip:12032649261 at 66.241.96.140>
�Content-Type: application/sdp
�Content-Length: 242
�
�v=0
�o=root 24046 24046 IN IP4 66.241.96.140
�s=session
�c=IN IP4 66.241.96.140
�t=0 0
�m=audio 19450 RTP/AVP 0 101
�a=rtpmap:0 PCMU/8000
�a=rtpmap:101 telephone-event/8000
�a=fmtp:101 0-16
�a=silenceSupp:off - - - -
�a=ptime:20
�a=sendrecv
�<------------->
{noformat}
Note the Contact header there is the 62.2.142.93 address, not the address that the INVITE request was sent to. This makes things ... weird.
>From Section 8.1.1.8:
{quote}
8.1.1.8 Contact
The Contact header field provides a SIP or SIPS URI that can be used
to contact that specific instance of the UA for subsequent requests.
The Contact header field MUST be present and contain exactly one SIP
or SIPS URI in any request that can result in the establishment of a
dialog. For the methods defined in this specification, that includes
only the INVITE request. For these requests, the scope of the
Contact is global. That is, the Contact header field value contains
the URI at which the UA would like to receive requests, and this URI
MUST be valid even if used in subsequent requests outside of any
dialogs.
{quote}
This makes everything very confusing. Your proxy has informed Asterisk that it wants to be contacted at {{sip:12032649261 at 66.241.96.140}}.
So, what takes precedence - the INVITE request line, or what the proxy told us to send to in the 1xx provisional response?
In this case, I still think Asterisk is doing the right thing.
# The ACK request is sent to the URI specified in the provisional response.
# However, the ACK request is transmitted to the IP address and port that the INVITE request was sent to. Note that this is inline with 17.1.1.2, which - in full context - states:
{quote}
The client transaction
MUST pass the received response up to the TU, and the client
transaction MUST generate an ACK request, even if the transport is
reliable (guidelines for constructing the ACK from the response are
given in Section 17.1.1.3) and then pass the ACK to the transport
layer for transmission. The ACK MUST be sent to the same address,
port, and transport to which the original request was sent.
{quote}
Note that this is referring to the transport layer - and Asterisk did, in fact, send the ACK request to the correct IP address and port number (even if the request line includes the URI specified by your proxy).
Even *if* there was a bug here in Asterisk, this could probably be easily solved by your proxy not telling Asterisk to contact it at the RTP media address.
> ACK sent to wrong destination in CANCEL dialog
> ----------------------------------------------
>
> Key: ASTERISK-23313
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-23313
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General
> Affects Versions: 11.7.0
> Environment: FreePBX 2.11.0.23, CentOS 6.5 (2.6.32-431.el6.i686), Asterisk 11.7.0
> Reporter: Gregory J Borrelli
> Assignee: Matt Jordan
> Severity: Critical
> Attachments: ack_issue.pcap, asterisk_debug_log.txt, sip_only.txt
>
>
> I've run into an issue that appears to be a bug within Asterisk. The issue surfaces when interfacing with a SIP trunk provider that uses different servers for SIP/signaling and RTP/media. I've tested against two different providers that have this type of setup and was able to consistently reproduce the problem every time.
> The issue occurs when an extension on the Asterisk box makes an external call and then hangs up during the ring phase (originator cancel). All goes as expected until the very last exchange... Provider's proxy sends "487 Request Terminated" to Asterisk. It appears that Asterisk knows it’s supposed to send the ACK back to the proxy, and from a network routing perspective the packet does get sent there, but when actually constructing the ACK statement in the SIP dialog it uses the wrong IP (the IP of the provider's media server rather than the proxy server).
> As per RFC 3261, Section 17.1.1.2:
> "...reception of a response with status code from 300-699 MUST cause the client transaction to transition to "Completed." ... and the client transaction must generate an ACK request ... The ACK MUST be sent to the same address, port, and transport to which the original request was sent."
> So it appears that asterisk is not following protocol here.
> I've pasted the relevant parts of the SIP dialog and asterisk logs below for quick reference and will attach the full files as well. Let me know if any additional information is needed.
> SIP DIALOG:
> {noformat}
> SIP/2.0 487 Request Terminated
> Via: SIP/2.0/UDP 108.244.232.196:5060;rport=5060;received=108.244.232.196;branch=z9hG4bK0deea205
> From: "BORRELLINET IT L1" <sip:8609150274 at 108.244.232.196>;tag=as7cabff0c
> To: <sip:12032649261 at 64.2.142.93>;tag=as10ab2210
> Call-ID: 461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060
> CSeq: 102 INVITE
> User-Agent: packetrino
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> Supported: replaces
> Content-Length: 0
> ACK sip:12032649261 at 66.241.96.140 SIP/2.0
> Via: SIP/2.0/UDP 108.244.232.196:5060;branch=z9hG4bK0deea205
> Max-Forwards: 70
> From: "BORRELLINET IT L1" <sip:8609150274 at 108.244.232.196>;tag=as7cabff0c
> To: <sip:12032649261 at 64.2.142.93>;tag=as10ab2210
> Contact: <sip:8609150274 at 108.244.232.196:5060>
> Call-ID: 461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060
> CSeq: 102 ACK
> User-Agent: FPBX-2.11.0(11.7.0)
> Content-Length: 0
> {noformat}
> ASTERISK DEBUG LOG:
> {noformat}
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 0 [ 30]: SIP/2.0 487 Request Terminated
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 1 [ 96]: Via: SIP/2.0/UDP 108.244.232.196:5060;rport=5060;received=108.244.232.196;branch=z9hG4bK0deea205
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 2 [ 73]: From: "BORRELLINET IT L1" <sip:8609150274 at 108.244.232.196>;tag=as7cabff0c
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 3 [ 48]: To: <sip:12032649261 at 64.2.142.93>;tag=as10ab2210
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 4 [ 62]: Call-ID: 461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 5 [ 16]: CSeq: 102 INVITE
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 6 [ 22]: User-Agent: packetrino
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 7 [ 72]: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 8 [ 19]: Supported: replaces
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: Header 9 [ 17]: Content-Length: 0
> [2014-02-14 13:05:58] VERBOSE[2013] chan_sip.c: --- (10 headers 0 lines) ---
> [2014-02-14 13:05:58] DEBUG[2013] chan_sip.c: = Looking for Call ID: 461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060 (Checking To) --From tag as7cabff0c --To-tag as10ab2210
> [2014-02-14 13:05:58] DEBUG[2013][C-000000f4] chan_sip.c: Stopping retransmission on '461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060' of Request 102: Match Found
> [2014-02-14 13:05:58] DEBUG[2013][C-000000f4] chan_sip.c: SIP response 487 to standard invite
> [2014-02-14 13:05:58] VERBOSE[2013][C-000000f4] chan_sip.c: Transmitting (no NAT) to 64.2.142.93:5060:
> ÿACK sip:12032649261 at 66.241.96.140 SIP/2.0
> ÿVia: SIP/2.0/UDP 108.244.232.196:5060;branch=z9hG4bK0deea205
> ÿMax-Forwards: 70
> ÿFrom: "BORRELLINET IT L1" <sip:8609150274 at 108.244.232.196>;tag=as7cabff0c
> ÿTo: <sip:12032649261 at 64.2.142.93>;tag=as10ab2210
> ÿContact: <sip:8609150274 at 108.244.232.196:5060>
> ÿCall-ID: 461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060
> ÿCSeq: 102 ACK
> ÿUser-Agent: FPBX-2.11.0(11.7.0)
> ÿContent-Length: 0
> ÿ
> ÿ
> ÿ---
> [2014-02-14 13:05:58] DEBUG[2013][C-000000f4] chan_sip.c: Trying to put 'ACK sip:120' onto UDP socket destined for 64.2.142.93:5060
> [2014-02-14 13:05:58] DEBUG[2013][C-000000f4] chan_sip.c: Updating call counter for outgoing call
> [2014-02-14 13:05:58] VERBOSE[2013][C-000000f4] chan_sip.c: Scheduling destruction of SIP dialog '461c637f587aa81f64b6316c73e221fe at 108.244.232.196:5060' in 6400 ms (Method: INVITE)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list