[Freeswitch-users] Loopback and bypass_media

[Phillip Jones]

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.

>>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

On Wed, Aug 12, 2009 at 10:22 AM, Rupa Schomaker<rupa at rupa.com> wrote:
> perhaps we need to add some syntax + logic to originate:
>
> application="originate"
> data="(sofia/foo/bar|sofia/baz/bar),(sofia/foo/yum|sofia/baz/yum)"
>
> This would acomplish the equiv of
>
> loopback/bar,loopback/yum  where bar and yum are then further expanded
> in the dialplan as
>
> sofia/foo/bar|sofia/baz/bar and sofia/foo/yum|sofia/baz/yum
>
> except that the threads of execution are handled directly by
> originate.  I'm not sure that is really the "solution" since each ()
> group would still have to be a separate thread to run independently.
>
> To me, loopback is the way to accomplish this issue (how I've done it
> with the same requirements that you have) since all the hard work is
> layered and works.  The problem is that you require bypass_media which
> doesn't play nice with loopback.
>
> Perhaps have an on answer hook that tries to enable bypass media
> (re-invite) after the call is setup?
>
> On Wed, Aug 12, 2009 at 8:29 AM, Phillip Jones<pjintheusa at gmail.com> wrote:
>> David / Michael - thanks for your your replies. The SoftIVR example is
>> particularly useful. Must admit though - I was hoping not to have to
>> do any custom stuff at this stage.
>>
>> It does appear there is no method to do this by staking bridge lines
>> so I will put an issue in jira to try and get loopback working with
>> bypass_media.
>>
>> In the meantime I will also start looking to build a custom bridging
>> app. As I said though - not a road I wanted to go down.
>>
>> Thanks for your help!
>>
>>
>> Phillip Jones
>>
>> On Tue, Aug 11, 2009 at 6:13 PM, Michael Giagnocavo<mgg at giagnocavo.net> wrote:
>>> It's also simple enough to write a plugin in one of the scripting languages to add an app to do exactly what you want...
>>>
>>> -----Original Message-----
>>> From: freeswitch-users-bounces at lists.freeswitch.org [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of David Knell
>>> Sent: Tuesday, August 11, 2009 1:55 PM
>>> To: freeswitch-users at lists.freeswitch.org
>>> Subject: Re: [Freeswitch-users] Loopback and bypass_media
>>>
>>> Just to add my $0.02-worth (if you're feeling generous..) - I don't
>>> think that the dialplan is expressive enough to do what's needed here,
>>> and that's where the trouble's coming from.  It's not enormously tricky
>>> to build a generic "dial this set of numbers according to these rules"
>>> service using something hanging off the event socket - there's a writeup
>>> here: http://www.softivr.com/wiki/index.php/Find_me showing how it could
>>> be done on SoftIVR.
>>>
>>> To roll something similar yourself using the event socket, you'd need to
>>> map the dial function to 'originate', bridge to (IIRC) 'uuid_bridge',
>>> and have some way of passing messages around between the threads
>>> handling the different call legs, assuming that you're using one thread
>>> per leg.
>>>
>>> --Dave
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> -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
>