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

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-23619:
-----------------------------------------

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 "fixed" zoiper version, it'll likely be low priority to be investigated and fixed.

> 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, 11.10.2
>         Environment: Linux
>            Reporter: Tamás Németh
>            Assignee: Rusty Newton
>         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)