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

Mark Michelson (JIRA) noreply at issues.asterisk.org
Tue Sep 4 16:25:07 CDT 2012


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

Mark Michelson commented on ASTERISK-20296:
-------------------------------------------

I've had a look over, and I see how checking {{static_RTP_PT}} is incorrect. Between Asterisk 10 and 11, the internal storage for codec payloads changed from an array to an ao2 container. It appears that as a result of this conversion, the semantics of checking compatibility in bridge_p2p_rtp_write() changed for the worse.

Here's what the Asterisk 10 code looked like:

{code}
if (!(ast_rtp_instance_get_codecs(instance1)->payloads[bridged_payload].rtp_code) &&
    !(ast_rtp_instance_get_codecs(instance1)->payloads[bridged_payload].asterisk_format)) {
        return -1;
}
{code}

Your change takes into account the first condition of the if statement. I'm not sure that the second condition is satisfied though. I *think* that an easy way to satisfy both conditions is just to make a single call to 

{code}
ast_rtp_codecs_get_payload_format(ast_rtp_instance_get_codecs(instance1), bridged_payload)
{code}

This will first search for the payload type using the same search algorithm that your patch provides. It then also checks that the payload type found is an asterisk_format. I believe this will give the same semantics that the code in Asterisk 10 provided. What do you think?

> 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



More information about the asterisk-bugs mailing list