Re: [Freeswitch-users] Possible problem in adding channel variables to the bridge
Both suggestions work: If I include the effective_caller_id_number in the dialplan before bridging, or if I include {origination_caller_id_number=45161061} or [origination_caller_id_number=45161061] as a part of the first parameter after a originate command. But skipping the "set" command in the dialplan, and trying to use: <action application="bridge" data="[effective_caller_id_number=45161061]sofia/gateway/45161061/$1"/> or: <action application="bridge" data="[origination_caller_id_number=45161061]sofia/gateway/45161061/$1"/
does not work. Same thing when using curled brackets. I need to be able to pass parameters individually to each of the bridge destinations, not just for the A-number, but also for other stuff to be used for post processing of the call. An alternative would be to emulate the Asterisk chan_local by making some kind of loopback to the dialplan, using IAX or SIP, but this is a inelegant way of solving it. Jon
I still need to know the output of "version" because you might be on one that has a bug in relation to this exact issue. If you can provide that or update to SVN trunk. /b On Sep 20, 2008, at 2:14 AM, Jon Bruel wrote:
Both suggestions work: If I include the effective_caller_id_number in the dialplan before bridging, or if I include {origination_caller_id_number=45161061} or [origination_caller_id_number=45161061] as a part of the first parameter after a originate command.
But skipping the “set” command in the dialplan, and trying to use:
<action application="bridge" data="[effective_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/>
or:
<action application="bridge" data="[origination_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/>
does not work. Same thing when using curled brackets.
I need to be able to pass parameters individually to each of the bridge destinations, not just for the A-number, but also for other stuff to be used for post processing of the call. An alternative would be to emulate the Asterisk chan_local by making some kind of loopback to the dialplan, using IAX or SIP, but this is a inelegant way of solving it.
Jon
_______________________________________________ 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
On Sep 20, 2008, at 2:14 AM, Jon Bruel wrote:
Both suggestions work: If I include the effective_caller_id_number in the dialplan before bridging, or if I include {origination_caller_id_number=45161061} or [origination_caller_id_number=45161061] as a part of the first parameter after a originate command.
But skipping the “set” command in the dialplan, and trying to use:
<action application="bridge" data="[effective_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/>
This is because effective_caller_id_number has to be set on the A-Leg before you call bridge. This method won't work. You can only set origination caller id in that manner. And this <action application="bridge" data="[origination_caller_id_number=666666666]sofia/x.x.x.x/1001"/> Works on the latest SVN trunk.
or:
<action application="bridge" data="[origination_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/>
does not work. Same thing when using curled brackets.
I need to be able to pass parameters individually to each of the bridge destinations, not just for the A-number, but also for other stuff to be used for post processing of the call. An alternative would be to emulate the Asterisk chan_local by making some kind of loopback to the dialplan, using IAX or SIP, but this is a inelegant way of solving it.
chan_local is a hack and not needed. Once you learn how everything works you'll see why its not needed.
Jon
participants (2)
-
Brian West
-
Jon Bruel