[Home]

Summary:ASTERISK-21411: Far end Re-invites Asterisk without SDP (ACKs with SDP) - Asterisk does not modify port of RTP stream - Ignores ACK due to no SDP version change
Reporter:Olivier Lambert (olilam)Labels:
Date Opened:2013-04-11 09:11:40Date Closed:2013-04-22 09:11:02
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.21.0 11.2.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS release 5.9 (Final)Attachments:( 0) issue21411.zip
Description:A re-invite without SDP is causing the voice to be established in one way. The exact same test done on asterisk 1.4.38 is not giving the issue, creating a two ways audio as it should. Pcaps of the two tests are available at http://www.misterlambert.net/pcaps.zip. Reinvite is located at frame 5127 for the 1.4 test while it is located at frame 7897 for the 1.8. The one way audio is caused by the missing RTP flow visible at frame 5166.
Comments:By: Michael L. Young (elguero) 2013-04-11 17:12:10.446-0500

In addition to the pcaps that you provided for 1.8, it would be helpful to provide a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Also, please include your SIP settings, general section and peer section.

In the 1.4 pcap I see RTP flowing but, in the 1.8 pcap I never see RTP flowing.  Have you checked the firewall on the 1.8 machine and made sure that the rtp ports are not being blocked?  I take it that 1.4 is on a different server than the 1.8 one?

If there was one-way audio, I would expect to see RTP at least from one side instead of nothing unless the idea is to have RTP flow between the endpoints and not through Asterisk.  A bit thrown off that there appears to be RTP going through on the 1.4 pcap if the reinvite is so that media flows directly between endpoints.  Perhaps I am not understanding your setup.
By: Olivier Lambert (olilam) 2013-04-12 03:34:48.523-0500

Hello, thanks for looking. I will reproduce it one more time and follow your guidelines to collect debug info.

Both pcaps have RTP flows... Look frame 5787 in "oneway_00001_20130411110718.pcap" for example. Both tests are done in the same environment, on the same machine with same firewall settings: to test, I upgrade or downgrade the same asterisk installation...

I post the files you required asap.

Thanks.
By: Olivier Lambert (olilam) 2013-04-12 05:37:37.907-0500

I have uploaded an archive containing the pcaps and asterisk debug info of test session made on asterisk 1.4 and 1.8. The archive also contains the sip.conf and a small drawing of the architecture used for the test...

To complete the info about the tests, in ast1.8 pcap, you can see an RTP flow starting at frame 2605. At frame 5210, the reinvite should stop the previous flow and send it elsewhere but by looking at duration of RTP flow (25,640 sec)  we see that it is not interrupted at all (causing the one way from user perspective)

Looking at the same sequence in ast1.4 pcap, you see that the RTP flow starting at frame 2783 last for only 14,759 sec; this time stamp correspond to the reinvite initiated by frame 5143. This re-invite is also causing the transmission of RTP flow starting at frame 5186…

Thanks

By: Olivier Lambert (olilam) 2013-04-17 02:25:25.234-0500

Hello, do you have all elements to continue the investigation?
Thanks
By: Rusty Newton (rnewton) 2013-04-19 18:01:57.427-0500

I might need someone else to double-check what I'm thinking here, but I think Asterisk is behaving correctly in 1.8.X I'm not sure about the old 1.4.X. (many things have changed since back then).

In regards to the 1.8 pcap and debug you attached:

If I'm reading RFC3264 correctly..

1.
{quote}
The corresponding media stream in the answer MAY be the same as the
  stream in the previous SDP from the answerer, or it MAY be different.
  If the updated stream is accepted by the answerer, the answerer
  SHOULD begin sending traffic for that stream to the new port
  immediately.  If the answerer changes the port from the previous SDP,
  it MUST be prepared to receive media on both the old and new ports as
  soon as the answer is sent.  The answerer MUST NOT cease listening
  for media on the old port until media arrives on the new port.  At
  that time, it MAY cease listening for media on the old port.  The
  same is true for an offerer that sends an updated offer with a new
  port; it MUST NOT cease listening for media on the old port until
  media arrives on the new port.
{quote}

It sounds like ContactRoute shouldn't be trying to listen on the new port until Asterisk actually starts sending media to it. Therefore in this case even though we are ignoring the new SDP coming with the ACK; the ContactRoute server should continue listening on the same port.

2.

{quote}
Nearly all aspects of the session can be modified.  New streams can
  be added, existing streams can be deleted, and parameters of existing
  streams can change.  When issuing an offer that modifies the session,
  the "o=" line of the new SDP MUST be identical to that in the
  previous SDP, except that the version in the origin field MUST
  increment by one from the previous SDP.  If the version in the origin
  line does not increment, the SDP MUST be identical to the SDP with
  that version number.  The answerer MUST be prepared to receive an
  offer that contains SDP with a version that has not changed; this is
  effectively a no-op.  However, the answerer MUST generate a valid
  answer (which MAY be the same as the previous SDP from the answerer,
  or MAY be different), according to the procedures defined in Section
  6.
{quote}

The ContactRoute server doesn't change the SDP version in it's ACK from the previous SDP it sent. Asterisk notes in the debug after the first ACK with SDP back from the ContactRoute server:

{quote}
[Apr 12 11:20:35] DEBUG[5817] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED OR FAILED.
[Apr 12 11:20:35] DEBUG[5817] chan_sip.c: Call 35b845b441d04134b3f9359d05478aa9 responded to our reinvite without changing SDP version; ignoring SDP.
{quote}

I believe if ContactRoute would change the SDP version in the ACK with SDP at frame 5244 that Asterisk would acknowledge it and modify the port for the RTP stream.

I think ASTERISK-17227 is a similar scenario, but with a INVITE with SDP instead of without.

The following option may present a work-around to your issue if you can't affect whether ContactRoute increments the SDP version. This is from the sip.conf sample:

{quote}
;ignoresdpversion=yes           ; By default, Asterisk will honor the session version
                               ; number in SDP packets and will only modify the SDP
                               ; session if the version number changes. This option will
                               ; force asterisk to ignore the SDP session version number
                               ; and treat all SDP data as new data.  This is required
                               ; for devices that send us non standard SDP packets
                               ; (observed with Microsoft OCS). By default this option is
                               ; off.
{quote}
By: Rusty Newton (rnewton) 2013-04-19 18:05:39.764-0500

Can you test with ignoresdpversion=yes and see what happens?
By: Michael L. Young (elguero) 2013-04-19 19:30:20.349-0500

I agree with Rusty's assessment above.  There is one comment that needs to be clarified.

{quote}
The ContactRoute server doesn't change the SDP version in it's ACK from the previous SDP it sent. Asterisk notes in the debug after the first ACK with SDP back from the ContactRoute server:
{quote}

Actually, it does change it but it changes it incorrectly.
The ACK changes the SDP "o=" from:
{quote}
o=root 2146949866 2146949869 IN IP4 172.27.172.3
{quote}

To:
{quote}
o=default 28 2 IN IP4 172.27.172.121
{quote}

First, the "o=" header is changed incorrectly according the RFC.

Second, Asterisk is looking at the session version in that line to determine if the SDP needs to be processed and since the session version didn't increment (it went backwards from 2146949869 to 2), Asterisk ignores the SDP.  Therefore, it doesn't change the audio port resulting in one-way audio.

Please try setting ignoresdpversion=yes, like Rusty pointed out, to see if it fixes this for you.  The RTP Engine had changes between 1.4 and 1.8.  Asterisk 1.8 is actually working the correct way.
By: Olivier Lambert (olilam) 2013-04-22 03:20:40.291-0500

Thank you guys! I will try what you suggested and I will keep you posted.

By: Olivier Lambert (olilam) 2013-04-22 04:12:13.423-0500

You are completely right: the ContactRoute server was the cause of the issue. It seems that the Asterisk 1.4 was more tolerant and was not "seeing" the issues in the SDP. I tested first with the "ignoresdpversion=yes" setting and could confirm that everything was then working.
I have then corrected the ContactRoute server (both about version and SDP "o=") to be able to work without the ignoresdpversion=yes.

Thanks a lot for your help and efficiency!

By: Rusty Newton (rnewton) 2013-04-22 09:10:22.128-0500

No problem. Closing this out since it's not a bug in Asterisk.