Thread: [Asterisk-java-users] originateCall in AsteriskManager
Brought to you by:
srt
Menu
▾
▴
asterisk-java-users
|
From: Tony M. <to...@am...> - 2006-05-31 20:43:22
|
Stefan,
I've been playing a little bit with the AsteriskManager interface. In my
application I have encountered two difficulties:
1) I have a race condition right after originating the call. I
originate the call, receive the new AsteriskChannel, and then register a
property change listener with it. I have no way of knowing if the channel
state has changed after origination but before having registered the
listener. I can probably synchronize on the channel and get a safe result,
but it feels a bit awkward.
2) There is no way for me to determine the reason for the call failure
when the originate returns null. For example if any of the origination
parameters, such as an illegal channel, caused the failure.
My application code that wraps the AsteriskManager has an interface somewhat
like a JTapi API.
Call call = pbxService.createCall(.);
call.addObserver(myObserver());
call.connect();
Does anybody have suggestions for how to deal with (1) and (2)?
Anthony Mowers
http://www.amowers.com <http://www.amowers.com/>
|
|
From: Stefan R. <sr...@re...> - 2006-05-31 22:02:52
Attachments:
signature.asc
|
Hi Tony, these are two very good questions :) What I thought of was to make to call to originate asynchronous so that you could pass it some kind of callback (maybe just a property change listener) that is called on changes to the originated channel. What do you think? =3DStefan Tony Mowers wrote: > Stefan, >=20 > =20 >=20 > I=92ve been playing a little bit with the AsteriskManager interface. I= n > my application I have encountered two difficulties: >=20 > =20 >=20 > 1) I have a race condition right after originating the call. I > originate the call, receive the new AsteriskChannel, and then register = a > property change listener with it. I have no way of knowing if the > channel state has changed after origination but before having registere= d > the listener. I can probably synchronize on the channel and get a safe= > result, but it feels a bit awkward. >=20 > 2) There is no way for me to determine the reason for the call > failure when the originate returns null. For example if any of the > origination parameters, such as an illegal channel, caused the failure.= >=20 > =20 >=20 > My application code that wraps the AsteriskManager has an interface > somewhat like a JTapi API. >=20 > =20 >=20 > Call call =3D pbxService.createCall(=85); >=20 > call.addObserver(myObserver()); >=20 > call.connect(); >=20 > =20 >=20 > Does anybody have suggestions for how to deal with (1) and (2)? --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... Jabber: sr...@ja... |
|
From: Tony M. <to...@am...> - 2006-06-01 10:39:05
|
The asynchronous origination would work for me. I am listening for = channel state changes so it means most things in my particular application are asynchronous. I know what the ideal mechanism would look like for me, so I'll just = talk aloud about some of my thoughts. I would like to be able to register for callbacks before any events are generated for my call. I don't want to miss any events related to my = call. If that can be done by automatically registering my property change = listener to the originating channel immediately then that would be good. I don't know enough about Asterisk to know whether watching the property changes of the originating channel is equivalent to watching a phone = call. I know that intuitively I would like to watch the call. The types of things I'd like to watch for are: - Originating channel was created (I didn't screw up with channel data) - Origination information was incorrect and call ended - Originating channel was congested and so call aborted - Alerting is happening on originating channel=20 - Origination alerting timed out - Originator has answered - Another channel has been linked to call - A channel in the call is being alerted - A channel in the call has answered - One of the channels has hung-up or failed - Call has ended I have to admit that the logical object model for asterisk is not very = clear to me yet. My basic understanding of it is that an originating channel = gets created and then some application is applied to the channel either in = the form of an extension or directly as an application. The application can = do certain things to the channel, such as creating another channel and = linking it to the originating channel. That's my na=EFve understanding of the = logical model. I don't know if this sheds any light on what might be the typical user requirements. -----Original Message----- From: ast...@li... [mailto:ast...@li...] On Behalf Of Stefan Reuter Sent: Thursday, June 01, 2006 12:03 AM To: ast...@li... Subject: Re: [Asterisk-java-users] originateCall in AsteriskManager Hi Tony, these are two very good questions :) What I thought of was to make to call to originate asynchronous so that you could pass it some kind of callback (maybe just a property change listener) that is called on changes to the originated channel. What do you think? =3DStefan Tony Mowers wrote: > Stefan, >=20 > =20 >=20 > I=92ve been playing a little bit with the AsteriskManager interface. = In > my application I have encountered two difficulties: >=20 > =20 >=20 > 1) I have a race condition right after originating the call. I > originate the call, receive the new AsteriskChannel, and then register = a > property change listener with it. I have no way of knowing if the > channel state has changed after origination but before having = registered > the listener. I can probably synchronize on the channel and get a = safe > result, but it feels a bit awkward. >=20 > 2) There is no way for me to determine the reason for the call > failure when the originate returns null. For example if any of the > origination parameters, such as an illegal channel, caused the = failure. >=20 > =20 >=20 > My application code that wraps the AsteriskManager has an interface > somewhat like a JTapi API. >=20 > =20 >=20 > Call call =3D pbxService.createCall(=85); >=20 > call.addObserver(myObserver()); >=20 > call.connect(); >=20 > =20 >=20 > Does anybody have suggestions for how to deal with (1) and (2)? --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... Jabber: sr...@ja... |
|
From: Tony M. <to...@am...> - 2006-06-01 10:50:19
|
I meant to say "I do not know what the ideal callback mechanism would = look like for me ..." -----Original Message----- From: ast...@li... [mailto:ast...@li...] On Behalf Of = Tony Mowers Sent: Thursday, June 01, 2006 12:39 PM To: ast...@li... Subject: Re: [Asterisk-java-users] originateCall in AsteriskManager The asynchronous origination would work for me. I am listening for = channel state changes so it means most things in my particular application are asynchronous. I know what the ideal mechanism would look like for me, so I'll just = talk aloud about some of my thoughts. I would like to be able to register for callbacks before any events are generated for my call. I don't want to miss any events related to my = call. If that can be done by automatically registering my property change = listener to the originating channel immediately then that would be good. I don't know enough about Asterisk to know whether watching the property changes of the originating channel is equivalent to watching a phone = call. I know that intuitively I would like to watch the call. The types of things I'd like to watch for are: - Originating channel was created (I didn't screw up with channel data) - Origination information was incorrect and call ended - Originating channel was congested and so call aborted - Alerting is happening on originating channel=20 - Origination alerting timed out - Originator has answered - Another channel has been linked to call - A channel in the call is being alerted - A channel in the call has answered - One of the channels has hung-up or failed - Call has ended I have to admit that the logical object model for asterisk is not very = clear to me yet. My basic understanding of it is that an originating channel = gets created and then some application is applied to the channel either in = the form of an extension or directly as an application. The application can = do certain things to the channel, such as creating another channel and = linking it to the originating channel. That's my na=EFve understanding of the = logical model. I don't know if this sheds any light on what might be the typical user requirements. -----Original Message----- From: ast...@li... [mailto:ast...@li...] On Behalf Of Stefan Reuter Sent: Thursday, June 01, 2006 12:03 AM To: ast...@li... Subject: Re: [Asterisk-java-users] originateCall in AsteriskManager Hi Tony, these are two very good questions :) What I thought of was to make to call to originate asynchronous so that you could pass it some kind of callback (maybe just a property change listener) that is called on changes to the originated channel. What do you think? =3DStefan Tony Mowers wrote: > Stefan, >=20 > =20 >=20 > I=92ve been playing a little bit with the AsteriskManager interface. = In > my application I have encountered two difficulties: >=20 > =20 >=20 > 1) I have a race condition right after originating the call. I > originate the call, receive the new AsteriskChannel, and then register = a > property change listener with it. I have no way of knowing if the > channel state has changed after origination but before having = registered > the listener. I can probably synchronize on the channel and get a = safe > result, but it feels a bit awkward. >=20 > 2) There is no way for me to determine the reason for the call > failure when the originate returns null. For example if any of the > origination parameters, such as an illegal channel, caused the = failure. >=20 > =20 >=20 > My application code that wraps the AsteriskManager has an interface > somewhat like a JTapi API. >=20 > =20 >=20 > Call call =3D pbxService.createCall(=85); >=20 > call.addObserver(myObserver()); >=20 > call.connect(); >=20 > =20 >=20 > Does anybody have suggestions for how to deal with (1) and (2)? --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... Jabber: sr...@ja... _______________________________________________ Asterisk-java-users mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/asterisk-java-users |
|
From: Stefan R. <sr...@re...> - 2006-06-09 02:28:11
Attachments:
signature.asc
|
> The types of things I'd like to watch for are: > - Originating channel was created (I didn't screw up with channel data)= > - Origination information was incorrect and call ended > - Originating channel was congested and so call aborted > - Alerting is happening on originating channel > - Origination alerting timed out > - Originator has answered > - Another channel has been linked to call > - A channel in the call is being alerted > - A channel in the call has answered > - One of the channels has hung-up or failed > - Call has ended With the new async originate methods, do you think things are better now?= Do you like the OriginateCallback and the PropertyChangeListener or does it feel strange to register a PropertyChangeListener and you would expect to have a more "natural" listener for channel changes with methods like onNewState or even onHangup and so on? =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... Jabber: sr...@ja... |
|
From: Tony M. <to...@am...> - 2006-06-09 11:00:59
|
The new async OriginateCallback method will work for me. I'm not sure if it is working as it should yet. If I call someone, who is using a SJPhone for example, and they hit their "ignore call" button then I get an "onFailure" callback. I'd expect an "onBusy". An "onFailure" makes me think there is something wrong with the phone number, the trunk, or some such thing. I'd also kind of expect the onFailure to have a cause if possible. The property change listener also works for me. It seemed a little strange at first because I was expecting the natural listener with an onHangup and such. After I saw that there were several properties that could be observed I understood the reason for your choosing the property change listener. I think most other people will understand too. -----Original Message----- From: ast...@li... [mailto:ast...@li...] On Behalf Of Stefan Reuter Sent: Friday, June 09, 2006 4:28 AM To: ast...@li... Subject: Re: [Asterisk-java-users] originateCall in AsteriskManager > The types of things I'd like to watch for are: > - Originating channel was created (I didn't screw up with channel data) > - Origination information was incorrect and call ended > - Originating channel was congested and so call aborted > - Alerting is happening on originating channel > - Origination alerting timed out > - Originator has answered > - Another channel has been linked to call > - A channel in the call is being alerted > - A channel in the call has answered > - One of the channels has hung-up or failed > - Call has ended With the new async originate methods, do you think things are better now? Do you like the OriginateCallback and the PropertyChangeListener or does it feel strange to register a PropertyChangeListener and you would expect to have a more "natural" listener for channel changes with methods like onNewState or even onHangup and so on? =Stefan -- reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: sr...@re... Jabber: sr...@ja... |
|
From: Stefan R. <sr...@re...> - 2006-06-09 11:17:37
Attachments:
signature.asc
|
Tony Mowers wrote: > I'm not sure if it is working as it should yet. If I call someone, who= is > using a SJPhone for example, and they hit their "ignore call" button th= en I > get an "onFailure" callback. I'd expect an "onBusy".=20 I have to check this with a softphone, and probably with a sip client that is not registered at all. It seems like this is treated the same way as a failure to a completely invalid channel. Hopefully we can see a difference for the two cases. > An "onFailure" makes > me think there is something wrong with the phone number, the trunk, or = some > such thing. Yes the only reason for onFailure i am aware of is an invalid channel. > I'd also kind of expect the onFailure to have a cause if > possible. Yes, I added a cause parameter (up to now this is always a NoSuchChannelException). > The property change listener also works for me. It seemed a little stra= nge > at first because I was expecting the natural listener with an onHangup = and > such. After I saw that there were several properties that could be obse= rved > I understood the reason for your choosing the property change listener.= I > think most other people will understand too. ok. plus its always the same for observing channels, meetme users and so on. will need a good example ;) =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: Tony M. <to...@am...> - 2006-06-09 16:15:13
|
This is perhaps an asterisk question instead of an asterisk-java, but maybe
someone here will know the answer.
If I make two calls in a row to the same ZAP extension the second call fails
with a "Channel Unavailable Exception". If I add in a delay of half a
second between calls then the call will succeed.
If the extension is a SIP extension then there is no problem.
Below is my test code (ext 100 is my ZAP phone and 101 my SIP phone):
package com.pbxworkbench;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
import junit.framework.TestCase;
import org.asteriskjava.live.AsteriskChannel;
import org.asteriskjava.live.ChannelState;
import org.asteriskjava.live.DefaultAsteriskServer;
import org.asteriskjava.live.LiveException;
import org.asteriskjava.live.OriginateCallback;
import org.asteriskjava.manager.ManagerConnection;
import org.asteriskjava.manager.ManagerConnectionFactory;
public class AsteriskServerTest extends TestCase {
private DefaultAsteriskServer server;
protected void setUp() throws Exception {
super.setUp();
ManagerConnectionFactory factory = new
ManagerConnectionFactory(
"192.168.2.150", "username", "password");
ManagerConnection connection =
factory.createManagerConnection();
server = new DefaultAsteriskServer(connection);
server.initialize();
}
protected void tearDown() throws Exception {
super.tearDown();
}
/*
* Test method for
*
*/
public void testOriginate ()
throws Exception {
MyOriginateCallback callback = new MyOriginateCallback();
server.originateToExtensionAsync(
"local/100@default",
"default",
"101",
1, 30000,
callback);
callback.waitForCallEnd();
Thread.sleep(200);
server.originateToExtensionAsync(
"local/100@default",
"default",
"101",
1,
30000, callback);
callback.waitForCallEnd();
}
private class MyOriginateCallback implements OriginateCallback,
PropertyChangeListener {
Semaphore semaphore = new Semaphore(1);
public MyOriginateCallback() {
semaphore.drainPermits();
}
public void waitForCallEnd() throws Exception {
semaphore.tryAcquire(30, TimeUnit.SECONDS);
semaphore.drainPermits();
}
public void onSuccess(AsteriskChannel channel) {
channel.addPropertyChangeListener(this);
}
public void onCallEnd() {
System.out.println("call ended");
semaphore.release();
}
public void onNoAnswer(AsteriskChannel channel) {
System.out.println("no answer");
onCallEnd();
}
public void onBusy(AsteriskChannel channel) {
System.out.println("busy");
onCallEnd();
}
public void onFailure(LiveException cause) {
System.out.println("failure " + cause);
onCallEnd();
}
public void propertyChange(PropertyChangeEvent evt) {
System.out.println(evt.getPropertyName() + "=" +
evt.getNewValue());
if (ChannelState.HUNGUP.equals(evt.getNewValue())) {
onCallEnd();
}
}
}
}
|
×
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