Summary:	ASTERISK-26221: chan_sip: iLBC does not include correct mode
Reporter:	Aaron Meriwether (ameriwether)	Labels:
Date Opened:	2016-07-20 00:01:10	Date Closed:
Priority:	Minor	Regression?	Yes
Status:	Open/New	Components:	Channels/chan_sip/CodecHandling
Versions:	13.9.1	Frequency of Occurrence	Constant
Related Issues:	is caused by ASTERISK-25309 [patch] iLBC 20 advertised is related to ASTERISK-26218 [patch] iLBC 20
Environment:		Attachments:	( 0) asterisk-13-ilbc-sdp.patch
Description:	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).
Comments:	By: Asterisk Team (asteriskteam) 2016-07-20 00:01:11.413-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: Aaron Meriwether (ameriwether) 2016-07-20 00:03:08.333-0500 Patch against Asterisk 13.9.1 By: Joshua C. Colp (jcolp) 2016-07-20 11:31:11.325-0500 [~traud] has implemented support for both on ASTERISK-26218. Does this also solve the issue mentioned here for you? By: Alexander Traud (traud) 2016-07-21 10:22:24.713-0500 {quote}If one side offers mode=20 and the other makes no framing offer, behavior is undefined.{quote}Mhm. I still understand it the way I did it. Rationale: iLBC 20 was introduced later than iLBC 30. If the answerer (in our case: Asterisk) does not support parameters at all, it cannot answer with a parameter {{mode}} because it does not know about this _new_ feature. Requiring a mode would break backwards compatibility. Furthermore, the chapter ‘Mapping to SDP parameters’ does not state 30 as a possible value for mode, just 20 and 0. No mode as parameter in SDP means iLBC 30. Although {{"mode=30"}} is written in the RFC, this is meant semantically not syntactically. Otherwise the previous statement – just 20 and 0 – does not make sense. Consequently, you have found a bug in one of your VoIP/SIP clients. Please, report this to their authors! Anyway, you raised an interoperability issue and I am curious which clients face this issue in particular. Especially, because the current reviewed change is just about the master branch (Asterisk 14 and newer) not about Asterisk 13, yet. I tested with a lot of iLBC clients – with iLBC 20 and without – and found no interoperability issue. Therefore, please, mention in detail which clients are faced by this issue. I would love to see iLBC 20 support in Asterisk 13 as well. If iLBC 20 does not come for Asterisk 13, the Asterisk team has to go for your proposal because I see no harm in including {{mode=30}} always. I removed that parameter because of the RFC and because it was in conflict with my iLBC 20 patch (which sets this value in a format-attribute module rather than chan_sip). By: Aaron Meriwether (ameriwether) 2016-07-21 12:40:02.327-0500 I need to test further, but I think it should work fine in conjunction with your 20ms patch.  I also suspect your 20ms patch alone may not solve our issue in all cases, since behavior will still be technically undefined if Asterisk does not advertise any particular framing. (e.g., if client advertises 20ms and Asterisk advertises nothing, some clients might expect Asterisk to transmit 30ms and others might expect 20ms). The specific client where this issue has been observed so far is Zoiper (inbound to Asterisk), but there is also an OpenSIPS proxy layer involved that might be muddying things too. By: Alexander Traud (traud) 2016-07-22 03:59:49.774-0500 {quote}if client advertises 20ms and Asterisk advertises nothing, some clients might expect Asterisk to transmit 30ms and others might expect 20ms{quote}You repeated yourself without going through my rationale. Consequently, I do not know whether you have not seen or not understand (parts of) the rationale: When one party has no {{mode}} in SDP, both parties have to fall back to iLBC 30. Consequently yet, I cannot give a better explanation because I do not know which part created the misunderstanding.{quote}Zoiper{quote}I tested that client but did not double-check that scenario via Wireshark correctly. As you stated, when Asterisk does not answer with a mode, Zoiper falls back to iLBC 20. Tested with Zoiper Premium 1.13.2 for iPhone. This breaks compatibility with legacy iLBC-30-only implementations which do not send/know about the mode parameter. Therefore, I am going to report this to the Zoiper team.{quote}your patch alone may not solve our issue in all cases{quote}I updated the patch and Asterisk sends the mode in any case now, because I see no harm in doing so. With that, Zoiper passed all my tests. Thanks for reporting. When you find an outstanding case/scenario, please update this issue report. [~asteriskteam], my change is just for Asterisk 14 and newer. This report here affects Asterisk 13 as well: A) shall I adopt my change for Asterisk 13, or B) shall Aaron submit his patch for inclusion, or C) is this report resolved as ‘Not A Bug’? By: Joshua C. Colp (jcolp) 2016-07-22 04:42:17.870-0500 [~traud] It's best to ask those kind of questions on the asterisk-dev mailing list as not everyone monitors the issue tracker closely. Supporting 20ms itself would be a new feature and would need a test for 13. By: Joshua C. Colp (jcolp) 2016-07-22 07:53:05.031-0500 As for this specific patch are you sure it sent a mode line in 11? I just looked through the source code for chan_sip and could not find it. By: Aaron Meriwether (ameriwether) 2016-07-22 14:54:43.005-0500 [~traud], RFC-3952 is very unclear on some points, which is why I referred to certain scenarios as "undefined".  Specifically, although the RFC in one place seems to imply that "20" is the only valid mode (or "0" which is "reserved") for transmission in an SDP packet, it later goes on to describe negotiation logic involving `an offer of "mode=20" receiving an answer of "mode=30"`, which seems to contradict the earlier assertion.  If that later part is taken to mean that absence of a "mode=" parameter is used to represent the implied "mode=30" constraint (as I believe you are interpreting it), then yes, your removal of the "mode=" parameter from Asterisk-13 could be considered to be according to the RFC.  However, it seems that others may have interpreted the RFC to mean that the literal "mode=30" string is a valid (and even required) value during negotiation, which is why it was present in Asterisk<13 (and why Zoiper uses a literal "mode=30" value too, so this interpretation is not without precedent). The other (perhaps primary?) issue is the "ptime" value, which is also derived from the "framing" variable in Asterisk.  With "framing" now calculated via "ast_format_cap_get_format_framing", unpatched Asterisk-13.9 may generate an SDP with no "mode=" and a "ptime" of "20" (copied from the other G711 leg of the call I assume), which is completely nonsensical.  Below, find an actual SDP negotiation from Zoiper calling in to unpatched Asterisk 13.9.1, (which bridges onward to a G711 channel): Zipper --> Asterisk {noformat} v=0 o=Z 0 0 IN IP4 xxx.x.xxx.xxx s=Z c=IN IP4 xxx.x.xxx.xxx t=0 0 m=audio 8000 RTP/AVP 98 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=30 a=sendrecv {noformat} Asterisk-->Zoiper {noformat} v=0 o=xxxxxxx 226373662 226373662 IN IP4 xx.xxx.xx.xx s=Asterisk PBX c=IN IP4 xx.xxx.xxx.xx t=0 0 m=audio 21772 RTP/AVP 98 a=rtpmap:98 iLBC/8000 a=silenceSupp:off - - - - a=ptime:20 a=maxptime:300 a=sendrecv {noformat} My patch addresses both the (perhaps non-RFC-intended but certainly widely used) lacking "mode=30" as well as the (definitely incorrect) "ptime" value.  Although it seems "mode=30" may not actually be required in some interpretations of the RFC, it caused no issues before Asterisk-13, so reverting behavior to the complete known-working pre-Asterisk-13 format seems like a good idea, especially in such a way as to make room as my patch does for the future iLBC-20 support that [~traud] is pushing for Asterisk-14. [~jcolp], here is the history of the code in question: * Originally, chan_sip.c always transmitted ("mode=%d", fmt.cur_ms), and things worked fine. * When [~mjordan] merged the Media Format Rewrite, this changed to ("mode=%d", framing), where framing comes from ast_format_cap_get_format_framing, causing Asterisk to advertise iLBC with "mode=20" in some cases (e.g. transcoding to G711).  Some other transcoding-between-mismatched-frame-sizes issues also appeared with this rewrite, which [~traud] has since resolved. * When [~traud] removed the "mode=" parameter as of "Change-Id: I92d724600a183eec3114da0ac607b994b1a793da", it may have fixed the issue in some cases (because Asterisk no longer advertises "mode=20"), but not for our Zoiper use-case. Now that I have examined the history more closely, I suspect that the iLBC "ptime" issue may have been present since the Media Format Rewrite, which is why [~traud]'s removal of the "mode=" parameter was insufficient to get SDP negotiation working again for us. By: Aaron Meriwether (ameriwether) 2016-07-22 14:57:37.378-0500 Reattaching my patch as a legal "code contribution" now that my registration is complete. By: sstream (sstream) 2016-07-23 23:51:36.244-0500 The similar issue seems to exist for IAX2(iLBC) to SIP(ulaw). Please refer to [ASTERISK-18094|https://issues.asterisk.org/jira/browse/ASTERISK-18094?focusedCommentId=231552&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-231552] By: Joshua C. Colp (jcolp) 2016-07-25 14:02:31.625-0500 If you'd like to see this change in faster there are instructions on the wiki[1] for the patch contribution process, otherwise it is up to someone else to take it through the complete process (code review). [1] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process By: Alexander Traud (traud) 2016-09-26 07:30:14.321-0500 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. By: Joshua C. Colp (jcolp) 2016-09-26 07:37:31.607-0500 This issue was in triage and I've acknowledged it once again. By: Aaron Meriwether (ameriwether) 2016-09-26 19:26:37.388-0500 Thanks for staying on top of this issue, [~traud].  We have indeed been using the patch I provided to solve our immediate issues, and thus not been motivated to babysit the upstream fix.  I got the impression that you and I had a little bit of a disagreement about the most correct fix to the SDP negotiation, and I didn't have the time to work through the arguments in detail. On the point about {{mode=30}}, I agree; after careful review of the RFC, it seems that this was never intended by the authors, but it does not seem to break anything, and it does seem to be expected by some implementations, so it makes sense to transmit it for interoperability reasons. "why it was present in Asterisk<13": Yes, I am not aware of any specific documentation as to "why" either, so it may have simply been coincidence that the RFC was misinterpreted in the same way by the original Asterisk implementor as the implementors of other software. On the subject of {{ptime=30}}, after further testing, it seems that it may actually be Asterisk that is encountering transcoding issues when the {{framing}} value is not a multiple of the codec packet size.  I have observed the issue when trying to connect from Zoiper, but from the packet capture, it appears to be the Asterisk side which is failing to transmit RDP packets when using iLBC-30 with {{framing = ast_format_cap_get_format_framing(p->caps, format)}}.  Zoiper does as you suggested and omits the {{ptime}} value from their side of the SDP, and that seems to be what confuses Asterisk, causing {{ast_format_cap_get_format_framing}} to return "20" even though that value will not work as a valid frame size with iLBC-30.  In my patch, I use {{ast_format_get_default_ms}} instead to inject the value of "30" into the Asterisk side of the SDP negotiation.  I assume this fixes things by causing later capabilities logic on the Asterisk side to see "30" as the negotiated frame size, rather than "20" as it seems to assume by default. This default frame size of "20" may be central to [~sstream]'s iLBC-30 transcoding problems too.  Unfortunately, I do not understand the capabilities structure well enough to correct the {{ast_format_cap_get_format_framing}} function to handle iLBC packetization calculations correctly... By: Alexander Traud (traud) 2016-09-27 03:51:08.575-0500 {quote} {{mode=30}} seem to be expected by some implementations, so it makes sense to transmit it for interoperability reasons.{quote} Fully agreed. Another question, hopefully the last: What about my iLBC 20 patch which is available via ASTERISK-26218 (actually via [my GitHub|https://github.com/traud/asterisk-ilbc]). Would that solve your issue as well? Then, I would look into alternative A to solve this here. Otherwise, I go for alternative B because alternative C conflicts with alternative A (I would have to add a reverse patch to my GitHub) and I do not think I get it passed the review process because the issue would not be solved for chan_pjsip, just chan_sip.{quote} Asterisk encounters transcoding issues when the framing value is not a multiple of the codec packet size.{quote}I would like to split this issue into a new report. Could you do me a favor and create concise steps to reproduce your issue? Which SIP client (Zoiper), SIP server (Asterisk chan_sip), which versions, which operating system, and which translation paths you get/use. The latter can be double-checked from the CLI. I look-up the exact command, if you need. I have done a lot of stuff in that area and all my framing issues were solved with Asterisk 13.6 (ASTERISK-25353). Obviously, you found another issue. To track that down, steps to reproduce, the actual results you see, the expected results – Apple explained such an bug-reporting approach [formerly…|http://web.archive.org/web/20160324163652/https://developer.apple.com/bug-reporting/using-bug-reporter/problem-detail/] That would help to reproduce your issue. Then, I can look into that as well. Perhaps, I find the reason and even a solution. Or went _all_ your issues away already with the patch you proposed here in that report? Anyway, please, create a full blown bug report.{quote}Thanks for staying on top of this issue …{quote}Well, it was my fault that this issue here got closed and marked as fixed, because I used a wrong command in my Commit Message for my iLBC 20 change. Simply, repairing my own faults actually. By: Aaron Meriwether (ameriwether) 2016-09-27 14:49:49.050-0500 My patch does completely solve our issue in Asterisk 13, where iLBC-30 is the only mode available, and where chan_sip is being used.  However because this is a patch to chan_sip in particular, if similar issues exist in IAX2 or pjsip, they will not be solved by my patch. I've tried your iLBC-20 patch by itself, but it doesn't add the "mode" value to chan_sip.  I also tried your patch plus adding "mode" to chan_sip, and that still doesn't work right because the ptime value causes Zoiper to use iLBC-20 even if Zoiper is configured to only offer iLBC-30.  Your patch also does not seem to work right in conjunction with chan_sip even when Zoiper offers iLBC-20 - the SDP negotiation on the wire looks correct in that case (each side offers iLBC-20), but Asterisk still transmits iLBC-30 and complains about receiving iLBC-20 frames (the "Huh?" message). {noformat} asterisk: WARNING[3706][C-00000004]: codec_ilbc.c:127 in ilbctolin_framein: Huh?  An ilbc frame that isn't a multiple of 50 bytes long from RTP (38)? {noformat} So it seems that your iLBC-20 patch does not really operate correctly with chan_sip at all. Here, specifically, are the tests which fail: Common setup for all the tests: Zoiper v3.9.32144, connecting to Asterisk 13 using chan_sip, and bridging to a G.711 PCMU 20ms back end. Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch applied: - Zoiper offers iLBC with mode=30 and no ptime - Asterisk offers iLBC with no mode and ptime=20 - Zoiper begins transmitting iLBC-20 frames - Asterisk begins transmitting iLBC-30 frames - Asterisk warns about frame size: {noformat} asterisk: WARNING[3706][C-00000004]: codec_ilbc.c:127 in ilbctolin_framein: Huh?  An ilbc frame that isn't a multiple of 50 bytes long from RTP (38)? {noformat} Zoiper with iLBC-20 enabled, Asterisk with the traud/asterisk-ilbc patch applied: - Zoiper offers iLBC with mode=20 and no ptime - Asterisk offers iLBC with no mode and ptime=20 - Zoiper begins transmitting iLBC-20 frames - Asterisk begins transmitting iLBC-30 frames - Asterisk warns about frame size ("Huh?") Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch, and the "mode" line added to chan_sip: - Zoiper offers iLBC with mode=30 and no ptime - Asterisk offers iLBC with mode=20 and ptime=20 - Zoiper begins transmitting iLBC-20 frames - Asterisk begins transmitting iLBC-30 frames - Asterisk warns about frame size ("Huh?") Zoiper with iLBC-20 enabled, Asterisk with the traud/asterisk-ilbc patch, and the "mode" line added to chan_sip: - Zoiper offers iLBC with mode=20 and no ptime - Asterisk offers iLBC with mode=20 and ptime=20 - Zoiper begins transmitting iLBC-20 frames - Asterisk begins transmitting iLBC-30 frames - Asterisk warns about frame size ("Huh?") Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch, and my full chan_sip patch: - Zoiper offers iLBC with mode=30 and no ptime - Asterisk offers iLBC with mode=20 and ptime=20 - Zoiper begins transmitting iLBC-20 frames - Asterisk begins transmitting iLBC-30 frames - Asterisk warns about frame size ("Huh?") Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch, and my full chan_sip patch: - Zoiper offers iLBC with mode=20 and no ptime - Asterisk offers iLBC with mode=20 and ptime=20 - Zoiper begins transmitting iLBC-20 frames - Asterisk begins transmitting iLBC-30 frames - Asterisk warns about frame size ("Huh?") And the tests that succeed: Zoiper with iLBC-30 enabled, Asterisk with my full chan_sip patch: - Zoiper offers iLBC with mode=30 and no ptime - Asterisk offers iLBC with mode=30 and ptime=30 - Zoiper begins transmitting iLBC-30 frames - Asterisk begins transmitting iLBC-30 frames - Everything works Zoiper with iLBC-20 enabled, Asterisk with my full chan_sip patch: - Zoiper offers iLBC with mode=20 and no ptime - Asterisk offers iLBC with mode=30 and ptime=30 - Zoiper begins transmitting iLBC-30 frames - Asterisk begins transmitting iLBC-30 frames - Everything works By: Alexander Traud (traud) 2016-09-28 03:39:09.126-0500 Mhm. You face an issue with my patch for sure. However, that patch works here with Asterisk 13.10/chan_sip and was re-tested against Zoiper after your report. Therefore, something else must be lurking around. Let me investigate. However, before I look into your test cases, # Which version of Asterisk 13 do you use exactly? # After applying my iLBC 20 change, do you have the statement ‘send mode even when 30, see issue report ASTERISK-26221’ in your {{./res/res_format_attr_ilbc.c}}?