[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=219388#comment-219388 ] 

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

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.

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