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

[Mark Michelson (JIRA)]

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

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

After looking at the code, I wasn't sure so I asked on IRC.

David Vossel, the writer of the code in Asterisk 10 said the reason he thinks that the check for {{asterisk_format}} is there is because of the ulaw format. {{ast_rtp_instance_get_codecs(instance1)->payloads[bridged_payload].rtp_code}} would legitimately be 0 when the payload is ulaw. The extra check for {{asterisk_format}} was to account for this. He agrees that your change to find the codec in the ao2_container (i.e. your original patch) would do the trick here and satisfy backwards compatibility.

Kevin Fleming stated that there should be a restriction to only passing Asterisk formats though since if the p2p bridge breaks (e.g. for hold), then Asterisk would not be able to communicate directly with one of the endpoints. I'm not sure that would be an issue though since Asterisk could just communicate using one of the negotiated Asterisk formats instead of the non-Asterisk format currently being used by the endpoint.

In all, I think your original patch is the way to go here. If it turns out to cause problems, we can re-visit the possibility of restricting p2p bridges to Asterisk formats, but I don't think that will happen.

> 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