[asterisk-bugs] [JIRA] (ASTERISK-23619) RTP codec mismatch

[Rusty Newton (JIRA)]

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

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

bq. The last line is the important one in this case, your asterisk version is not following the standard.

I've checked the pcap against the RFC, including your excerpt there. Asterisk is following the RFC and your pcap demonstrates that. 

{quote}
 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.
{quote}

In your pcap, the 200 OK from Zoiper (the answer) specifies a payload type of 100 for iLBC (which is different than the 97 specified by Asterisk). Asterisk does in fact send RTP with payload type 100 (from the answer), following the RFC.

Therefore, I'm confused why the guys at Zoiper or you feel that Asterisk is not following the RFC here?

I did note that the offer from Asterisk specifies payload type 97, and Zoiper ends up sending with payload type 97 instead of the 100 that they specify in their own answer.  The developer who assisted me in looking into this couldn't immediately find where that behavior is specified in the RFC . However, In my own testing with Zoiper clients, using your configuration, I saw the same behavior (as far as payload types goes), but my calls work fine and I don't see any of the errors that you get.

Perhaps, the problem lies elsewhere. For us to investigate further, you'll need to provide a description of reproduction steps that will allow us to reproduce.  On top of that, you'll want to include full sip.conf configuration, the dialplan involved and an Asterisk full log including debug and verbose messages.

> RTP codec mismatch
> ------------------
>
>                 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
>         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)