[asterisk-dev] [Code Review] 3687: media format improvements: Update packetization handling; improve rtp_engine's ast_rtp_codecs handling

[Matt Jordan]

> On July 1, 2014, 12:55 p.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed-trunk/main/rtp_engine.c, line 595
> > <https://reviewboard.asterisk.org/r/3687/diff/4-5/?file=61681#file61681line595>
> >
> >     Would be nice to BUGBUG this procedure so we can audit callers, make them check for/react to error.
> 
> Matt Jordan wrote:
>     Ironically... no one uses it.
>     
>     :-)
>     
>     We *could* just remove it, but theoretically, someone out there could have written their own RTP engine, and they may be relying on this function... so it might be better to keep it.
> 
> Corey Farrell wrote:
>     I have no strong opinion on keeping or removing it, and if no one uses it then audit complete.  Part of me thinks that we should just remove it as dead code, if someone has a custom RTP engine that requires this they can file a bug - then it can be added back with a unit test.  Since we're already making tons of API/ABI changes it's easier to remove now than later.  OTOH it's a 35 line procedure, not a huge deal.
>     
>     Feel free to drop this finding and commit away.

I agree; I'll remove the function.


- Matt


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


On July 1, 2014, 12:43 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3687/
> -----------------------------------------------------------
> 
> (Updated July 1, 2014, 12:43 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch started out as an attempt to fix the BUGBUGs left over packetization calls into rtp_engine; it got a little bit bigger. Things now compile and work (see Testing), so this is a good place to stop before the renaming effort.
> 
> Primarily, this patch does the following:
> (1) Removes ast_rtp_codecs_packetization_set. This call was effectively a NoOp with res_rtp_asterisk/res_rtp_multicast. The various channel drivers now call ast_rtp_codecs_set_framing where appropriate.
> (2) A major overhaul of ast_rtp_codec was done. This includes:
>     (a) Storing the framing on the structure. This allows for the smoother in res_rtp_asterisk to easily get the framing specified without having to do major gyrations.
>     (b) Payload types (which are ao2 ref counted objects) are no longer stored in an ao2_container. This container had two patterns of usage: lookups by an integer key value and iteration. Vectors work well for this type of access and - for relatively small numbers of items (which is generally the case for payload types), are much faster on both counts.
> (3) The 'use_ptime' setting in res_pjsip_sdp_rtp now works. Packetization is also handled a little bit better, as both the RTP engine and format_cap API already do the job of managing the framing.
> 
> A variety of ref leaks were cleaned up as well along the way.
> 
> 
> Diffs
> -----
> 
>   /team/group/media_formats-reviewed-trunk/tests/test_format_cap.c 417724 
>   /team/group/media_formats-reviewed-trunk/res/res_speech.c 417724 
>   /team/group/media_formats-reviewed-trunk/res/res_rtp_asterisk.c 417724 
>   /team/group/media_formats-reviewed-trunk/res/res_pjsip_sdp_rtp.c 417724 
>   /team/group/media_formats-reviewed-trunk/res/res_fax.c 417724 
>   /team/group/media_formats-reviewed-trunk/main/rtp_engine.c 417724 
>   /team/group/media_formats-reviewed-trunk/main/format_cap.c 417724 
>   /team/group/media_formats-reviewed-trunk/main/format.c 417724 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/vector.h 417724 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/rtp_engine.h 417724 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/frame.h 417724 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/format_cap.h 417724 
>   /team/group/media_formats-reviewed-trunk/include/asterisk/format.h 417724 
>   /team/group/media_formats-reviewed-trunk/formats/format_h264.c 417724 
>   /team/group/media_formats-reviewed-trunk/formats/format_h263.c 417724 
>   /team/group/media_formats-reviewed-trunk/channels/chan_skinny.c 417724 
>   /team/group/media_formats-reviewed-trunk/channels/chan_sip.c 417724 
>   /team/group/media_formats-reviewed-trunk/channels/chan_motif.c 417724 
>   /team/group/media_formats-reviewed-trunk/channels/chan_jingle.c 417724 
>   /team/group/media_formats-reviewed-trunk/channels/chan_iax2.c 417724 
>   /team/group/media_formats-reviewed-trunk/channels/chan_h323.c 417724 
>   /team/group/media_formats-reviewed-trunk/channels/chan_gtalk.c 417724 
>   /team/group/media_formats-reviewed-trunk/bridges/bridge_softmix.c 417724 
>   /team/group/media_formats-reviewed-trunk/bridges/bridge_native_rtp.c 417724 
>   /team/group/media_formats-reviewed-trunk/addons/ooh323cDriver.c 417724 
>   /team/group/media_formats-reviewed-trunk/addons/chan_ooh323.c 417724 
> 
> Diff: https://reviewboard.asterisk.org/r/3687/diff/
> 
> 
> Testing
> -------
> 
> Back in February, I wrote a number of single audio stream tests for the PJSIP channel driver. Eventually these will get posted up for review, but the tests cover:
>  * Basic Offer/Answer of different sets of codecs (using a variety of patterns, including allow=all (ew))
>  * Packetization, including use_ptime=yes|no.
>  * AVPF
>  * Preferred codec only (by only specifying a single supported codec), subsets of offers, etc.
> 
> These tests will eventually get put up on another review, but they gave some confidence that the mucking around in the rtp_engine that is done on this patch works.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140702/4d81d204/attachment-0001.html>