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