Follow

Multiple Registrations Issue

Unidata phones have an issue in regards to responding appropriately to phone calls placed to a user that has more than one device (when the call is forked). The behavior of the phone is not compliant with SIP RFC 3261 or with OnSIP.

As an example, we registered a SQ3000 to hiro@example.onsip.com. Hiro makes a phone call to charlotte@junctionnetworks, who is registered on a Polycom 550 and an Eyebeam. The SQ3000 hears first from the Polycom and then the Eyebeam. If Charlotte picks up the Polycom, the phone call will complete appropiately. However, if Charlotte picks up the Eyebeam instead, the SQ3000 continues to ring and Charlotte hears silence.

This bug is repeatable with any combination of phones that we tried - the SQ3000 always ignores the second phone that it hears from.

Here's the SIP trace:

## User dials a phone number associated with charlotte@junctionnetworks.com
## SQ3000 sends an INVITE to the proxy

U 2010/01/21 16:25:41.567030 71.249.172.83:1179 -> 66.227.100.25:5060
INVITE sip:15555555555@example.onsip.com;user=phone SIP/2.0.
From: "Hiro Protagonist" <sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
To: <sip:15555555555@example.onsip.com;user=phone>.
Contact: <sip:hiro@71.249.172.83:1179;transport=udp>.
User-Agent: UniData.
<snip>

## Proxy sends a TRYING to the SQ3000

U 2010/01/21 16:25:41.569453 66.227.100.25:5060 -> 71.249.172.83:1179
SIP/2.0 100 Trying.
<snip>

## Proxy sends an INVITE to charlotte@junctionnetworks.com on the Polycom

U 2010/01/21 16:25:41.579241 66.227.100.25:5060 -> 173.49.233.40:5060
INVITE sip:charlotte@192.168.1.58;aor=charlotte%40junctionnetworks.com SIP/2.0.
From: "Hiro Protagonist" <sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
To: <sip:15555555555@example.onsip.com;user=phone>.
User-Agent: UniData.

## Proxy sends an INVITE to charlotte@junctionnetworks.com on the Eyebeam

U 2010/01/21 16:25:41.579283 66.227.100.25:5060 -> 173.49.233.40:28328
INVITE sip:charlotte@192.168.1.56:28328;rinstance=5bb3ca9b0900c506;
aor=charlotte%40junctionnetworks.com SIP/2.0.
From: "Hiro Protagonist" <sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
To: <sip:15555555555@example.onsip.com;user=phone>.
User-Agent: UniData.
<snip>

<snip>
The Polycom and the Eyebeam send RINGING packets to the proxy.
<snip>

## The proxy forwards the RINGING from the Eyebeam to the SQ3000 

U 2010/01/21 16:25:41.746637 66.227.100.25:5060 -> 71.249.172.83:1179
SIP/2.0 180 Ringing.
Contact: <sip:charlotte@173.49.233.40:28328;rinstance=5bb3ca9b0900c506;
aor=charlotte%40junctionnetworks.com>.
To: <sip:15555555555@example.onsip.com;user=phone>;tag=af7ad478.
From: "Hiro Protagonist"<sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
<snip>

## The proxy forwards the RINGING from the Polycom to the SQ3000

U 2010/01/21 16:25:41.829678 66.227.100.25:5060 -> 71.249.172.83:1179
SIP/2.0 180 Ringing.
From: "Hiro Protagonist" <sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
To: <sip:15555555555@example.onsip.com;user=phone>;tag=66224A5D-6609FDD0.
User-Agent: PolycomSoundPointIP-SPIP_550-UA/3.2.1.0054.
<snip>

# The SQ3000 sends a PRACK in response to the Polycom
# The SQ3000 will now ignore all data from the Eyebeam, 
# even when the user picks up the Eyebeam

U 2010/01/21 16:25:41.882073 71.249.172.83:1179 -> 66.227.100.25:5060
PRACK sip:charlotte@173.49.233.40:5060 SIP/2.0.
From: "Hiro Protagonist" <sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
To: <sip:15555555555@example.onsip.com;user=phone>;tag=66224A5D-6609FDD0.
RAck: 8193 30884970 INVITE.
User-Agent: UniData.
<snip>

## The proxy forwards the SQ3000's PRACK to the Polycom

U 2010/01/21 16:25:41.882680 66.227.100.25:5060 -> 173.49.233.40:5060
PRACK sip:charlotte@173.49.233.40:5060 SIP/2.0.
From: "Hiro Protagonist" <sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
To: <sip:15555555555@example.onsip.com;user=phone>;tag=66224A5D-6609FDD0.
Call-ID: 5e3901e6-8176-122d-acb6-00032a21d4cf.
CSeq: 30884971 PRACK.
RAck: 8193 30884970 INVITE.
User-Agent: UniData.
<snip>

## The Polycom sends an OK to the SQ3000's PRACK to the 
## proxy and proceeds to hang up. (snipped)

U 2010/01/21 16:25:41.913623 173.49.233.40:5060 -> 66.227.100.25:5060
SIP/2.0 200 OK.

## Charlotte picks up her Eyebeam and hears nothing 
## while the SQ3000 continues to ring

## Charlotte's Eyebeam sends an OK in response to the 
## SQ3000's INVITE to the proxy

U 2010/01/21 16:25:43.268953 173.49.233.40:28328 -> 66.227.100.25:5060
SIP/2.0 200 OK.
<snip>

## The proxy forwards the OK in response to the INVITE from 
## the Eyebeam to the SQ3000

U 2010/01/21 16:25:43.273141 66.227.100.25:5060 -> 71.249.172.83:1179
SIP/2.0 200 OK.
<snip>

## The Eyebeam sends the OK to the proxy again, as it's had no response. 

U 2010/01/21 16:25:43.872488 173.49.233.40:28328 -> 66.227.100.25:5060
SIP/2.0 200 OK.
User-Agent: eyeBeam release 1104a stamp 54436.
<snip>

## The proxy resends the OK from the Eyebeam again, as the SQ3000 seems 
## to be ignoring it. 

U 2010/01/21 16:25:43.873656 66.227.100.25:5060 -> 71.249.172.83:1179
SIP/2.0 200 OK.
To: <sip:15555555555@example.onsip.com;user=phone>;tag=af7ad478.
From: "Hiro Protagonist"<sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
User-Agent: eyeBeam release 1104a stamp 54436.

## The Eyebeam sends the OK to the proxy again, as it's had no response. 
## This repeats and repeats until the SQ3000 sends a CANCEL packet.
## The Eyebeam and the SQ3000 are confused at this point, as are the users.

U 2010/01/21 16:25:44.880026 173.49.233.40:28328 -> 66.227.100.25:5060
SIP/2.0 200 OK.
To: <sip:15555555555@example.onsip.com;user=phone>;tag=af7ad478.
From: "Hiro Protagonist"<sip:hiro@example.onsip.com>;tag=F0N6Xp3pHD2Fm.
User-Agent: eyeBeam release 1104a stamp 54436.
<snip>

We have notified Unidata of our findings and they have acknowledged that the phone cannot reliably complete calls where responses are received from multiple to destinations due to a forking proxy and as such the phone is not compliant with the core SIP RFC 3261, but are unaware of any time frame in which this bug will be fixed. Until such time, we do not advise the purchase of Unidata phones.


 

See our top business VoIP phone recommendations for 2017

Download the 2017 Business Phone Guide

Was this article helpful?
0 out of 0 found this helpful

Comments