[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:all-tabpanel ]

Rusty Newton reassigned ASTERISK-23619:
---------------------------------------

    Assignee:     (was: Rusty Newton)

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