> On June 30, 2014, 2:27 p.m., Corey Farrell wrote:
> > /team/group/media_formats-reviewed-trunk/channels/chan_sip.c, lines
> > 10088-10090
> > <https://reviewboard.asterisk.org/r/3687/diff/1/?file=61242#file61242line10088>
> >
> > Why switch these to be undefined values?
>
> Matt Jordan wrote:
> Compilation issue. Both the vector and the rwlock complained about
> missing braces around initializer:
>
> chan_sip.c: In function ‘process_sdp’:
> chan_sip.c:10084:9: error: missing braces around initializer
> [-Werror=missing-braces]
> chan_sip.c:10084:9: error: (near initialization for
> ‘newaudiortp.payloads’) [-Werror=missing-braces]
>
>
> Granted, I might be able to initialize them all to 0 by explicitly
> specifying properties of the vector/lock, but that feels wrong - generally, I
> shouldn't be doing that to 'private' members of a struct. Plus, these
> variables are not used without being initialized - their initialization
> happens nearly immediately on line 10123.
>
> If there's a way to initialize them to 0 that I'm missing, I'd be happy
> to restore that however.
>
>
>
> Corey Farrell wrote:
> If one or more of the initializations on line 10123 fail, we "goto
> process_sdp_cleanup;" which will run ast_rtp_codecs_payloads_destroy on the
> undefined values. Maybe switch to ast_calloc?
>
> Another option would be to have create a macro to allow:
> struct ast_rtp_codecs newvideortp = AST_RTP_CODECS_NULL;
>
> AST_RTP_CODECS_NULL would need to use similar macro's to construct the
> NULL vector/mutex fields. I agree that we don't want to have chan_sip.c
> explicitly setting 'private' fields, the header which defines those fields
> should do it for us.
Ew. Yeah, that would be bad.
So this worked:
#define AST_RTP_CODECS_NULL \
{ .payloads = { 0, }, .framing = 0, .codecs_lock = AST_RWLOCK_INIT_VALUE, }
struct ast_rtp_codecs foo = AST_RTP_CODECS_NULL;
So I'll go with that.
- Matt
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3687/#review12393
-----------------------------------------------------------
On June 28, 2014, 11:31 p.m., Matt Jordan wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3687/
> -----------------------------------------------------------
>
> (Updated June 28, 2014, 11:31 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 417585
> /team/group/media_formats-reviewed-trunk/res/res_speech.c 417585
> /team/group/media_formats-reviewed-trunk/res/res_rtp_asterisk.c 417585
> /team/group/media_formats-reviewed-trunk/res/res_pjsip_sdp_rtp.c 417585
> /team/group/media_formats-reviewed-trunk/res/res_fax.c 417585
> /team/group/media_formats-reviewed-trunk/main/rtp_engine.c 417585
> /team/group/media_formats-reviewed-trunk/main/format_cap.c 417585
> /team/group/media_formats-reviewed-trunk/main/format.c 417585
> /team/group/media_formats-reviewed-trunk/include/asterisk/vector.h 417585
> /team/group/media_formats-reviewed-trunk/include/asterisk/rtp_engine.h
> 417585
> /team/group/media_formats-reviewed-trunk/include/asterisk/frame.h 417585
> /team/group/media_formats-reviewed-trunk/include/asterisk/format_cap.h
> 417585
> /team/group/media_formats-reviewed-trunk/include/asterisk/format.h 417585
> /team/group/media_formats-reviewed-trunk/formats/format_h264.c 417585
> /team/group/media_formats-reviewed-trunk/formats/format_h263.c 417585
> /team/group/media_formats-reviewed-trunk/channels/chan_skinny.c 417585
> /team/group/media_formats-reviewed-trunk/channels/chan_sip.c 417585
> /team/group/media_formats-reviewed-trunk/channels/chan_motif.c 417585
> /team/group/media_formats-reviewed-trunk/channels/chan_jingle.c 417585
> /team/group/media_formats-reviewed-trunk/channels/chan_iax2.c 417585
> /team/group/media_formats-reviewed-trunk/channels/chan_h323.c 417585
> /team/group/media_formats-reviewed-trunk/channels/chan_gtalk.c 417585
> /team/group/media_formats-reviewed-trunk/bridges/bridge_softmix.c 417585
> /team/group/media_formats-reviewed-trunk/bridges/bridge_native_rtp.c 417585
> /team/group/media_formats-reviewed-trunk/addons/ooh323cDriver.c 417585
> /team/group/media_formats-reviewed-trunk/addons/chan_ooh323.c 417585
>
> 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
>
>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
