[asterisk-bugs] [JIRA] (ASTERISK-23619) Call negotiating iLBC results in speex error messages and one way audio

[Tamás Németh (JIRA)]

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

Tamás Németh commented on ASTERISK-23619:
-----------------------------------------

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 :-)

> Call negotiating iLBC results in speex error messages and one way audio
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-23619
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23619
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling
>    Affects Versions: 11.8.0
>         Environment: Linux
>            Reporter: Tamás Németh
>            Assignee: Tamás Németh
>         Attachments: bad_android.pcap
>
>
> 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.



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