[asterisk-dev] func_jitterbuffer handling of masquerades

[Matthew Jordan]

On Wed, Nov 5, 2014 at 12:24 PM, Joshua Colp <jcolp at digium.com> wrote:
> Corey Farrell wrote:
>
> <snip>
>
>>
>> The change I am proposing is that we always have an active JB after
>> masquerade if either side had one before the masquerade.  So in
>> scenario 1 and 2 listed above this would cause the only active
>> jitterbuffer to remain active after a masquerade.  For situations
>> where both channels have active jitterbuffer, we would always prefer
>> the jitterbuffer settings from clonechan.
>
>
> I'm not sure I agree with that. Local channels aside (as they always
> complicate things) for the moment if I have two channels:
>
> PJSIP/alice
> PJSIP/bob
>
> Following assumptions:
>
> PJSIP/alice has had a jitterbuffer placed on her.
>
> Scenario:
>
> PJSIP/bob masquerades into PJSIP/alice to take her place.
>
> As a deployer would I expect PJSIP/bob to have a jitterbuffer then? No. I
> placed it on PJSIP/alice. Why should it be on PJSIP/bob after this? I don't
> know or care that a masquerade happened. If it is on PJSIP/bob though - how
> do I know a masquerade has happened so I can get rid of it since I don't
> want it there?
>
> I can understand why when Local channels are involved it can make things
> easier but I don't think the resulting behavior would be what people would
> expect or want, and allowing some method to control it confuses people.
>
> That's my feelings about this.
>
> What do others think?
>

I think this scenario is a lot easier in Asterisk 12+.

But I also think Josh is right. Unfortunately, in Asterisk 11-, you
don't really know whether or not the channel being masqueraded into
another is representative of a new path of communication to the same
device or a different device. If it is the same device, you want it to
inherit; if not, you don't. Witness the craziness of the
'AUDIOHOOK_INHERIT' function.

This gets further weird with ConfBridge (unfortunately), which uses
func_jitterbuffer to put a jitterbuffer on each channel that joins.
This works great unless they get masqueraded out of the ConfBridge.
Should the jitterbuffer travel with them at that point? Probably not.

I think when a masquerade occurs, a jitterbuffer must:
 * Assume that it should be destroyed
 * Inform the channel that it was on that it has left the building
 * Re-sync the RTP engine appropriately so that the timestamps/SSRC
are as correct as it can

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