[asterisk-dev] Adding the support for NACK in asterisk

[Matthew Jordan]

On Wed, Feb 18, 2015 at 7:02 PM, Matthew Jordan <mjordan at digium.com> wrote:

>
>
> On Tue, Feb 17, 2015 at 9:24 AM, Nitesh Bansal <nitesh.bansal at 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.bansal at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150218/d5289945/attachment.html>