Transfer Issue

Unidata phones cannot successfully perform transfers due to a violation of SIP RFC 3515.

When a Unidata phone issues an INVITE in response to a REFER packet, it replaces the domain of the REFER-TO contact with the domain of the user the phone is registered for. This creates a SIP address that is incorrect and almost certainly invalid (accept in the case where the domains are coincidentally the same).

The following SIP trace is from a SQ3000, which has registered for Hiro has dialed into the OnSIP auto-attendant. At the voice prompt, Hiro dialed an extension to be transferred to

## The SIP proxy sends a REFER to the SQ3000; 
## note that refer-to contact is "".

U 2010/01/21 16:31:32.745920 ->
REFER sip:hiro@ SIP/2.0.
From: <;user=phone>;tag=as274379be.
To: "Hiro Protagonist" <>;tag=g9eZZHmtepr2F.
Contact: <sip:welcome!>.
Call-ID: 29f87e81-8177-122d-acb6-00032a21d4cf.
CSeq: 102 REFER.
User-Agent: Asterisk PBX.
Max-Forwards: 69.
Refer-To: <>.
Referred-By: <sip:welcome!>.

## The SQ3000 sends an OK to the proxy in response to the REFER

U 2010/01/21 16:31:32.814456 ->
SIP/2.0 202 Accepted.

## The SQ3000 sends a new INVITE, using, which is broken.  

U 2010/01/21 16:31:33.295084 ->
From: "Hiro Protagonist" <>;tag=Hj8Q1c5XBZeNB.
To: <>.

## The proxy correctly returns a 404 Not Found, 
## as does not exist.

U 2010/01/21 16:31:33.296921 ->
SIP/2.0 404 Not Found.

We have notified Unidata of our findings, 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

Download the 2017 Business Phone Guide

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