[Freeswitch-users] Best way to bridge 2 calls with LCR?

Tue Jul 21 13:05:22 PDT 2009

Now I understand! thank you very much for your explanation, very clear!

On Tue, Jul 21, 2009 at 2:21 PM, Rupa Schomaker <rupa at rupa.com> wrote:

> Well, the "as xml" is something I've been meaning to do, so I'm gonna get
> that checked in today sometime anyway.  If you want to do any programmatic
> processing of the lcr data, the as xml is the way to go rather than parsing
> the strings.
>
> As for originate + lcr....  You can use the loopback endpoint and do it all
> in the dialplan:
>
> originate loopback/firstnumber secondnumber
>
> This will hit your dialplan with firstnumber first which you can lcr
> route.  Then when that call establishes, it'll hit the dialplan with the
> second number which will also be routed through lcr.
>
> Is that more what you are looking for?
>
> This way all the 'routing' logic can be done via the dialplan.
>
>
> On Tue, Jul 21, 2009 at 1:00 PM, Nicolas Brenner <nicolas at medularis.com>wrote:
>
>> Thank you very much for the offer, but I don't want to bother you with
>> this.
>>
>> I can just parse the string returned by lcr and get the gateway, that's
>> all I really need to create my complete originate command.
>>
>> I am using the socket api because it is easier for me to understand how to
>> do it, nevertheless I'd really like to know how to do it with the dialplan.
>>
>> What I don't understand very well about using the dialplan for this, is
>> how to do the first originate command (which I need to do using the socket
>> api). What puzzles me is that according to the originate syntax, I need to
>> use an extension or call an application, yet for the first call I would have
>> to use a dummy extension as I only need to hit the dialplan section that
>> calls lcr once to originate the first call with an extension that hits the
>> section of the dialplan where lcr gets called again and the calls get
>> bridged.
>>
>> I'm thinking something like this:
>>
>> 1) call originate from socket api to hit dialplan section that does all
>> the work (this originate command is what I don't understand, is there
>> another way of "hitting the dialplan" besides calling originate?)
>>
>> 2) hit dialplan section which calls lcr for first number and bridges to an
>> extension
>>
>> 3) the extension calls lcr fir the second number and originates the second
>> call
>>
>> On steps 2 and 3 I could just use set data to set the additional variables
>> I need. The first step is what troubles me.
>>
>>
>> Thank you!
>>
>>
>> Nicolas
>>
>>
>> On Tue, Jul 21, 2009 at 12:54 PM, Rupa Schomaker <rupa at rupa.com> wrote:
>>
>>> Ok, if you want to do it from the socket api, then I need to make a 'as
>>> xml' option to mod_lcr and give you lcr_auto_route as one of the nodes in
>>> the returned xml.  Then you can do your own substitution in the originate
>>> line...  In that case, you'd call lcr twice and do:
>>>
>>> originate lcr_auto_route1 &bridge(lcr_auto_route2)
>>>
>>> How soon do you need this?
>>>
>>>
>>> On Tue, Jul 21, 2009 at 11:27 AM, Nicolas Brenner <nicolas at medularis.com
>>> > wrote:
>>>
>>>> That looks like a good way to go about it.
>>>>
>>>> How can I access channel variables through the socket using the api? I
>>>> mean, how do I recover the value of ${lcr_auto_route}? I would need to add
>>>> some other variables, like ignore_early_media=true and a uuid that 'links'
>>>> the two calls so I can track it listening for events.
>>>>
>>>> Thanks!
>>>>
>>>> Nicolas
>>>>
>>>>
>>>> On Tue, Jul 21, 2009 at 11:43 AM, Rupa Schomaker <rupa at rupa.com> wrote:
>>>>
>>>>> lcr api command doesn't really return a usable dialstring (it was
>>>>> originally done for debug purposes).  I could add an "as xml" option if
>>>>> needed...
>>>>>
>>>>> Anyway, to do this from the dialplan:
>>>>>
>>>>> remember that originate's usage is:
>>>>>
>>>>> -USAGE <call url> <exten>|&<application_name>(<app_args>) [<dialplan>]
>>>>> [<context>] [<cid_name>] [<cid_num>] [<timeout_sec>]
>>>>>
>>>>> so, the first argument is the call url and the second would be an
>>>>> extension. so:
>>>>>
>>>>> 1) execute lcr for the first leg of the call
>>>>> 2) execute originate with:
>>>>>
>>>>> originate ${lcr_auto_route} extension
>>>>>
>>>>> extension just needs to match something in your dialplan.
>>>>>
>>>>> In extension, you'd do another lcr lookup and then bridge to that leg's
>>>>> ${lcr_auto_route} value.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 21, 2009 at 10:35 AM, Nicolas Brenner <
>>>>> nicolas at medularis.com> wrote:
>>>>>
>>>>>> I would like to originate 2 calls from FS and then bridge them.
>>>>>> There's no incoming call so I think there's no dialplan involved.
>>>>>> What I'd like to do now is apply lcr rules to these calls. I've come
>>>>>> up with 2 options so far:
>>>>>>
>>>>>> 1) call lcr through the socket twice (once for each phonenumber) and
>>>>>> then originate the calls through the socket too
>>>>>> 2) have a javascript file which runs the actions above, run the script
>>>>>> through the socket with 'jsrun'
>>>>>>
>>>>>> How would you do it?
>>>>>>
>>>>>> For what I've read on the list, usually the recommended way is to stay
>>>>>> away from javascript as much as possible because it is not as efficient as
>>>>>> doing everything from the dialplan. Does this mean the first option is the
>>>>>> best? or is there a "dialplan way" of doing it?
>>>>>>
>>>>>> Thank you very much for your help!
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090721/476cfe9b/attachment-0001.html 