[asterisk-bugs] [JIRA] (ASTERISK-26221) chan_sip: iLBC does not include correct mode

[Alexander Traud (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232411#comment-232411 ] 

Alexander Traud commented on ASTERISK-26221:
--------------------------------------------

Changing the Status back from Closed to Triage, because this issue still affects Asterisk 13. The issue is solved in Asterisk 14 along with another issue (adding iLBC 20). Asterisk Team, please, re-Open this issue. This issue still affects Asterisk 13.

Aaron, the Asterisk Team takes over resolutions of issues only in some cases (internal work project was accepted as so on). Therefore to get this going, the Asterisk Team expects _you_ to go through the whole contribution process. This is counter intuitive (and against motivation theory) because you have solved the issue for your setup already. Although you were keen enough to report the issue, created a shareable patch, and filed the legal registration, you are punished to go even through Git and Gerrit. So it should not be called ‘see the change faster’ but ‘see it it all’. I have seen five year old issue reports with full working patches – I had to drive the inclusion myself.

Anyway, back to you actual issue. I hate to argument and wasting everyones time even more, however, I disagree with some of your points. {quote}this interpretation is not without precedent{quote}Yes, even I had a hard time to understand that part of the RFC while analyzing the various iLBC implementations and what Asterisk 13 did actually. But this is no justification to interpret it that way. Anyway, for the sake of interoperability and because it does not hurt, Asterisk should send {{mode=30}}. Furthermore, I raised this issue with the Zoiper team exactly two months ago and did not get any response, yet. Aaron (and everyone else interested in a resolution), please, file a bug-report with Zoiper as well. Obviously, I was not able to explain/convince them. This issue should be addressed by them as well.{quote}required value during negotiation, which is why it was present in Asterisk<13{quote}I am not aware of any documentation of the why.{quote}seems to contradict the earlier assertion{quote}It does not, when you read it semantically instead of syntactically. The main problem are legacy iLBC-30-only implementations which never heard about iLBC 20 and this newly introduced {{mode=20}}. If you go through the RFC revisions, you see how that evolved. Therefore, the compatible way is to default to iLBC 30 when one party does not specify {{mode=20}} while negotiation. Or stated differently: Only if both parties state {{mode=20}}, the call goes for iLBC 20. The authors found a clever way to stay compatible with early implementations or those which do not support mode parameters at all. Hopefully the Zoiper team addresses this in sake of interoperability. Anyway, I see no harm to send the mode always, as Asterisk 12 and earlier did.

Now, we have to get the patch into Asterisk 13. Joshua, could you please explain what sort of tests are required? Is there a role model to copy from? I see three approaches to this issue:
A) add the iLBC 20 code to Asterisk 13 (it is already backported; test cases are required), or
B) add a format module like it was done with G.729 Annex B [just recently|https://issues.asterisk.org/jira/browse/ASTERISK-26228] (chan_pjsip would benefit from this as well), or
C) add the proposed change just to chan_sip as proposed here.{quote}{{ptime:20}} is completely nonsensical in case of iLBC 30.{quote}That topic is even more difficult. A receiver has to support all possible packetization times, within the negotiated format – in case of iLBC 30, this is 30, 60, 90, 120, and so on. The maxptime gives an upper limit on that, for example when the receiver has limited buffers or quality constraints (like delay or echo detection). The ptime itself is therefore just a preferred value to been seen, for example the sender knows about networking constraints, for example wants to reduce the traffic load.

An example, Asterisk has no limitations because it is connected to a high speed Internet connection. It sends a ptime of 20 and a maxptime of 300 because there are no constraints. Actually, it would be better not to send any ptime then. That is another story. The VoIP/SIP client is on a GSM network, but does not like to buffer too much data and therefore specifies a ptime of 60 and maxptime 120. Furthermore, it does not add {{mode=20}} to the SDP, to make sure the more resource strained iLBC 30 is negotiated. In that case, it does not make any sense (or gives any additional information) to change the ptime on the Asterisk side while SDP negotiation. If just iLBC 30 is negotiated, a ptime of 30 sounds more logical but it does not add any more information to the setup.

When it comes to the other direction, it is the same. Although Asterisk could answer with a ptime of 30, yet, because just iLBC 30 was negotiated – why should it? When later on, there is a re-INVITE with new audio codecs, one which allows ptime 20 again, Asterisk would have to send a different ptime again – although its constraints did not change at all. Or stated differently: A ptime of 20 is fine for Asterisk. Just because it is using iLBC 30 for this connection, its constrains did not change. The iLBC mode and the packetization time are orthogonal things. One is about the constraints of the system, the other one is about the negotiated audio format.

Puh, yes, I thought a lot about this and asked myself exactly the same question, when I raised that other issue. Especially because Asterisk does not honor the preferred ptime for audio codecs which are not marked as ‘smoothable’. Personally, I would like to see no \[max\]ptime from Asterisk at all, because Asterisk should have no limitations. However, I have to admit, that there are several places within Asterisk which improve in behavior with a ptime of at least 20 (and multiples of that).

Long story short, another example: My personal Asterisk setup sends ptime:20/maxptime:20, because I have one media format enabled which does not allow packetization on the ingress (not a limitation of the codec but support for that was not coded yet). Then, I tried with iLBC 20 disabled. Still, I had no problems with all iLBC implementations, I tested. Therefore, when you find an implementation which has problems with the ptime, please, update this issue report.

> chan_sip: iLBC does not include correct mode
> --------------------------------------------
>
>                 Key: ASTERISK-26221
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26221
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling
>    Affects Versions: 13.9.1
>            Reporter: Aaron Meriwether
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: asterisk-13-ilbc-sdp.patch
>
>
> As of Asterisk-13, the format/channel handling was overhauled.  Bug ASTERISK-25309 was introduced as a result and eventually closed, but the fix for that bug was not complete.
> The old (pre-Asterisk-13) behavior was that whenever iLBC would be listed in an SDP message, it would be qualified with "mode=30" because Asterisk supports only the 30ms framing of iLBC.  As of Asterisk-13, the new format/channel handling overhaul caused Asterisk to offer "mode=20" in some cases, resulting in some connections negotiating an unsupported framing.  ASTERISK-25309 addressed this by removing the mode value entirely, which resolved the issue for some SIP clients, but because the mode is omitted entirely from the Asterisk side, if the client offers mode=20 and Asterisk does not override that offer with a mode=30 offer, some clients take that as an invitation to begin transmitting iLBC-20 data.
> ASTERISK-25309 cites RFC 3952 section 5 as justification for removing the "mode=" offer, however if that specification is read carefully, it can be seen that it only defines the "always use iLBC-30" behavior when at least one side offers mode=30.  If one side offers mode=20 and the other makes no framing offer, behavior is undefined.
> The attached patch causes iLBC negotiation to return to its pre-Asterisk-13 behavior of always offering mode=30 regardless of the other side's offer.  It does this by reinstating the "mode=" output, and taking the "framing" value from "ast_format_get_default_ms" rather than "ast_format_cap_get_format_framing".  This also causes "ptime" to be output correctly, and does not preclude using a patched iLBC-20 format module (as hard-coding the value in chan_sip.c would have).



--
This message was sent by Atlassian JIRA
(v6.2#6252)