Call transfer enables User A (transferring user) to transform an existing call with User B (primary call) into a new call between User B and User C (transferred-to user) selected by User A.

OnSIP and Polycom support two standard transfer types:

1. Blind transfers: The call is transferred immediately to C after A has finished dialing C’s number. User A does not hear ring-back.
2. Consultation transfers: User A dials C’s number and consults privately with C after the call is answered and then completes the transfer.

   Polycom phones offer a third non-standard transfer type:

3. Consultation transfers which are dispatched during the proceeding state: User A dials C’s number and hears ring-back and decides to complete the transfer before C answers.

This third transfer type is in violation of RFC 3891 (see below), is not interoperable with other vendors products and in most cases call transfers attempted using this method will fail in unexpected and sometimes surprising ways. While this option is unfortunately enabled by default, it can and should be disabled.

Disabling this transfer method cannot currently be done via the phones Web or Local interface. It must be done in configuration file sip.cfg on the phones central boot server by setting the parametervoIpProt.SIP.allowTransferOnProceeding="0" and then rebooting phones.

Residing on the central boot server, the configuration file sip.cfg contains SIP protocol and core configuration settings that would typically apply to an entire installation and must be set before the phones will be operational. This configuration file contains the parameter which specifies whether to allow a transfer during the proceeding state of a consultation call: voIpProt.SIP.allowTransferOn-Proceeding. If set to 1, a transfer can be completed during the proceeding state of a consultation call. This is the default. If set to 0, a transfer is not allowed during the proceeding state of a consultation call.

The OnSIP service is operating correctly as per RFC 3891 and we will not be providing a server side work around. Here are relevant excerpts from the RFC...

RFC 3891
3. User Agent Server Behavior: Receiving a Replaces Header
...
If the Replaces header field matches an early dialog that was not initiated by this UA, it returns a 481 (Call/Transaction Does Not Exist) response to the new INVITE, and leaves the matched dialog unchanged.

4. User Agent Client Behavior: Sending a Replaces Header
...
A UAC MUST NOT send an INVITE with a "Replaces" header field that attempts to replace an early dialog which was not originated by the target of the INVITE with a "Replaces" header field.

See our top business VoIP phone recommendations for 2017