How can i know the phone is in a call or not?

Unanswered Question
Nov 10th, 2008

How can i know the phone is in a call or not?

I need to detect it and then send alert to the phone.

Should i use AXL or JTAPI?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
msabir Mon, 11/10/2008 - 20:33

If you are pushing text or audio to an IP phone, using CiscoIPPhoneExecute, you can use "Priority" as "2", then it will not execute that command.


0 = Execute Immediately

The URL executes regardless of the state of the phone. If the Priority attribute does not get specified in the , the default priority gets set to zero for backward compatibility.

1 = Execute When Idle

The URL gets delayed until the phone goes idle, at which time it executes.

2 = Execute If Idle

The URL executes on an idle phone; otherwise, it does not get executed (it does not get delayed).

gerence.guan Mon, 11/10/2008 - 22:19

Actually, i am going to set RTPR to the remote phone, like intercom example. does the Execute Priority also work for that?

msabir Tue, 11/11/2008 - 05:28

Yes, this is what we use in PhoneTop Messenger. You can use RTPRx and RTPTx URIs within the execute command. If you choose the JTAPI route, you will be dependant on CUCM version and will need to update JTAPI with CUCM updates.

stephan.steiner Wed, 11/12/2008 - 01:48

However, if it's an intercom application, you may want to give he who initiates the intercom "call" some feedback if the process doesn't succeed.. I don't recall offhand if you get that when POSTing.

@msabir: are you actually involved in PhoneTopMessenger somehow? If so and you're using POST.. how reliable has it been for you? I only use POST for quick tests (I've been too lazy to write a nice Java app with a GUI for that purpose) but in my (admittedly somewhat limited) experience, POSTing has proven to be less reliable than passing XSI via JTAPI.

msabir Wed, 11/12/2008 - 04:47

Post has been reliable when you use a 3rd party authentication service, instead of built-in CUCM authentication. We found the bottle neck was authentication when you push a POST request. Also, we use Multi-Threading when using POST, so we can simultaneously POST to hundereds or thousands of Phones. One more thing, is the number of active TCP connections your Windows OS allows. On XP/Workstation, it is limited, on server OS, you can have more active threads. Another thing is max thread count for your web server. So when you fine tune all of this, we are able to make HTTP POST a reliable way to push audio/text/graphics, etc to IP phones.

gerence.guan Wed, 11/12/2008 - 14:41


I also try to use java Multi-Threading to simultaneously Push voice to phones. Less then 20 not hundereds. But it still PUSH like one by one. How did you do that?

Is that because i am using CUCM authentication? I think 20 PUSH is not a big deal.

msabir Wed, 11/12/2008 - 14:44

You need to create a HTTP POST thread for each push, and use Java's built-in multi-thread feature or use 3rd party multithread utilities.

stephan.steiner Thu, 11/13/2008 - 02:31

Ahh.. I guess that's the difference then (I suspect the CiscoIpPhoneError 0 I get every now and then could be related to that as well as the phone can access the service page just fine and thus talk to the ccm via http).

Do you still use device association or do you have another mechanism to handle permissions? I figure if you still use the CCM you'd have to cache the device association data so as to not run into another bottleneck.

gerence.guan Wed, 11/12/2008 - 20:56


No. the CiscoIPPhoneExecute Priority=”2” does not work for me. the Push RTPR always been executed even the phone is on a call.

Is there anything need to be set in the call manager?

I am using CUCM 6.1.2, 7961 Phones

Wes Schochet Wed, 11/12/2008 - 15:07

I have had pretty good luck polling the phone itself via http. There are a couple of fields that change when a call is active. As I look at mine now (7941), it looks like there is a stream status field. I believe that on my old 7960 it was called Row Status.


This Discussion