[asterisk-bugs] [JIRA] (ASTERISK-21981) Pass-through support for Opus and VP8 formats
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Tue Jul 23 11:33:04 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-21981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208157#comment-208157 ]
Matt Jordan commented on ASTERISK-21981:
----------------------------------------
{quote}
According to draft-ietf-payload-rtp-opus, almost all of the parameters you can negotiate are put in a single fmtp attribute (e.g., "a=fmtp:101 stereo=1; sprop-stereo=1"). My module takes care of this by making use of strstr to check for a parameter in order to parse it. The problem is that in Asterisk, if fmtp parameters are separated by whitespaces (as in the example I put before) only the first one is passed to the parser. Removing the whitespace ("a=fmtp:101 stereo=1;sprop-stereo=1") passes the whole string to the parser successfully. Is this a known issue/limitation? I guess this can be blamed on the sscanf format that is used to parse the fmtp in chan_sip.c in the first place.
{quote}
Yup, that's a bug. With the way the sscanf is written, the "%s" specifier will hit the first whitespace character and stop. That can be pretty easily fixed to scan a particular number of characters or until we hit a null termination.
{quote}
I then tried a simple scenario, where an Opus compliant softphone (Alice) calls another one (Bob) through Asterisk. I've noticed that my module parses the parameters correctly, but Asterisk doesn't make use of the parameters provided by Alice in order to generate the parameters for the call towards Bob: the defaults I placed there are still generated. This makes sense if we consider that it's Alice's opus_attr structure that is updated when parsing, while to generate the SDP for Bob a different opus_attr (related to that leg) is going to be used, but shouldn't the original opus_attr for Alice going to be used as a basis to generate the offer to send Bob in the current Asterisk architecture for passthrough codecs? Or am I missing something in the format modules specification that may help in that sense?
{quote}
Hm. That isn't what's supposed to happen :-)
The format attributes presented by Alice (which are stored on her {{ast_channel}}) should be pulled over to the Bob channel during {{ast_request}}. When the INVITE request is sent in {{sip_call}}, the format attributes should be added to the SDP - but those format attributes should have the settings from Alice by virtue of {{ast_request}. It's possible that it is something subtle in the format attribute copying or in the SDP generation - a more in depth code review may help with that.
I definitely think this is ready for Review Board :-)
> Pass-through support for Opus and VP8 formats
> ---------------------------------------------
>
> Key: ASTERISK-21981
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-21981
> Project: Asterisk
> Issue Type: New Feature
> Security Level: None
> Components: Formats/General
> Reporter: Tzafrir Cohen
> Attachments: asterisk_opus+vp8_passthrough_20130718.patch, asterisk_opus+vp8_passthrough.patch
>
>
> Following discussions on the asterisk-dev mailing list, I create a bug for Lorenzo Miniero to merge the parts of his WebRTC codecs patch that can be merged.
> See:
> http://lists.digium.com/pipermail/asterisk-dev/2013-May/060388.html
> http://lists.digium.com/pipermail/asterisk-dev/2013-May/060419.html
> (If this is a duplicate: sorry for the noise. I failed to find it)
> Including this patch should allow for a review in time before the Asterisk 12 deadline. I marked this as "major" as I think this is an important feature missing in Asterisk right now. Supporting the formats is the least we can do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list