> 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<[email protected]> 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 > [email protected] > > > > > 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<[email protected]> wrote: >>> On Wed, Aug 12, 2009 at 10:22 AM, Phillip >>> Jones<[email protected]> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
