CiscoIPPhoneExecute URL behaviour in CUCM 7.1

Version 1
    This document was generated from CDN thread

    Created by: Vadim Bruk on 17-12-2008 10:32:35 PM
    Hi,

    I have a problem with a scenario when there is a URL is associated with a softkey and user presses this softkey. HTTP request goes to our app. The app responses with IPPhoneExecute command with a dummy URL like “Hello world”. Using this “dummy” URL keeps the phone screen on the same page. This works for phones registered with CUCM’s versions up to 6.1. In CUCM 7.1 it works differently. In fact, the phone screen gets cleared and it goes to the “home” page after receiving the app’s response.
    Is there any special requirements for these URLs in CUCM 7.1?

    Thanks,
    Vadim.

    Subject: Re: CiscoIPPhoneExecute URL behaviour in CUCM 7.1
    Replied by: David Staudt on 18-12-2008 02:03:13 AM
    The scenario sounds a little odd. Can you provide more details on what exactly occurs, what messages are sent/received, and the expected vs unexpected behaviour?

    I would expect the XSI behaviour to be effected by the phone firmware version, rather than the CCM version. As far as I know 7.1 has not been released, are you using 7.0 or do you have pre-release access?

    A network packet capture (Wireshark) could help you investigate exactly what is being transmitted back and forth between phone/CCM/app. You can attach it here if you spot something amiss.

    Subject: Re: CiscoIPPhoneExecute URL behaviour in CUCM 7.1
    Replied by: Vadim Bruk on 18-12-2008 10:13:37 PM
    Re-posting.

    Subject: Re: CiscoIPPhoneExecute URL behaviour in CUCM 7.1
    Replied by: David Staudt on 19-12-2008 12:16:05 AM
    • A CiscoIPPhoneExecute object should only reach the phone via HTTP POST (i.e. a 'push'). Returning an Execute object from a GET request - as here - is not intended, and results could be unexpected. Later phone firmware, such as that which comes with CM7, may be more strict in rejecting invalid XML objects. I think you should be able to return a CiscoIPPhoneText object with the safe effect.

    • In the pcap provided, there are 3 HTTP packets:
    Phone -> GET <url>
    App -> 200 OK
    App -> Continuation <CiscoIPPhoneExecute xml...>

    There does not appear to be any HTTP POST of an Execute object with RTPx commands, etc.

    Subject: Re: CiscoIPPhoneExecute URL behaviour in CUCM 7.1
    Replied by: Vadim Bruk on 19-12-2008 01:12:56 AM
    Well, then my quesion is what body would be safe to send in the HTTP response back to the phone, so it will not change the original web page? Please note, the intention of this HTTP request going from the phone to the application is not to show a new page but rather to trigger one or more push requests to the phone (as you can see these pushes are not neccessarily are new phone screens).
    Also, you don't see in the wireshark dump pushing of RTPx command to the phone because, as I've mentioned in my previous post, the push is done via CUAE's call sendXSIData (I do see traces of this push in the CUAE AppServer log files and I can hear the pushed audio file being played on the phone). I was running the wireshark on our app box which is not the CUAE box.

    Thank you,
    Vadim.

    Subject: Re: CiscoIPPhoneExecute URL behaviour in CUCM 7.1
    Replied by: David Staudt on 19-12-2008 02:48:44 AM
    I think I understand what you are trying to accomplish. The fact that responding with an Execute object causes the phone to not leave the call plane screen is interesting (and unexpected/unintended.)

    However, I think the phone is always going to show 'Requesting' and has to be returned a valid object (or it will timeout/error.) If you have the ability to modify the HTTP headers returned, you can try a Refresh header of 1 second with Init:Services as the URI:

    Refresh 1; url=Init:services

    I'm not sure CUAE has this capability. In which case possibly the only option is to respond with a CiscoIPPhoneText ('Please wait') and then include an 'Init:Services' ExecuteItem when you push down the RTP command.

    Subject: Re: CiscoIPPhoneExecute URL behaviour in CUCM 7.1
    Replied by: Vadim Bruk on 22-12-2008 08:48:02 PM
    Hi David,

    I've double checked the documentation. Here is what CU IPPS Application Development Notes Release 7.0(1) (page 2-23) says:
    Like the other XML objects, the CiscoIPPhoneExecute can be either pushed (HTTP POST) or pulled (HTTP GET).
    So is this a documentation error?

    Thanks,
    Vadim.

    Subject: Re: CiscoIPPhoneExecute URL behaviour in CUCM 7.1
    Replied by: Stephan Steiner on 07-01-2009 09:37:40 AM
    Are you sure you have the same phone load on both CCMs? I don't use wireless phones but I know for the wired ones, CCM 7.01 contains the 8.4.1 loads which change quite a bit over what was installed previously (only CCM 6.1.3 also comes with the 8.4.x loads).

    I wouldn't rely on sending invalid URIs and expect something to happen.. it's well within the real of possibilities that the behavior can change with newer loads.

    Is there a particular reason you're not sending the rtp and play commands from the application? I know this works as I have applications which upon pressing a softkey return CiscoIPPhoneExecute elements which start rtp reception and directs the phone to a new page. However, there has to be some displayable action within the items you execute.. .e.g. in my case the phone then forwards to another page. Or you could do a Init:Services or one of the new app control uris.

    And speaking of things that are new... once again I don't know how that applies to the mobile phones but on a hardphone with load 8.3.5 or higher you have the notification uris which allow you to perform NOP operations (basically).. instead of the phone sending a GET and expecting something it can display, you could have it send a POST to your application at a given url which you can then use to trigger whatever backend actions need to be taken. After that, the phone won't do anything.. so you stay at the page you were at.