I just ran some tests and I can find no evidence that [] populates only the b leg. In all my tests the {} and [] methods behave exactly as documented, populating all a legs or single a legs, respectively. -MC On Fri, Sep 24, 2010 at 2:44 PM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
I'm not sure if wiki text is correct...
On Friday 24 September 2010, David Ponzone wrote:
Sergey,
I am sorry, but I really think you are the one who is confused :)
From the wiki: {foo=bar} is *only* valid at the beginning of the dial string. It will set the same variables on every channel. [foo=bar] goes before every individual dial string and will set the variable values specified for only this user's dial string channel.
David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 24/09/2010 à 22:52, Sergey Okhapkin a écrit :
No, whatever is set in {} is unavailable to b leg. [] sets b leg variables and are unavailable on a leg.
On Friday 24 September 2010, David Ponzone wrote:
Sergey,
you are confusing me. It seemed to me that when you have only one destination leg, {} and [] are the same.
David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 24/09/2010 à 22:28, Sergey Okhapkin a écrit :
Correction:
bridge [sip_cid_type=none]sofia/etc
[] but not {}
On Friday 24 September 2010, David Ponzone wrote:
Mario,
To save you some time, most carriers will accept in the FROM field. AFAIR, FS defaults to Remote-Party-Id, so perhaps you just need to set this before your dialstring: bridge {sip_cid_type=none}sofia/etc...
David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Le 24/09/2010 à 21:54, Sergey Okhapkin a écrit : > Does the gateway uid1 allow to specify CID number? > > On Friday 24 September 2010, Mario wrote: >> I am bridging a call from either inside or outside to an >> emergency >> number on an att cellphone which works fine. I am trying to pass >> the >> original caller id or anything else for that matter as the caller >> id/name. I only get "unknown". I also tried to send to a VOIP >> number and >> it also gets "unknown" so I am thinking it is not att. I tried >> various >> combinations of things I found on the web but nogo. Anyone see >> the >> problem below? Thanks! >> Mario >> >> <extension name="mx911"> >> <condition field="destination_number" expression="^2911$"> >> <action application="set" >> data="effective_caller_id_name=Emergency"/> <action >> application="set" >> data="effective_caller_id_number=9161234567"/> >> <action application="set" data="hangup_after_bridge=true"/> >> <action application="bridge" data="sofia/gateway/ >> uid1/19161112222"/> >> </condition> >> </extension> >> >> _______________________________________________ >> 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-u >>se rs 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-us >er s 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-user s 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
_______________________________________________ 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