Soundpoint IP 650 slow response to URL push

[Anonymous]

We have been using a URL push to send a mute command to an IP 650.  The push is working fine, but it sometimes seems to take a long time to take effect (as much as 10+seconds for a "Mute" command).  It seems like this is happening the first time we send the push after the phone has been idle for a while - subsequent push commands to the same phone happen very quickly.  This isn't a network problem or a problem with the web server - this has been tested on multiple phones with the same web server & network configuration.  Maybe the phone does some caching of URI's?

Any suggestions?

[SteffenBaierUK]

Hello GregH,

welcome to the Polycom Community.

• What Software Version on the Phone?
• Have you lowered the log level for PUSH to check if it arrives at the phone?

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services

[Anonymous]

Software versions: SIP 3.2.5.0508, BootROM 4.3.0.0246.  I've seen this behavior on an IP 650, 450, and 320, all running the same sofware versions.

I don't have a syslog server running, but I've been able to verify that the message arrives at the phone via Wireshark and because the visible and audible hold status changes on the phone. The OK response is returned by the phone shortly after the hold status changes.

[SteffenBaierUK]

Hello Greg,

SIP 3.2.5 is quite an old build in terms of PUSH support and I recall some memory leak issues if used for a while.

In order to verify any issues a support ticket would need to be raised via your Polycom reseller but I suggest you upgrade to the current UCS 4.0.3 Rev F or newer and re-test as many additional fixes in regards of PUSH have been added.

Best Regards

Steffen Baier

[Anonymous]

OK, I've made some headway.  I upgraded one of the 650's to SIP 4.0.3f.  Afterwards the phone shows:

SIP 4.0.3.7562

Updater 5.0.3.1667

Now I'm seeing two problems:

(1) The phone seems to be ignoring changes made in the Config/applications.cfg file on the provisioning server.  Specifically, I changed the various apps.push parameters so they would be the same as they were in the previous version.  Before & after I did this, the phone refused the push connection.  I've seen the same behavior with the other config files: changes that I make in the config file on the provisioning server don't seem to affect the phone.  The provisioning server is obviously accessible - the new bootROM changes were loaded from there.  Looking at logs in the web interface shows some minor configuration problems ,but nothing about push parameters.  I set up a syslog server, but it doesn't show any more info than the phone logs do.

(2) I changed the push parameters in the phone web interface, and now instead of the connection being refused, I'm getting a "400 (bad request)" response from the server in response to the push.  Here are two sample pushes:

     <PolycomIPPhone><URL priority="Critical">/push/mute.jsp</URL></PolycomIPPhone>

     <PolycomIPPhone><Data Priority="Critical"><title>Incoming</title><br/><h1>Line 0</h1></Data></PolycomIPPhone>

The phone log shows the same error for both push requests:

            000535.208|push |4|03|PushManagerC::enqueuePushObject: the message was not sent: http://xxx.xxx.xx.xx:8080//push/mute.jsp

             001939.736|push |4|03|PushManagerC::enqueuePushObject: the message was not sent: <PolycomIPPhone><Data Priority="Critical"><title>Incoming</title><br/><h1>Line 0</h1></Data></PolycomIPPhone>

I'm not sure what this means, as the phone obviously received the push, and in the case of the DATA push, there's no place for it to send the message.

As far as I can tell, these match the specs in the web app developers' guide, and they worked with phones running the previous version of BootROM/SIP (except for the slow response that started this whole discussion).

Suggestions?

[SteffenBaierUK]

Hello Greg,

your comment in regards of the provisioning server has me worried.

In addition your hyperlink for the PUSH url has // in it instead of the expected /.

If your prior software was SIP 3.2.x and your provisioning system is setup for this then it is most likely utilizing the sip.cfg / phone1.cfg which is no longer used since UCS 3.3.0.

This is all described in the community FAQ.

The best thing to go forward is to format the file system, provision the phone from a standalone FTP server, manually configure the PUSH and SIP registration and test.

Then work with your provisioning server provider and / or your Polycom reseller on how to upgrade your infrastructure.

The reseller is also your tier 1 contact for any further support or follow up the advise given in my signature.

Some PUSH and other examples can also be found in the dedicated development section => here <=

Best Regards

Steffen Baier