<div dir="ltr">On Mon, Jun 24, 2013 at 5:22 AM, Pavel Troller <span dir="ltr"><<a href="mailto:patrol@sinus.cz" target="_blank">patrol@sinus.cz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi!<br>
Last Friday I upgraded one of our Asterisk VoIP gateways to the current v11<br>
branch. Before it was running on a v11 branch from December 17th, 2012.<br>
I found that since then, average call duration decreased dramatically for<br>
some destinations. I've made some tcpdumps and I've found the cause.<br>
The problem appears with some partners, which also use Asterisk, in one<br>
particular case in version 1.6.2.24. The call flow is like this:<br>
- We send INVITE with offered codecs G.711A, G.729 and G.711U (in this<br>
order).<br>
- The partner replies with 100 Trying (No SDP), 180 Ringing (No SDP) and<br>
183 Sessiong progress (With SDP, offered G.711A, G.711U and G.729 codecs in<br>
this order).<br>
The media stream is going from this time, in G.711A both directions.<br>
- The partner sends 200 Ok with SDP and with the same codecs as in 183.<br>
And now, the problem occurs: For no apparent reason, G.729 encoded packets<br>
start appearing in the stream together with already present G.711A ones in<br>
both directions, they are 1:1 and almost perfectly interleaved.<br></blockquote><div><br></div><div style>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:</div>
<div style><br></div><div style><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"> 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.</pre></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I've never seen this. The subscribers don't understand each other and the<br>
calls are terminated quickly, thus causing very low ACD.<br>
I've made a quick fix by disallowing G.729 on my side and ACD promptly<br>
recovered.<br>
I've looked at svn log and I've found that in r369028 there was a relatively<br>
big change in SDP handling, but IMHO doing a different thing - handling<br>
multiple media streams (SDP m lines) than multiple codecs in one media stream.<br></blockquote><div><br></div><div style>That change also occurred before 11 was released, so this would not have altered the behavior between your upgrades.</div>
<div style><br></div><div style>There have not been significant changes to SDP handling since 11 was released.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
What I also don't understand is, that the same thing happens on both<br>
endpoints - the remote party also sends me back perfectly interleaved mix<br>
of G.711A and G.729 in one media stream.<br></blockquote><div><br></div><div style>Then they're both doing the wrong thing.</div><div> <br></div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div>
<div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>