Thread: [Asterisk-java-users] Originate and multiple variables
Brought to you by:
srt
Menu
▾
▴
asterisk-java-users
|
From: Edu <jav...@ba...> - 2006-07-06 07:33:10
|
I'm using Asterisk-java 0.2 and I want to put 3 variables in a originate
action. In my devel machine with asterisk 1.2 works Ok, but in the production
machine with asterisk 1.0 doesn't work.
Example code:
(...)
Map<String,String> variables=new LinkedHashMap<String,String>(2);
variables.put("callId",call.getIdCall());
while(i.hasNext())//Locuciones
variables.put(LOCUTIONSNAME+(++n),i.next());
originate.setVariables(variables);
And later, in extensions.conf I have an UserEvent like this:
exten => s, 3,UserEvent(Foo| callId: ${callId})
As commented in Asterisk wiki, Originate syntax and variables differ in 1.0
and 1.2, so I think that there is the problem so only want to confirm this
behaviour :)
Regards,
Edu
|
|
From: Stefan R. <sr...@re...> - 2006-07-06 08:05:32
Attachments:
signature.asc
|
Edu wrote: > As commented in Asterisk wiki, Originate syntax and variables differ in= 1.0=20 > and 1.2, so I think that there is the problem so only want to confirm t= his=20 > behaviour :) Asterisk-Java takes this into account, so it usually works with 1.0 and 1.2. Does Asterisk-Java recognize your production server as 1.0? (according to the logs) =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... |
|
From: Eduard M. <ed...@ba...> - 2006-07-06 08:11:58
|
According to the logs, the version is Asterisk 1.0: 06-jul-2006 7:58:34 net.sf.asterisk.util.impl.JavaLoggingLog info INFO: Determined Asterisk version: Asterisk 1.0 Well, the production machine is not exactly Asterisk 1.0 but Asterisk Bussi= nes=20 Edition ABE-A.1-6 I will do more tests Edu El Jueves, 6 de Julio de 2006 10:05, Stefan Reuter escribi=F3: > Edu wrote: > > As commented in Asterisk wiki, Originate syntax and variables differ in > > 1.0 and 1.2, so I think that there is the problem so only want to confi= rm > > this behaviour :) > > Asterisk-Java takes this into account, so it usually works with 1.0 and > 1.2. Does Asterisk-Java recognize your production server as 1.0? > (according to the logs) > > =3DStefan |
|
From: Edu <jav...@ba...> - 2006-07-06 08:12:31
|
According to the logs, the version is Asterisk 1.0: 06-jul-2006 7:58:34 net.sf.asterisk.util.impl.JavaLoggingLog info INFO: Determined Asterisk version: Asterisk 1.0 Well, the production machine is not exactly Asterisk 1.0 but Asterisk Bussi= nes=20 Edition ABE-A.1-6 I will do more tests Edu El Jueves, 6 de Julio de 2006 10:05, Stefan Reuter escribi=F3: > Edu wrote: > > As commented in Asterisk wiki, Originate syntax and variables differ in > > 1.0 and 1.2, so I think that there is the problem so only want to confi= rm > > this behaviour :) > > Asterisk-Java takes this into account, so it usually works with 1.0 and > 1.2. Does Asterisk-Java recognize your production server as 1.0? > (according to the logs) > > =3DStefan |
|
From: Eduard M. <ed...@ba...> - 2006-07-06 08:25:51
|
Another possible cause:
I'm doing Originate to a local channel, like Local@/XXXXX@outcoming
Originate extension then is s, context [connected]
In extensions I have=20
[outcoming]
exten =3D> _XXXX,1,UserEvent(LocalChannel)
exten =3D> _XXXX,2,Dial(Zap/g2/${EXTEN})
exten =3D> _XXXX,3,Hangup
[connected]
exten =3D> s, 3,UserEvent(Foo| callId: ${callId})
I'm doing this things because with the LocalChannel userEvent I have the re=
al=20
name of the local channel in my java application and I can cancel the=20
originate (hanging up this channel) and when is connected, Foo tells me the=
=20
real zap channel answered.
OriginateSuccesfulEvent doesn't tell me the real channel, and with originat=
e=20
action with a Zap group channel I don't have the channel until is answered=
=20
(so I can't cancel the originate while is ringing)
El Jueves, 6 de Julio de 2006 10:05, Stefan Reuter escribi=F3:
> Edu wrote:
> > As commented in Asterisk wiki, Originate syntax and variables differ in
> > 1.0 and 1.2, so I think that there is the problem so only want to confi=
rm
> > this behaviour :)
>
> Asterisk-Java takes this into account, so it usually works with 1.0 and
> 1.2. Does Asterisk-Java recognize your production server as 1.0?
> (according to the logs)
>
> =3DStefan
|
|
From: Edu <jav...@ba...> - 2006-07-06 08:26:14
|
Another possible cause:
I'm doing Originate to a local channel, like Local@/XXXXX@outcoming
Originate extension then is s, context [connected]
In extensions I have=20
[outcoming]
exten =3D> _XXXX,1,UserEvent(LocalChannel)
exten =3D> _XXXX,2,Dial(Zap/g2/${EXTEN})
exten =3D> _XXXX,3,Hangup
[connected]
exten =3D> s, 3,UserEvent(Foo| callId: ${callId})
I'm doing this things because with the LocalChannel userEvent I have the re=
al=20
name of the local channel in my java application and I can cancel the=20
originate (hanging up this channel) and when is connected, Foo tells me the=
=20
real zap channel answered.
OriginateSuccesfulEvent doesn't tell me the real channel, and with originat=
e=20
action with a Zap group channel I don't have the channel until is answered=
=20
(so I can't cancel the originate while is ringing)
El Jueves, 6 de Julio de 2006 10:05, Stefan Reuter escribi=F3:
> Edu wrote:
> > As commented in Asterisk wiki, Originate syntax and variables differ in
> > 1.0 and 1.2, so I think that there is the problem so only want to confi=
rm
> > this behaviour :)
>
> Asterisk-Java takes this into account, so it usually works with 1.0 and
> 1.2. Does Asterisk-Java recognize your production server as 1.0?
> (according to the logs)
>
> =3DStefan
|
|
From: Stefan R. <sr...@re...> - 2006-07-06 08:25:30
Attachments:
signature.asc
|
Edu wrote: > According to the logs, the version is Asterisk 1.0: >=20 > 06-jul-2006 7:58:34 net.sf.asterisk.util.impl.JavaLoggingLog info > INFO: Determined Asterisk version: Asterisk 1.0 >=20 > Well, the production machine is not exactly Asterisk 1.0 but Asterisk B= ussines=20 > Edition ABE-A.1-6 >=20 > I will do more tests Is it possible that your version of Asterisk is considered to be Asterisk 1.0 though it behaves as 1.2 regarding the handling of variables in originate? =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... |
|
From: Eduard M. <ed...@ba...> - 2006-07-06 08:27:23
|
Maybe, tomorrow I will try upgrading to last bussines edition (I think is=20 equivalent to 1.2) El Jueves, 6 de Julio de 2006 10:25, Stefan Reuter escribi=F3: > Edu wrote: > > According to the logs, the version is Asterisk 1.0: > > > > 06-jul-2006 7:58:34 net.sf.asterisk.util.impl.JavaLoggingLog info > > INFO: Determined Asterisk version: Asterisk 1.0 > > > > Well, the production machine is not exactly Asterisk 1.0 but Asterisk > > Bussines Edition ABE-A.1-6 > > > > I will do more tests > > Is it possible that your version of Asterisk is considered to be > Asterisk 1.0 though it behaves as 1.2 regarding the handling of > variables in originate? > > =3DStefan |
|
From: Stefan R. <sr...@re...> - 2006-07-06 08:49:24
Attachments:
signature.asc
|
Eduard Martinez wrote: > Another possible cause: > I'm doing Originate to a local channel, like Local@/XXXXX@outcoming > Originate extension then is s, context [connected] you can try setting the variables with two leading underscores (e.g. __callerId) this causes them to be interhited. I am unsure whether this works with Local/ channels though. =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... |
|
From: Edu <jav...@ba...> - 2006-07-07 08:10:06
|
Thanks! It works like a charm. I don't know why is not needed in my develop machine but doesn't matter. Regards, Edu El Jueves, 6 de Julio de 2006 10:49, Stefan Reuter escribi=F3: > Eduard Martinez wrote: > > Another possible cause: > > I'm doing Originate to a local channel, like Local@/XXXXX@outcoming > > Originate extension then is s, context [connected] > > you can try setting the variables with two leading underscores (e.g. > __callerId) this causes them to be interhited. I am unsure whether this > works with Local/ channels though. > > =3DStefan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X