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

[Matthew Jordan]

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.
should be forwarded might help here. Right now, I'm having a hard time
envisioning the specific scenario where you have two or more endpoints
providing video to Asterisk and where Asterisk can simply relay the entire
feedback message and not generate the message itself. I could be mistaken,
but it feels like while this could work in a simple two-party core bridge,
there are a lot of other scenarios where this goes wrong quickly.

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.

Matt

-- 
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/8cf0ab5f/attachment.html>