----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3365/#review11239 -----------------------------------------------------------
That Asterisk *needs* audio was not true before. If it is, then we've broken things. When I worked with T.140 realtime text we made it possible to place calls with video and text, no audio. It took a while, but it did work in a few releases. Have no test software at this moment, but if that statement is true we have a problem. - Olle E Johansson On March 16, 2014, 9:36 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3365/ > ----------------------------------------------------------- > > (Updated March 16, 2014, 9:36 p.m.) > > > Review request for Asterisk Developers and Joshua Colp. > > > Repository: Asterisk > > > Description > ------- > > In a perfect world, an Asterisk channel would care very little (if at all) > about the media streams that happened to be related to it. It would merrily > exist as a path of communication between some endpoint and Asterisk, and the > data (which may or may not be media at all!) that flowed (like a stream!) > between the endpoint and Asterisk would be a completely separate concept. > Alas, such is not the world we exist in. Asterisk *needs* audio. As frames. > At a nice periodic rate, please. Strange things happen when it doesn't get it. > > Today, the res_pjsip stack will do some funky things if you give it an offer > with no media. There will be a slew of warnings, some compatibility errors, > strange transcoding attempts, and finally you may get an Answer to the Offer > that contains an audio codec in a video media stream (probably ulaw) - just > because Asterisk *really* wants audio. (Can you please send some with this > video?) > > This is clearly not right. This patch makes it so that res_pjsip_session > looks to see if we have an audio stream (in validate_sdp) and, if not, it > declines the offer. > > I offer this patch in the hopes that it will some day be removed... > > > Diffs > ----- > > /branches/12/res/res_pjsip_session.c 410554 > /branches/12/res/res_pjsip_sdp_rtp.c 410554 > /branches/12/include/asterisk/res_pjsip_session.h 410554 > > Diff: https://reviewboard.asterisk.org/r/3365/diff/ > > > Testing > ------- > > Tests are ongoing. A test has been written that offers only a single video > stream. Prior to this patch; hilarity. With this patch, Asterisk rejects the > offer with a 488. > > > 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
