On Wed, Feb 18, 2015 at 7:02 PM, Matthew Jordan <mjor...@digium.com> wrote:
> > > On Tue, Feb 17, 2015 at 9:24 AM, Nitesh Bansal <nitesh.ban...@gmail.com> > wrote: > >> Hi Matt, >> >> It seems that my reply was lost in the pile of mails during holiday >> period? >> >> Is there any update on this? >> >> Regards, >> Nitesh >> >> On Tue, Dec 30, 2014 at 5:54 PM, Nitesh Bansal <nitesh.ban...@gmail.com> >> wrote: >> >>> Hi Matt, >>> >>> The scenario which i have in my mind is as follows: >>> >>> WebRTC browser -----------> (Inbound) Asterisk --------------> SIP >>> phone (VP.8 video call) >>> >>> Since this is a webRTC call, RTP stream will be encrypted between Web >>> Browser and Asterisk (call leg 1) and in our case and call leg between >>> Asterisk and SIP phone(call leg 2) can be secured/unsecured depending on >>> the config. Since one leg of the call is encrypted, there can't be a P2P >>> bridge. >>> But the fact is that asterisk isn't the source of the video, it is just >>> forwarding the RTP stream. >>> In this case, i believe it makes sense to forward RTCP FB messages like >>> NACK, PLI and FIR. >>> NACKs -- Asterisk can request the retransmission of video frames >>> PLI/FIR -- Asterisk can request image refresh from either endpoint >>> >>> To avoid the RTCP FB forwarding in other scenarios, we can probably make >>> it as config enabled feature. >>> >>> > It wasn't really lost in the pile. I'm just not sure I have anything else > to say that I haven't already said. > > It isn't that your idea won't work - for your specific scenario, it will > absolutely work. But I can't see how it universally applicable, and the > code is going to be intrusive enough that I'm not sure I'd want a > non-universal solution. > > In your outlined scenario, Asterisk is not forwarding the media. It may > seem like it - but it isn't. It is taking the RTP packet, putting it into > an AST_FRAME_VIDEO (along with AST_FRAME_VOICE most likely as well), > passing them over a bridge - which may go to more than one party - > re-packaging it in RTP, and passing it along. Yes, it isn't transcoding it, > but that doesn't mean that there aren't scenarios where from one party's > perspective, the media from Asterisk has remained the same, while in > reality some other party is now sending it media. > Sorry, my attempt to remove the reply sections backfired. This should have been removed in the original e-mail. :-) > > > I could be wrong, and there may be a graceful way to support this in your > scenario that doesn't violate Asterisk's model of channels and acting as a > B2BUA. But I suspect that multi-party bridges, call hold, redirecting > channels in/out of bridges, Local channels, and more will cause lots of > problems for the implementation that you have in mind. > -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
-- _____________________________________________________________________ -- 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
