Automatically returning to status mode after XML push/entering service mode

Unanswered Question
Oct 19th, 2007

We push out XML data to 79xx phones in CME. By pushing the data the phones enter services mode. Is there a way to send a command to return to status mode after detecting a disconnect? Currently the user must press the exit key. I suspect this can be done as the phone returns to status mode from Idle mode when a call is received.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
msabir Tue, 10/23/2007 - 05:38

"Is there a way to send a command to return to status mode after detecting a disconnect?"

I am not sure if your question is clear. What do you mean by "detecting a disconnect". Are you talking about call disconnect? What do you mean by "Status Mode"?

4mcohen Wed, 01/02/2008 - 10:38

I believe the original poster wants to change back to the Call Plane from the Service Plane without user intervention. The only way I have been able to accomplish this is by pushing a Key:Services URI to the phone.

ckatene Wed, 01/02/2008 - 14:44

Use "Init:Services" instead, which clears the services plane only if it is currently displayed. This means you can automate it, by setting the Refresh HTTP header. eg:

Refresh: 10; URL=Init:Services

After 10 seconds the service plane will be cleared: If it's not being displayed at the time, then this will have no effect.

juliosanchezt Fri, 12/19/2008 - 15:07


I'm having an issue with the HTTP-REFRESH header.

Cisco IP Phone 7960 is not interpreting correctly the URL(correctly URI): "Init:Services".

It responds with: "HOST NOT FOUND" at the prompt line of the phone.

Is this a firmware issue? Phone is currently loaded with firmware version 8.0(9.0).

Thanks in advance.

juliosanchezt Fri, 12/19/2008 - 15:26

Thanks a lot for this forum...

There are always alternate ways of doing things...

Within the HTTP-Refresh header, I don't use the URI "Init:Services" anymore. Instead, I use a normal URL (http://) that points to a page withe the following code:

Now it works, thanks!

ckatene Wed, 01/02/2008 - 14:46

what do you mean by "detecting a disconnect?" a disconnect from what ? a call?

stephan.steiner Mon, 12/29/2008 - 05:05

I've always used the approach now used by julio.. it always works reliably across all the phone types. I would suspect that the IPC could also be one of the phones that handles the cisco internal uris differently (or not at all).. whereas every phone type has no trouble dealing with a regular page that returns a CiscoIPPhoneExecute.

As for the rest of the question.. to get information when there's a disconnect.. you need CTI (so TAPI or JTAPI). With the 8.3.5+ firmware there's also some eventing in applications, e.g. you can be informed when an application has been closed or pushed to the background (e.g. if a call comes in your app is pushed in the background)... however, that doesn't apply to disconnects as there's no context change for your application.. the phone will stay in the phone context and your application will remain in the background so you have to use one of the two CTI interfaces.


This Discussion