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

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

Hi,

I sent your notes to the developers of Zoiper. This is their answer:

Hello,

You may find our developers comments below:

There is no ambiguity in the RFC. It states that the offerer specifies the payload type it wishes to receive. The answerer can only override the payload type that the answerer wishes to receive, there is no provision for the answerer to override the offerer's receive type or for the offerer to override the answerer's receive type.

Thus the offerer's receiving payload type is set in the offer and remains unchanged until a new session invalidates the old offer.

The answerer's receiving payload type is set in the answer and there is a requirement that the offerer changes its sending payload type to match the answerer's receiving payload type. The wording is

"the offerer MUST send with the payload type numbers from the answer"

it is not "the offerer MUST send and receive".

Furthermore, there is an explicit mention that this can lead to different payload types being used in both directions on Page 6 of the same RFC 3264:

Different payload type numbers may be needed in each direction because of interoperability concerns with H.323.

Zoiper used to have the same dynamic numbers for the same codecs as Asterisk so issues like this won't happen. It was an accident that they were changed and have already been reverted back in the source so this won't be an issue in subsequent releases of the software.

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