> On July 12, 2014, 10:32 p.m., Matt Jordan wrote: > > I'm not sure I understand the problem for your issue description: > > > > "When ast_format_cap_append was replaced with > > ast_format_cap_append_from_cap, the behavior of the original function was > > not preserved. This change introduces > > ast_format_cap_append_compatible_from_cap which reproduces the original > > behavior of ast_format_cap_append and alters the original users of > > ast_format_cap_append to use ast_format_cap_append_compatible_from_cap." > > > > What behavioural difference was changed? Why do we need to switch it back? > > What is the intent of ast_format_cap_append_compatible_from_cap? And why > > wouldn't you just use ast_format_cap_get_compatible? > > > > > > opticron wrote: > The difference in behavior is that ast_format_cap_append_from_cap appends > unconditionally from the source format capability while ast_format_cap_append > checks for compatibility with ast_format_cap_iscompatible before appending > from the source format capability. > > Without switching it back, chan_pjsip now offers codecs to the endpoint > that are not configured in its codec definition and causes one-way audio > where it otherwise would have declined the INVITE. > > It appears that this could be accomplished using > ast_format_cap_get_compatible, ast_format_cap_append_from_cap, and the > allocation of another format cap for each instance. > > opticron wrote: > I could also add an ast_media_type parameter to > ast_format_cap_get_compatible to obtain equivalent functionality: > ast_format_cap_get_compatible(cap1, cap2, cap2, type);
ast_format_cap_append doesn't check for compatibility. In fact, ast_format_cap_append_from_cap calls ast_format_cap_append when it copies the formats over; there's really not difference between the two. Compatibility is determined only via ast_format_cap_iscompatible_format and ast_format_cap_get_compatible. The latter will take two format compatibility structures and compute their joint capabilities. I don't see why ast_format_cap_get_compatible can't be used. As for needing one that takes in a type as well, I don't think that will necessarily be needed. IIRC, PJSIP already maintains its formats for different media streams in different compatibility structures; other channel drivers (such as chan_sip) should already have code that pulls the formats of a particular type out of their joint capability structure. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3763/#review12596 ----------------------------------------------------------- On July 12, 2014, 9:19 p.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3763/ > ----------------------------------------------------------- > > (Updated July 12, 2014, 9:19 p.m.) > > > Review request for Asterisk Developers, Corey Farrell and Matt Jordan. > > > Repository: Asterisk > > > Description > ------- > > When ast_format_cap_append was replaced with ast_format_cap_append_from_cap, > the behavior of the original function was not preserved. This change > introduces ast_format_cap_append_compatible_from_cap which reproduces the > original behavior of ast_format_cap_append and alters the original users of > ast_format_cap_append to use ast_format_cap_append_compatible_from_cap. > > The primary difference in behavior is that ast_format_cap_append_from_cap > appends unconditionally from the source format capability while > ast_format_cap_append checks for compatibility with > ast_format_cap_iscompatible. > > > Diffs > ----- > > team/group/media_formats-reviewed-trunk/res/res_pjsip_session.c 418441 > team/group/media_formats-reviewed-trunk/res/res_pjsip_sdp_rtp.c 418441 > team/group/media_formats-reviewed-trunk/main/format_cap.c 418441 > team/group/media_formats-reviewed-trunk/include/asterisk/format_cap.h > 418441 > team/group/media_formats-reviewed-trunk/channels/chan_sip.c 418441 > team/group/media_formats-reviewed-trunk/addons/chan_ooh323.c 418441 > > Diff: https://reviewboard.asterisk.org/r/3763/diff/ > > > Testing > ------- > > Ensured that calling a channel via Dial() produced the same behavior as trunk. > > > Thanks, > > opticron > >
-- _____________________________________________________________________ -- 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
