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

Tue Jul 1 12:32:29 CDT 2014

> On July 1, 2014, 12:14 p.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed-trunk/main/rtp_engine.c, lines 578-581
> > <https://reviewboard.asterisk.org/r/3687/diff/3/?file=61632#file61632line578>
> >
> >     Do we need the temp variable or can we just ao2_cleanup(AST_VECTOR_GET())?
> >     
> >     Also is it safe to cleanup the vector items during iteration without removing them?  I'm not sure this is an issue when we are about to free, but wanted to mention anyhow.

I prefer to pull it out into the temp variable, as AST_VECTOR_GET is a macro. Sometimes it is fine to call a macro within a function, other times you're going to get odd results. I'd rather just be safe here.

As far as whether or not you can clean up without removing, yes, you can. Unlike a list, which maintains a pointer to the next element, the vector is traversing an array. It doesn't care if an element in the array is garbage or not, it will just merrily move onto the next location. If someone came along and *used* the value while we were nuking them out (and assuming the ref count went to 0), then it would be 'bad' - hence the locking around the list here.

That being said, rtp_codecs is not reference counted, which means you should not be expecting that the object's lifetime is undetermined. If you are destroying it, it is because it should be destroyed. Period. No one else should be using it at that point in time.

> On July 1, 2014, 12:14 p.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed-trunk/main/rtp_engine.c, lines 704-708
> > <https://reviewboard.asterisk.org/r/3687/diff/3/?file=61632#file61632line704>
> >
> >     We need to remove from the vector.  Also why not ao2_cleanup?
> 
> Corey Farrell wrote:
>     A related thought, maybe we need an AST_VECTOR_EXTRACT(vector, idx) to handle get + remove?

We don't need to remove from the vector. We are explicitly blowing away our reference to the item on the vector, then replacing it with a new item. No removal is necessary, as the item on the vector is just a pointer to the ao2 object.

> On July 1, 2014, 12:14 p.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed-trunk/main/rtp_engine.c, line 848
> > <https://reviewboard.asterisk.org/r/3687/diff/3/?file=61632#file61632line848>
> >
> >     All code assumes that ast_rwlock_(rd|wr)lock(&codecs->codec_lock) will succeed.  Should we be checking the return code?  This question applies through-out rtp_engine.c.

That same comment applies to all of Asterisk. Furthermore, what can we do if the lock fails? You aren't going to get it back. You're up a creek without a paddle :-)

- Matt

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

On July 1, 2014, 11:19 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3687/
> -----------------------------------------------------------
> 
> (Updated July 1, 2014, 11:19 a.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/20140701/3547a91d/attachment-0001.html>