[Freeswitch-users] Loopback and bypass_media

[Phillip Jones]

> The reason it works when you wait 3 seconds is that mod_loopback bails
> out of the equation as soon as it detects a bridge.
> It'll call switch_ivr_uuid_bridge() and you'll end up with 2 sofia
> channels.

Is there a hook that is fired when when that switch_ivr_uuid_bridge()
successfully executes? So the uuid_media off is called on the
appropriate sofia channels? Is "api_after_bridge" behaving correctly -
should that only be called on the sofia channels and not the loopback?
Is it being fired to early?



On Thu, Aug 13, 2009 at 4:54 PM, Mathieu Rene<mrene_lists at avgs.ca> wrote:
> Hi All,
>
> The reason it works when you wait 3 seconds is that mod_loopback bails
> out of the equation as soon as it detects a bridge.
> It'll call switch_ivr_uuid_bridge() and you'll end up with 2 sofia
> channels.
>
> Now the reason why you can't do uuid_media over a loopback channel is
> because it doesn't pass on SWITCH_MESSAGE_INDICATE_MEDIA and
> SWITCH_MESSAGE_INDICATE_NOMEDIA onto the underlying channel.
> The handler for those two events require accessing channel variables
> on the both channels to get the ip+port of where the audio should go
> through, so that mod_sofia can send a re-invite.
> Since mod_loopback is a completely different channel, it has its own
> channel variables, independent from mod_sofia (provided you have sofia
> channels on both side).  That's why even sofia<>loopback won't do
> bypass media.
>
> On another note, mod_sofia will behave differently when it detects its
> being bridge with another sofia channel, providing optimizations when
> both call legs are SIP.
>
> My personal opinion is not to use mod_loopback unless absolutely
> necessary, FreeSWITCH's core is very flexible and there's often a
> (better) way than using mod_loopback.
>
> Mathieu Rene
> Avant-Garde Solutions Inc
> Office: + 1 (514) 664-1044 x100
> Cell: +1 (514) 664-1044 x200
> mrene at avgs.ca
>
>
>
>
> On 13-Aug-09, at 6:59 PM, Phillip Jones wrote:
>
>> Rupa / all,
>>
>> Just a quick follow up to this.
>>
>> This is appears to a timing issue. If I try and do a "uuid_media off +
>> uuid"  in  "api_after_bridge"  it fails with "CHAN_NOT_IMPLEMENTED"
>> and  the call is dropped.
>>
>> If appears to be trying to do a SIP reinvite on the loopback channel
>> which is of course just about to / has disappear/ed.
>>
>> So I tried this, after the call is established, at the commend line, I
>> do "show calls" and using the uuid shown, type "uuid_media off  uuid".
>> The SIP REINVITE is issued and works.
>>
>> I think the switch_ivr_nomedia function in switch_ivr_c is getting the
>> loopback uuid when it calls "other_uuid =
>> switch_channel_get_variable(channel, SWITCH_BRIDGE_VARIABLE)"
>>
>> That's why the SIP REINVITE fails.
>>
>> So... in api_after_bridge I issue:
>>
>> "sched_api", "+3 none uuid_media off " + uuid. This calls the
>> switch_ivr_nomedia function 3 seconds after the calls bridge is
>> established.
>>
>>
>> And it works, Not nice - not scalable or production ready - but the
>> SIP-REINVITE is successful and at least now I understand what is going
>> on.
>>
>> Make sense?
>>
>> Thanks
>>
>>
>> Phil
>>
>>
>> On Wed, Aug 12, 2009 at 12:21 PM, Rupa Schomaker<rupa at rupa.com> wrote:
>>> On Wed, Aug 12, 2009 at 10:22 AM, Phillip
>>> Jones<pjintheusa at gmail.com> wrote:
>>>> Hi there,
>>>>
>>>>>> application="originate" data="(sofia/foo/bar|sofia/baz/bar),
>>>>>> (sofia/foo/yum|sofia/baz/yum)"
>>>>
>>>> I agree. However, perhaps the ideal is not to specify the carriers
>>>> at
>>>> this level, as carriers are added and removed fairly often as
>>>> costings
>>>> change. So it would be nice to have some sort of proxy that resolves
>>>> to a list of carriers:
>>>>
>>>> application="originate" data="sofia/MyCarriers/bar,sofia/
>>>> MyCarriers/yum"
>>>
>>>> <MyCarriers>
>>>> <action application="carrier" data="sofia/foo"/>
>>>> <action application="carrier" data="sofia/baz"/>
>>>> <action application="carrier" data="sofia/etc"/>
>>>> </MyCarriers>
>>>>
>>>>
>>>> or something similar. This would achieve the same as loopback in
>>>> this
>>>> use case but without dangers of looping? Complicated stuff though.
>>>
>>> Well, that is all done by mod_lcr.  I was simplifying to narrow down
>>> to just originate.
>>>
>>> First we need to see if this is worth pursuing over fixing
>>> (modifying,
>>> whatever) loopback to handle bypass media.  If it is, then I'll
>>> modify
>>> mod_lcr to deal with the situation in question (comma or pipe sep
>>> list
>>> of numbers to call.  mod_lcr would then group as appropriate).
>>>
>>> Right now, my bridge is setup in a small javascript script that
>>> builds
>>> the appropriate dialstring (using loopback for external calls, user/
>>> for internal calls) and then when doing the loopback call to mod_lcr
>>> to get the dialstring with all providers in the right order.
>>>
>>>>>> Perhaps have an on answer hook that tries to enable bypass media
>>>>>> (re-invite) after the call is setup?
>>>>
>>>> That's a good idea - I will look into that.
>>>>
>>>>
>>>> Thanks again.
>>>>
>>>>
>>>> Phillip
>>>
>>> Let us know how it works for you...
>>>
>>> --
>>> -Rupa
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>