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

[Rusty Newton (JIRA)]

Rusty Newton created ASTERISK-23978:
---------------------------------------

             Summary: Call negotiating iLBC results in speex error messages and one way audio
                 Key: ASTERISK-23978
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23978
             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


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)