Re: [Freeswitch-users] Possible problem in adding channel variables to the bridge
Yes I can, but somehow I start to repeat myself. An INVITE is sent allright every time, but one of the headers differs: Works: Remote-Party-ID: <sip:45161061@jbconsulting.v2tel.dk>;screen=yes;privacy=off Doesn't work: Remote-Party-ID: "Extension 1000" <sip:1000@jbconsulting.v2tel.dk>;screen=yes;privacy=off I have tried with different variable names in the bridge data: <action application="bridge" data="[effective_caller_id_number=45161061]sofia/gateway/45161061/$1"/> as well as: origination_caller_id_number data="[origination_caller_id_number=45161061]sofia/gateway/45161061/$1"/
the latter combined with: <param name="caller-id-in-from" value="true"/>. But the only thing which works is setting the effective_caller_id_number in the dialplan before the bridge. That would be fine, unless I want to bridge to several destinations. Every time the call is rejected, the Remote-Party-ID-header hasn't the right value. I have tried to execute another dialplan at bridge, testing with other variables, and the info application doesn't reveal the variable I try to include in square brackets in the bridge data string. So maybe its not passed over to the B-leg. If you need more data, let me know, and I'll package it during the weekend. Jon
Let me show you some examples that I'm doing right now that work fine. I do this at the CLI and it works: originate {origination_caller_id_number=9184238080}sofia/gateway/ asterlink.com/1918XXXXXXX 9999 And this is in my dialplan works: <extension name="asterlink.com"> <condition field="destination_number" expression="^(1\d+)$"> <action application="export" data="nolocal:absolute_codec_string=PCMU"/> <action application="set" data="effective_caller_id_number=9184238080"/> <action application="bridge" data="sofia/gateway/asterlink.com/ $1"/> </condition> </extension> /b On Sep 19, 2008, at 4:44 PM, Jon Bruel wrote:
Yes I can, but somehow I start to repeat myself. An INVITE is sent allright every time, but one of the headers differs: Works: Remote-Party-ID: <sip:45161061@jbconsulting.v2tel.dk>;screen=yes;privacy=off Doesn't work: Remote-Party-ID: "Extension 1000" <sip:1000@jbconsulting.v2tel.dk>;screen=yes;privacy=off I have tried with different variable names in the bridge data: <action application="bridge" data="[effective_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/> as well as: origination_caller_id_number data="[origination_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/
the latter combined with: <param name="caller-id-in-from" value="true"/>. But the only thing which works is setting the effective_caller_id_number in the dialplan before the bridge. That would be fine, unless I want to bridge to several destinations. Every time the call is rejected, the Remote-Party-ID-header hasn't the right value. I have tried to execute another dialplan at bridge, testing with other variables, and the info application doesn't reveal the variable I try to include in square brackets in the bridge data string. So maybe its not passed over to the B-leg. If you need more data, let me know, and I'll package it during the weekend. 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
Jon, I did this originate at the CLI and each one has its own callerid: originate [origination_caller_id_number=666666666]sofia/x.x.x.x/1000, [origination_caller_id_number=999999999]sofia/x.x.x.x/1001 9999 And this in the dialplan: <extension name="test"> <condition field="destination_number" expression="^886$"> <action application="bridge" data="[origination_caller_id_number=666666666]sofia/x.x.x.x/1000, [origination_caller_id_number=999999999]sofia/x.x.x.x/1001"/> </condition> </extension> This is confirmed working as is my previous email. You have to watch and make sure you're looking at the correct invite. Also remove the caller-id-in-from. My RPID looks like: Remote-Party-ID: "Extension 1005" <sip: 999999999@x.x.x.x>;screen=yes;privacy=off Remote-Party-ID: "Extension 1005" <sip: 666666666@x.x.x.x>;screen=yes;privacy=off I have even tried this out to the PSTN to my cellphone and it works. /b On Sep 19, 2008, at 4:44 PM, Jon Bruel wrote:
Yes I can, but somehow I start to repeat myself. An INVITE is sent allright every time, but one of the headers differs: Works: Remote-Party-ID: <sip:45161061@jbconsulting.v2tel.dk>;screen=yes;privacy=off Doesn't work: Remote-Party-ID: "Extension 1000" <sip:1000@jbconsulting.v2tel.dk>;screen=yes;privacy=off I have tried with different variable names in the bridge data: <action application="bridge" data="[effective_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/> as well as: origination_caller_id_number data="[origination_caller_id_number=45161061]sofia/gateway/ 45161061/$1"/
the latter combined with: <param name="caller-id-in-from" value="true"/>. But the only thing which works is setting the effective_caller_id_number in the dialplan before the bridge. That would be fine, unless I want to bridge to several destinations. Every time the call is rejected, the Remote-Party-ID-header hasn't the right value. I have tried to execute another dialplan at bridge, testing with other variables, and the info application doesn't reveal the variable I try to include in square brackets in the bridge data string. So maybe its not passed over to the B-leg. If you need more data, let me know, and I'll package it during the weekend. 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
Also what is "version" and make sure you're on svn trunk if possible. That [] had a bug in it at some point and I can't recall the exact rev we fixed it in. But I'm on svn trunk here working to nail down bugs so we can release 1.0.2. /b
participants (2)
-
Brian West
-
Jon Bruel