[asterisk-dev] Asterisk 11 branch SIP/SDP: Media stream opened with two codecs simultaneously

[Matthew Jordan]

On Mon, Jun 24, 2013 at 5:22 AM, Pavel Troller <patrol at sinus.cz> wrote:

> Hi!
>   Last Friday I upgraded one of our Asterisk VoIP gateways to the current
> v11
> branch. Before it was running on a v11 branch from December 17th, 2012.
>   I found that since then, average call duration decreased dramatically for
> some destinations. I've made some tcpdumps and I've found the cause.
>   The problem appears with some partners, which also use Asterisk, in one
> particular case in version 1.6.2.24. The call flow is like this:
>   - We send INVITE with offered codecs G.711A, G.729 and G.711U (in this
> order).
>   - The partner replies with 100 Trying (No SDP), 180 Ringing (No SDP) and
> 183 Sessiong progress (With SDP, offered G.711A, G.711U and G.729 codecs in
> this order).
>   The media stream is going from this time, in G.711A both directions.
>   - The partner sends 200 Ok with SDP and with the same codecs as in 183.
>   And now, the problem occurs: For no apparent reason, G.729 encoded
> packets
> start appearing in the stream together with already present G.711A ones in
> both directions, they are 1:1 and almost perfectly interleaved.
>

It sounds like one or both of the remote systems is misinterpreting the
presence of multiple format attributes in a response. The purpose of having
multiple formats listed in the O/A is to allow systems to respond to
changes in the environment or the user's preferences. From RFC 3264:

   When the offerer receives the answer, it MAY send media on the
   accepted stream(s) (assuming it is listed as sendrecv or recvonly in
   the answer).  It MUST send using a media format listed in the answer,
   and it SHOULD use the first media format listed in the answer when it
   does send.

      The reason this is a SHOULD, and not a MUST (its also a SHOULD,
      and not a MUST, for the answerer), is because there will
      oftentimes be a need to change codecs on the fly.  For example,
      during silence periods, an agent might like to switch to a comfort
      noise codec.  Or, if the user presses a number on the keypad, the
      agent might like to send that using RFC 2833 [9].  Congestion
      control might necessitate changing to a lower rate codec based on
      feedback.

   The offerer SHOULD send media according to the value of any ptime and
   bandwidth attribute in the answer.

So it's perfectly valid to respond with multiple format attributes, and
perfectly valid to change from one format to another. It probably shouldn't
be doing that on every other RTP packet.

I have seen traces like this before, although I can't recall what system it
was that was misbehaving. It is not, however, a bug in Asterisk to respond
with multiple formats in an offer or answer.

You can control what Asterisk responds with to an initial INVITE request
with the "preferred_codec_only" option, or, as you noticed, by limiting the
codecs you offer a peer in the first place.



>   I've never seen this. The subscribers don't understand each other and the
> calls are terminated quickly, thus causing very low ACD.
>   I've made a quick fix by disallowing G.729 on my side and ACD promptly
> recovered.
>   I've looked at svn log and I've found that in r369028 there was a
> relatively
> big change in SDP handling, but IMHO doing a different thing - handling
> multiple media streams (SDP m lines) than multiple codecs in one media
> stream.
>

That change also occurred before 11 was released, so this would not have
altered the behavior between your upgrades.

There have not been significant changes to SDP handling since 11 was
released.


>   What I also don't understand is, that the same thing happens on both
> endpoints - the remote party also sends me back perfectly interleaved mix
> of G.711A and G.729 in one media stream.
>

Then they're both doing the wrong thing.


-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130625/62594e9c/attachment-0001.htm>