[Home]

Summary:ASTERISK-26386: No audio when calling from Asterisk through sip.us and back in
Reporter:Rajiv Duggal (rduggal@dex.com)Labels:
Date Opened:2016-09-16 15:49:52Date Closed:2016-10-11 01:10:22
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General Channels/chan_sip/Interoperability
Versions:13.2.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:64bit LinuxAttachments:( 0) call_18886789208_form_cell_works.txt
( 1) call_18886789208_from_int_silence.txt
( 2) sip.log
Description: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@gw1.sip.us:5061>;tag=as28725f49
To: <sip:15033277805@gw1.sip.us:5060>;tag=gK0ce47da4
Call-ID: 0e760a970d24e31e22afca333f10989e@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@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@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@gw1.sip.us:5061>;tag=as28725f49
To: <sip:15033277805@gw1.sip.us:5060>;tag=gK0ce47da4
Contact: <sip:8053881711@100.32.192.11:5061>
Call-ID: 0e760a970d24e31e22afca333f10989e@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.
Comments:By: Asterisk Team (asteriskteam) 2016-09-16 15:49:53.553-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Rajiv Duggal (rduggal@dex.com) 2016-09-16 15:52:19.231-0500

sip.log attached for review.
By: Joshua C. Colp (jcolp) 2016-09-20 08:15:23.535-0500

Is this with chan_sip or chan_pjsip?
Can you also please provide the complete Asterisk console output.
By: Rajiv Duggal (rduggal@dex.com) 2016-09-20 10:30:31.426-0500

this is on a trunk using chan_sip
By: Rusty Newton (rnewton) 2016-09-21 17:53:25.953-0500

Rajiv, can you do two things to help us out:

* See if the behavior is the same in an older version of 13 to see if there is a regression in the same branch.
* See if the behavior is the same in the 11 branch (where chan_sip is core supported).
By: Rajiv Duggal (rduggal@dex.com) 2016-09-21 18:14:40.490-0500

Hi Rusty,

I already have asterisk 11 running and I verified it works ok on this release.
What version of 13 do you want me to use and where do I download it from.

Regards
Rajiv

By: Rajiv Duggal (rduggal@dex.com) 2016-09-21 18:16:10.303-0500

Am I on the most current release ? If not can I upgrade from the freepbx menu ? If error still persists you would want a fix on the most current release in any case .

Thanks
Rajiv
By: Joshua C. Colp (jcolp) 2016-10-04 12:01:53.191-0500

The most recent release of 13 is Asterisk 13.11.2. I'm unfamiliar with how to update from FreePBX, you would need to look at their documentation for doing so. I'm putting this back into feedback until we know if it remains an issue with a recent version as well.
By: Walter Doekes (wdoekes) 2016-10-05 16:34:20.692-0500

It's perfectly legal to have a Contact which is different from the To-header.

@Rajiv, I fail to see the problem here.

What do you expect Asterisk 13 to do differently than it does in the SIP snippet above?
By: Rajiv Duggal (rduggal@dex.com) 2016-10-06 11:52:36.827-0500

The problem being restated is that for the below INVITE from sip provider
{noformat}
To: <sip:15033277805@gw1.sip.us:5060>;tag=gK0ce47da4
..
Contact: <sip:+15033277805@192.168.16.8:5060 SIP/2.0
{noformat}

the ACK generated by asterisk is per below
{noformat}
ACK sip:+15033277805@192.168.16.8:5060 SIP/2.0
..
       From: <sip:8053881711@gw1.sip.us:5061>;tag=as28725f49
       To: <sip:15033277805@gw1.sip.us:5060>;tag=gK0ce47da4
       Contact: <sip:8053881711@100.32.192.11:5061>
       Call-ID: 0e760a970d24e31e22afca333f10989e@gw1.sip.us
       CSeq: 103 ACK
       User-Agent: FPBX-AsteriskNOW-12.0.76.4(13.2.0)
{noformat}

Per RFC 3261 Section 17.1.1.3:
{quote}
"...The ACK request constructed by the client transaction MUST contain
values for the Call-ID, From, and Request-URI that are equal to the
values of those header fields in the request passed to the transport
by the client transaction (call this the "original request")"
{quote}

So ACK should like per below
{noformat}
ACK sip:15033277805@192.168.16.8:5060 SIP/2.0
..
       From: <sip:8053881711@gw1.sip.us:5061>;tag=as28725f49
       To: <sip:15033277805@gw1.sip.us:5060>;tag=gK0ce47da4
       Contact: <sip:8053881711@100.32.192.11:5061>
       Call-ID: 0e760a970d24e31e22afca333f10989e@gw1.sip.us
       CSeq: 103 ACK
       User-Agent: FPBX-AsteriskNOW-12.0.76.4(13.2.0)
{noformat}

thanks
Rajiv

By: Walter Doekes (wdoekes) 2016-10-06 15:17:56.383-0500

Hi there,

I think you've been reading the wrong section of RFC3261.

Check out this bit:
{quote}
17.1.1.3 Construction of the ACK Request

  This section specifies the construction of ACK requests sent within
  the client transaction.  A UAC core that generates an ACK for 2xx
  MUST instead follow the rules described in Section 13.
{quote}

The ACK we're dealing with here is an ACK to a 200, not to a final non-2xx.

For ACKs to final 2xx: R-URI = Contact of 2xx \(*)
For ACKs to final non-2xx: R-URI = original R-URI (where you were reading)

\(*)
{quote}
The UAC core MUST generate an ACK request for each 2xx received from
the transaction layer.  The header fields of the ACK are constructed
in the same way as for any request sent within a dialog (see Section
12) \(**)
{quote}
\(**)
{quote}
  The UAC uses the remote target and route set to build the Request-URI
  and Route header field of the request.

etc.. etc.. etc..
{quote}

I see no issue here.
By: Rajiv Duggal (rduggal@dex.com) 2016-10-10 17:12:48.748-0500

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@gw1.sip.us:5061>;tag=as28725f49
       To: <sip:15033277805@gw1.sip.us:5060>;tag=gK0ce47da4
       Call-ID: 0e760a970d24e31e22afca333f10989e@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@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@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@gw1.sip.us:5061>;tag=as28725f49
       To: <sip:15033277805@gw1.sip.us:5060>;tag=gK0ce47da4
       Contact: <sip:8053881711@100.32.192.11:5061>
       Call-ID: 0e760a970d24e31e22afca333f10989e@gw1.sip.us
       CSeq: 103 ACK
       User-Agent: FPBX-AsteriskNOW-12.0.76.4(13.2.0)
       Content-Length: 0

By: Walter Doekes (wdoekes) 2016-10-11 01:09:55.990-0500

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}
  Since all the route set elements contain the lr parameter, U1
  constructs the following BYE request:

     BYE sip:callee@u2.domain.com SIP/2.0
{quote}
That R-URI (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/
By: Rajiv Duggal (rduggal@dex.com) 2016-10-11 11:47:53.878-0500

Hi Walter,

I am sorry if my analysis caused you grief. I am trying to bridge the gap between what my sip provider is doing and way asterisk 11 vs 13 is working. Intention was to dive into details to uncover bug that if fixed will help the community.
I am not stating that the contact header should not be used, just that it plays a role where a dialog is setup and established.

I do thank you for the details you have provided and I have sent the information to my provider for final response on this issue. I believe they are also waiting on access to JIRA account, provider being SIP.US. I am trying to drive consensus between the 2 teams.

My opinion is that sip.us is changing the contact in when it should not be changed. The next question was should that be non-consequential because its value should not be referenced as it is not a target refresh request. At the end of the day it seems to work with Asterisk11 but not 13 that leads me to believe something more is happening.

You reasoning is well received and I would like to come back with a reasoning  as applicable. Again the intention is not to contradict you.

thanks.
Rajiv


.

By: Asterisk Team (asteriskteam) 2016-10-11 11:47:54.094-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: Walter Doekes (wdoekes) 2016-10-12 11:17:46

Good! Now that we agree that updating the R-URI to the Contact is correct in regular cases, we can move on to your specific issue.

Normally, I would say that this is a support problem that doesn't belong in the issue tracker, but as you say, it apparently behaves differently between Asterisk 11 and 13. That makes me curious enough to find out more.

Can you get us the following:
- a SIP trace of a good call setup (Asterisk 11): including the INVITE, 1xx, 200, ACK, BYE and 200; only the call-leg that is causing trouble (between Asterisk and sip.us, you say?)
- a SIP trace of a failing call setup (Asterisk 13): including the INVITE, 1xx, 200, ACK, BYE and 200 (or at least, all packets that are available) and all packets that are duplicated; again only the relevant call-leg
- the chan_sip config you use for these calls (the device config + relevant general config; passwords and usernames scrubbed of course); using any outboundproxy? nat config? externip/externhost? check the settings in in [general] too
- the Dial-string from your extensions.conf; using an outboundproxy in that string?

Scrub as little as possible, but if you do scrub any details, make sure the replacements don't drop information (e.g. if you replace an IP, replace it everywhere with the same unique identifier).

If possible, get the SIP traces on the outermost router. I think the contact with 192.168.16.8 looks awfully suspicious. And I wonder if there isn't simply some ALG on the way messing things up for you.
By: Rajiv Duggal (rduggal@dex.com) 2016-10-14 15:22:41.147-0500

Hi Walter,

Thanks for your details on this. At this time we can close this ticket as it does not seem to be a asterisk issue. At this time I can replicate my issue on Asterisk11 as well.
Attaching 2 logs once where call works fine when calling from cell phone to a DID that points back to our PBX.
The other when we call from a local extensions or a sip trunk and it disconnects or goes silent.
Both logs are uploaded for your review. My sip provider is looking at their routing at this time.

Thanks for your help, much appreciated
.Rajiv.
By: Rajiv Duggal (rduggal@dex.com) 2016-10-14 15:23:14.832-0500

debug logs
By: Walter Doekes (wdoekes) 2016-10-15 03:42:36.126-0500

(1) You originally described a problem with the ACK being sent to the wrong place, and then you've captured an *inbound* call, where Asterisk doesn't need to send any ACK (call_18886789208_form_cell_works.txt) -- Asterisk is the UAS for both transactions in that call...
(2) Call setup/teardown appears fine in call_18886789208_from_int_silence.txt
(3) As the SIP seems fine, your problem is probably SDP/RTP related, but call_18886789208_from_int_silence.txt is missing lots of SDP info, particularly *all* SDP from  65.254.44.194. Because you used grep -C10 on the logs instead of the tcpdump filters: tcpdump -r allcaptured.pcap -nnvls0 host 65.254.44.194
(4) If the call stays silent, you should attempt to debug with 'rtp set debug on' and 'sip set debug on' in the asterisk console. Those two should show enough (assuming your logger.conf settings are set up properly).

In short:
- as you've said yourself: these dumps have nothing to do with the original problem you've described
- the routing appears just fine, if there is anything you should look at, it would be RTP flow startup or lack thereof (wrong IPs? or both parties waiting for the other to start sending? or NAT issues?)

Closing out as not-a-bug. Support can be found in other places like the forum or the asterisk-users list.

Good luck!