[asterisk-bugs] [JIRA] Commented: (ASTERISK-20296) In certain scenarios, asterisk can send rtp in an unsupported payload type to an endpoint

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-20296:
----------------------------------------

Nope, actually Michael Young opened it again (thanks :-))

> In certain scenarios, asterisk can send rtp in an unsupported payload type to an endpoint
> -----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20296
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20296
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 11.0.0-beta1
>         Environment: OS: Debian squeeze distribution x86_64 architecture
>            Reporter: NITESH BANSAL
>         Attachments: codec_negotiation.patch, codec_negotiation.patch, CODEC_NEGOTIATION_SIPP_SCRIPTS_AND_SIP_CONF_2.tar.gz, CODEC_NEGOTIATION_SIPP_SCRIPTS_AND_SIP_CONF.tar.gz
>
>
> SIP caller A supports alaw/ulaw
> Asterisk is configured to support alaw,ulaw,g729 and places all 3 in the offer to B
> SIP called B supports g729,alaw,ulaw putting all 3 in the 200 OK.
> Asterisk sees that there is one common codec between A and B, it sets up a packet to packet bridge
> If B sends audio in G.729, it gets forwarded to A without transcoding which is expecting alaw/ulaw. Asterisk does not check the incoming payload from the peer and forwards to another peer
> even if the payload received was different from the payload expected on the bridge.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira