[asterisk-dev] [Code Review] 2723: Add pass through support for both VP8 and Opus

Joshua Colp reviewboard at asterisk.org
Wed Aug 21 09:24:51 CDT 2013



> On Aug. 20, 2013, 11:10 a.m., Joshua Colp wrote:
> > /trunk/channels/chan_sip.c, line 12855
> > <https://reviewboard.asterisk.org/r/2723/diff/4/?file=44220#file44220line12855>
> >
> >     As the max packet size is a combination of all formats involved it should be the *lowest* not the highest.
> 
> Matt Jordan wrote:
>     I was thinking that what you were informing the remote endpoint was the largest packet size you may send them, which would be the highest of all of the combined formats. 
>     
>     {quote}
>           a=maxptime:<maximum packet time>
>     
>              This gives the maximum amount of media that can be encapsulated
>              in each packet, expressed as time in milliseconds. 
>     {quote}
>     
>     Wouldn't we want to tell the endpoints that amongst codecs A, B, and C, the largest packet size is max(A,B,C), not min(A,B,C)?

Messy attribute is messy. Since this applies to all codecs at media level if I am using codec A which has a max of 60ms and codec B which has a max of 120ms then if codec A is used the maximum amount of media we accept that can be encapsulated is not 120ms, it's 60ms. Now... would the Asterisk core actually CARE if we received 120ms? Probably not. That's my thinking.


- Joshua


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2723/#review9442
-----------------------------------------------------------


On Aug. 19, 2013, 11:05 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2723/
> -----------------------------------------------------------
> 
> (Updated Aug. 19, 2013, 11:05 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Mark Michelson.
> 
> 
> Bugs: ASTERISK-21981
>     https://issues.asterisk.org/jira/browse/ASTERISK-21981
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Note: This patch was written by Lorenzo Miniero. I know he's at the IETF this week, but I figured we could get the formal code review going for him :-)
> 
> This patch adds pass through support for Opus and VP8. That includes:
> * Format attribute negotiation for Opus. Note that unlike some other codecs, the draft RFC specifies having spaces delimiting the attributes in addition to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in chan_sip, so a small tweak was also included in this patch for that.
> * A format attribute negotiation module for Opus
> * Fast picture update for VP8. Since VP8 uses a different RTCP packet number than FIR, this really is specific to VP8 at this time. Ideally this would be more generic and flexible for user preferences and other video codecs, but that could be done at a latter date.
> 
> The only part of this work that I did was port over the fast picture update code to chan_pjsip. I *think* that chan_pjsip will still suck out the attributes in res_pjsip_sdp_rtp, but I could be mistaken (Josh?)
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_pjsip.c 396942 
>   /trunk/channels/chan_sip.c 396942 
>   /trunk/include/asterisk/format.h 396942 
>   /trunk/include/asterisk/opus.h PRE-CREATION 
>   /trunk/main/channel.c 396942 
>   /trunk/main/format.c 396942 
>   /trunk/main/frame.c 396942 
>   /trunk/main/rtp_engine.c 396942 
>   /trunk/res/res_format_attr_opus.c PRE-CREATION 
>   /trunk/res/res_pjsip_sdp_rtp.c 396942 
>   /trunk/res/res_rtp_asterisk.c 396942 
> 
> Diff: https://reviewboard.asterisk.org/r/2723/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130821/8c20a163/attachment.htm>


More information about the asterisk-dev mailing list