Summary:	ASTERISK-23619: Call negotiating iLBC results in speex error messages and one way audio
Reporter:	Tamás Németh (nice0051)	Labels:
Date Opened:	2014-04-11 07:31:28	Date Closed:	2017-12-18 10:33:16.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:	11.8.0 11.10.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux	Attachments:	( 0) bad_android.pcap
Description:	I created a SIP account in Asterisk 11.8.0 like this: [sip703] type=friend host=dynamic secret=zoiper context=belfold regcontext=belfold regexten=703 callerid="Nemeth Tamas" <703> qualify=yes directmedia=no disallow=all allow=ilbc:30 Then I registered to this account using Zoiper for Android. I enabled ILBC as the top priority codec in Zoiper (but I haven't disabled the other codecs). Now I have a problem with INCOMING calls in Zoiper: I hear the calling party but he/she doesn't hear me. I see error messages in Asterisk like this: frame.c:936 speex_get_wb_sz_at: Encountered corrupt speex frame; too many wideband frames in a row. frame.c:966 speex_samples: Had error while reading wideband frames for speex samples I assume, Asterisk thinks that the called Zoiper phone sends it media stream in the speex format, while it sends ILBC. First I thought it's a bug in Zoiper, so I reported to them, but they replied this: ------ RFC 3264 #5.1 ------ For recvonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is expecting to receive for that codec. For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is planning to send for that codec. For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. --------------------------- The last line is the important one in this case, your asterisk version is not following the standard.
Comments:	By: Rusty Newton (rnewton) 2014-04-23 15:42:10.959-0500 bq. The last line is the important one in this case, your asterisk version is not following the standard. I've checked the pcap against the RFC, including your excerpt there. Asterisk is following the RFC and your pcap demonstrates that. {quote} However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. {quote} In your pcap, the 200 OK from Zoiper (the answer) specifies a payload type of 100 for iLBC (which is different than the 97 specified by Asterisk). Asterisk does in fact send RTP with payload type 100 (from the answer), following the RFC. Therefore, I'm confused why the guys at Zoiper or you feel that Asterisk is not following the RFC here? I did note that the offer from Asterisk specifies payload type 97, and Zoiper ends up sending with payload type 97 instead of the 100 that they specify in their own answer.  The developer who assisted me in looking into this couldn't immediately find where that behavior is specified in the RFC . However, In my own testing with Zoiper clients, using your configuration, I saw the same behavior (as far as payload types goes), but my calls work fine and I don't see any of the errors that you get. Perhaps, the problem lies elsewhere. For us to investigate further, you'll need to provide a description of reproduction steps that will allow us to reproduce.  On top of that, you'll want to include full sip.conf configuration, the dialplan involved and an Asterisk full log including debug and verbose messages. By: Tamás Németh (nice0051) 2014-04-24 12:40:35.951-0500 Hi, I sent your notes to the developers of Zoiper. This is their answer: Hello, You may find our developers comments below: There is no ambiguity in the RFC. It states that the offerer specifies the payload type it wishes to receive. The answerer can only override the payload type that the answerer wishes to receive, there is no provision for the answerer to override the offerer's receive type or for the offerer to override the answerer's receive type. Thus the offerer's receiving payload type is set in the offer and remains unchanged until a new session invalidates the old offer. The answerer's receiving payload type is set in the answer and there is a requirement that the offerer changes its sending payload type to match the answerer's receiving payload type. The wording is "the offerer MUST send with the payload type numbers from the answer" it is not "the offerer MUST send and receive". Furthermore, there is an explicit mention that this can lead to different payload types being used in both directions on Page 6 of the same RFC 3264: Different payload type numbers may be needed in each direction because of interoperability concerns with H.323. Zoiper used to have the same dynamic numbers for the same codecs as Asterisk so issues like this won't happen. It was an accident that they were changed and have already been reverted back in the source so this won't be an issue in subsequent releases of the software. By: Rusty Newton (rnewton) 2014-05-19 08:29:57.150-0500 Thanks. It is good to have them confirm as well that both sides are behaving according to the RFC. I don't have an explanation for the behavior you saw and I am unable to reproduce it. What specific version of Zoiper did you use to reproduce the issue? Is there a newer version you can try? By: Tamás Németh (nice0051) 2014-05-20 15:06:49.832-0500 OK. In spite the fact that I'm not a developer, just an ordinary sysadmin, I tried to interpret the RFC interpretaion of the Zoiper guy by examining some wireshark dumps. So: I assume both Asterisk and Zoiper have TWO charts of payload_type_number to codec mappings: one for encoding and sending audio and another for receiving and decoding. In the SDP data both of them send their RECEIVING mappings and then use the received mapping data to construct the SENDING codec mapping chart. This means that the offerer constructs its SENDING codec mapping from the answerer's RECEIVING mapping and vice versa. Neither party is obliged to change its own RECEIVING mapping to match the other one's SENDING mapping (however the SDP answerer may do so BEFORE sending the SDP answer). In my opinion, the problem is, that Asterisk - even as an offerer - overly tries to align its RECEIVING mapping to the other parties SENDING mapping: Take a look at the attached PCAP file: -In the eighth packet Asterisk (the offerer) tells Zoiper that it can receive ilbc encoded audio with a payload type number of 97. -I the eleventh packet Zoper tells it can receive ilbc audio with a type number of 100, speex audio tagged with number 97, GSM as number 3, etc. Now the Zoiper guy says the according to the RFC, Zoiper sends ilbc with a payload type number of 97 because Asterisk told it to do so. In the meantime however Asterisk had changed its RECEIVING mappings (which it mustn't have done) and misinterprets the received ilbc audio as speex. Both parties send audio according to the RFC but Asterisk does RECEIVING wrong, because being the SDP offerer it mustn't have to alter its RECEIVING codec mapping. In addition Asterisk does this improper mapping change if there is a payload number "collision" between it's own codec mapping table and that of its partner. In Zoiper for Android 1.17.4 for example speex has the payload number of 97 (which is the same as ilbc in Asterisk), in other Zoiper versions, however speex is number 110 and number 97 is unused, so Asterisk doesn't confuse itself by changing its RECEIVING codec mapping. Maybe this mechanism was introduced into Asterisk as a workaround for some buggy VoIP client, but Zoiper as an SDP answerer doesn't change its's RECEIVING mapping according to Asterisk's offer (which is only a recommendation but not mandatory), and coincidently it has a codec mapping "collision" with Asterisk, and this leads to the confusion. Please show this comment to a developer because I worked on it very much but don't trust me: I'm neither a developer nor a SIP/SDP/RTP expert :-) By: Tamás Németh (nice0051) 2014-05-30 09:36:00.774-0500 Dear Asterisk developers. Did you read the comment above? By: Rusty Newton (rnewton) 2014-06-12 11:44:04.347-0500 Beyond the assumptions you are making about how Asterisk operates internally (I don't have much of an idea either) what you are saying makes sense. I don't believe there is an RFC violation based on what we know so far, but I do think there is a bug based on Asterisk's behavior. Are you still using 11.8.0? Can you please test in 11.10.0? ASTERISK-23279 and ASTERISK-22789 may be related. They were fixed in 11.9.0 Please make sure to completely recompile and re-install, then test again. Verify chan_sip was rebuilt of course. By: Rusty Newton (rnewton) 2014-06-27 10:14:42.123-0500 I'll leave this open for a couple more weeks to give you time to test before closing this out if we don't hear back from you.  Thanks! By: Tamás Németh (nice0051) 2014-06-28 04:08:48.744-0500 I still think this might by an Asterisk bug. Can you analyze it in more detailed? BTW, sorry for being so late with this comment, but openSUSE didn't release Asterisk 11.10 until now. Too bad, Asterisk 11.10 still produces this symptom with that particular Zoiper version, however Zoiper developers released a new verison with a workaround for this problem. By: Rusty Newton (rnewton) 2014-07-01 16:19:53.330-0500 I believe it is a bug. However being a bug that apparently isn't seen in other clients (I couldn't find any other reports of this issue), and now only in an older Zoiper version (that has been updated with a workaround), it'll likely be low priority to be investigated and fixed. By: Joshua C. Colp (jcolp) 2017-12-18 10:33:17.070-0600 I'm suspending this issue as Asterisk 11 is now end of life, chan_sip has entered a community supported state, and Zoiper has implemented a workaround. When combined I don't think anyone in the community will actively work on this. If you disagree and would still like it open feel free to comment and it will automatically reopen.