Subject: [Sipping] RE: [Sip] Proposal for 'Transfer-From' INVITE header.

From: "Hearty, John" <[email-masked]>
Date: Fri, 29 Aug 2003 16:30:28 -0600

This probably belongs on the sipping list rather than sip.  If I
understand your flow correctly, this attended transfer flow is covered
in the cc-transfer draft section 6.  By the way, this draft recently
expired, what's the status Robert or Alan?

This statement seems to be at the heart of the issue:

On a PBX, the 'intent' needs to be known upfront, since the way that the
call is put onhold depends on the intent of the requester (put the call
onhold so another call can be made, or put the call onhold-pend-transfer
to eventually dial a transfer target).

It is not clear to me why the transferee needs to know the intent while
going on hold. The transferee certainly learns the intent of transfer
upon receiving the Refer.  What different actions does the transferee
need to take regarding going on hold prior to transfer vs. regular hold?

John Hearty

Level3

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Greier, Tom
Sent: Friday, August 29, 2003 12:14 PM
To: [email-masked]
Cc: Greier, Tom
Subject: [Sip] Proposal for 'Transfer-From' INVITE header.

Hello All,

I am usually a passive reader of this forum, but there has been an issue
that my development group has been struggling with for a while. We have
been using a 'proprietary' header for some time, for which I am hoping
to legitimize via a draft or get information as to existing solutions.

On most PBX and key system digital stations, in order to perform a
supervised transfer of a call, the transferee is put onhold and a new
call is automatically created in the dialtone state. The transfer target
is then dialed on the new dialtone call. If the transferor decides to
complete the transfer, the transferor usually either hangs up or presses
a transfer key to complete the transfer.

This scenario is a two-step transfer process:

1) Put transferee onhold-pend-transfer, which creates new call to be
dialed on to reach transfer destination.

2) Complete transfer.

The two-step transfer process allows the transferor to possibly abort
the transfer, drop the transfer destination and reconnect to the
transferee call.

In implementing a PBX/SIP gateway to PBX/key systems that operate in
this manner, we have a problem with Re-INVITE (hold), INVITE (new
party), REFER/replaces to perform the transfer. When the gateway
receives the Re-INVITE (hold) method, the gateway does not know the
'intent' of the hold request. Is it a regular 'put the call onhold', or
is the requestor intending to later make another outbound call on the
same line and transfer the original call. On a PBX, the 'intent' needs
to be known upfront, since the way that the call is put onhold depends
on the intent of the requester (put the call onhold so another call can
be made, or put the call onhold-pend-transfer to eventually dial a
transfer target).

In order to support this functionality, we have been using our own
'Transfer-From' header. The 'Transfer-From' header is placed in the
INVITE that the requestor sends to dial the transfer destination. The
'Transfer-From' header specifies the call-ID of the transferee call that
the gateway should put onhold-pend-transfer. The destination specified
by the INVITE in the To header is then dialed as the transfer
destination. If the requestor later sends a REFER/replaces specifying
the transferee and the transfer target, then the gateway completes the
transfer. The requestor can also send a BYE or CANCEL on the transfer
target dialog to drop the transfer target and unhold the original
transferee call. Media is then re-established to the original transferee
call upon the gateway receiving a Re-INVITE (unhold) request.

I know that this is very specific to a PBX-gateway device, but is what
we are doing relevant to any other interfaces/implementations? Is this
header viable in any broader sense, is it worth a draft, or is there an
existing standard for this type of functionality?

Thank you for your help.

Tom Greier

Intel Corporation
Network Building Block Division
55 Dodge Rd.

Getzville, NY 14068

Phone: (716) 639-3211
mailto:[email-masked]