Polycom Multple Contacts Registration Bug

The wrong expire time might be used when there are multiple contacts returned in a Contact header upon registration.

This is an issue in Polycom version 2.1.2. We are not aware if it has been fixed in later versions. Polycom reports that they fixed the bug back in release 2.0.0 (listed in their release notes as "14083: Wrong expire time might be used when there are multiple contact header lines"), but unfortunately that is not the case.

An example:

1. joe@example.onsip.com registers his eyeBeam phone with a registration period of 3600 seconds
2. joe@example.onsip.com also registers his Polycom phone with a registration period of 600 seconds

When the Polycom registers in step 2, the OnSIP registration server will (correctly) return information about the contact information for both registrations 1 and 2. Unfortunately, the Polycom may incorrectly use the expire time associated with the eyeBeam registration in 1. The result being that the Polycom may not re-register for up to an hour, but its registration actually expires in the 10 minutes thus leaving the Polycom unreachable for up to 50 minutes.

From the end users perspective, "My phone is registered (the phone icon on my line is solid black), but people are calling me and my phone is not ringing!". However, upon checking the OnSIP admin portal for the registration listing, the Polycom phone will not show up as a registered contact. A rather confusing situation.

The workaround is to make sure that the Polycom is the only device registered for the particular AOR (joe@example.onsip.com in the example above) or to make sure that all the devices involved are using the same registration interval.

The OnSIP registration server is operating correctly as per RFC 3261 and we will not be providing a server side work around. Here is the relevant excerpt from the RFC...

RFC 3261
Section 10.3 Processing REGISTER Requests
...
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. Each Contact value MUST feature an "expires"
parameter indicating its expiration interval chosen by the
registrar. The response SHOULD include a Date header field.