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

[NITESH BANSAL (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

NITESH BANSAL updated ASTERISK-20296:
-------------------------------------

    Attachment: codec_negotiation.patch

I have resolved this issue. Please find the patch file attached:
I have added a new function into rtp_engine.c to check for a payload code in the ast_rtp_codecs structure and called this function from bridge_p2p_rtp_write() in res_rtp_asterisk.c, it serves the purpose of checking the incoming payload against the codecs stored on the bridge.

> 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
>    Affects Versions: 11.0.0-beta1
>         Environment: OS: Debian squeeze distribution x86_64 architecture
>            Reporter: NITESH BANSAL
>         Attachments: codec_negotiation.patch
>
>
> 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