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

From: "Greier, Tom" <[email-masked]>
Date: Tue, 2 Sep 2003 14:30:06 -0400

Thanks for the response. I've moved this to the sipping list.

	You are correct that the transfer flow (attended transfer) is
covered in the cc-transfer draft, section 6. But, the draft does not
cover the issue that we are having.
	 
	We are trying to implement this on the PBX gateway so that we do
not trombone the transfer over IP across different PBX lines. Therefore,
we are trying to implement the transfer on a single PBX line. 
	 
	PBXs/KSUs have the limitation in that there is a distinct
difference between a call that is just onhold and a call that is
onhold-pend-transfer (transferee waiting to be transferred).
	 
	Consider the following:
	 
	                                     IP
PBX
	              Transferor
Gateway                         Transferee                    Transfer
	                   |
|
Target
	                   |
|                                  |
	       dialog1  | INVITE/200 OK/ACK
|                                  |
	
|----------------------------------------------->|  establish call
---------->|                                  |
	       dialog1  | INVITE (hold)/200 OK/ACK
|                                  
	
|----------------------------------------------->|  
	       dialog2  | INVITE/200 OK/ACK
|
	
|----------------------------------------------->|   establish call
-------------------------------------------> |
	       dialog2  | INVITE (hold)/200 OK/ACK
|
	
|----------------------------------------------->|  
	       dialog1  | REFER
(Refer-To:sip:TransferTarget?Replaces=dialog2) 
	
transfer call

	When the gateway receives the initial INVITE for dialog2, it
needs to know if the intent of the call is to eventually transfer
dialog1 to dialog2 in order to perform an attended transfer on the PBX
side. 
	 
	If the gateway does NOT know the intent upfront, it will merely
place the dialog1 call onhold in order to originate the dialog2 call.
When the gateway subsequently receives the REFER request, the gateway
can not simply complete a transfer, since a transfer was never started.
The dialog1 transferee call is onhold, not onhold-pend-transfer. The
gateway would have to tear down the call to the transfer target,
initiate a transfer from the transferee call (placing the transferee
onhold-pend-transfer), and then complete the transfer. The PBX transfer
target party would be disconnected and then a new call would ring in on
the PBX transfer target party. It would not be a true attended transfer
on the PBX side of the gateway.
	 
	If the gateway DOES know the intent upon receiving the initial
INVITE for dialog2, it can initiate a transfer immediately and dial the
dialog2 PBX transfer target party. When the gateway receives the REFER
request, it can then complete the transfer on the PBX side. To the PBX
transfer target, it would be a true attended transfer.
	 
	I hope that I am describing our problem clearly. Any ideas?
	 
	Thanks,
	Tom Greier

	 -----Original Message-----
	From: Hearty, John [mailto:[email-masked]] 
	Sent: Friday, August 29, 2003 6:30 PM
	To: Greier, Tom
	Cc: [email-masked]; [email-masked];
[email-masked]
	Subject: RE: [Sip] Proposal for 'Transfer-From' INVITE header.

		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]

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 12 Sep 2003 09:55:01 -0700

On Tuesday, September 2, 2003, at 11:30 AM, Greier, Tom wrote:

> You are correct that the transfer flow (attended transfer) is covered  
> in the cc-transfer draft, section 6. But, the draft does not cover the  
> issue that we are having.
>  
> We are trying to implement this on the PBX gateway so that we do not  
> trombone the transfer over IP across different PBX lines. Therefore,  
> PBXs/KSUs have the limitation in that there is a distinct difference  
> between a call that is just onhold and a call that is  

Herein lies the problem. I have used several PBXs that do not suffer  
from this limitation.  I would go so far as to call this a bug.  I do  
not think it is compelling that SIP should add a new header in order to  
facilitate interoperability with a proprietary signaling interface that  
places a pointless arbitrary restriction on what you can do with your  
call legs.

My old PBX desk phone which I got rid of 4 years ago in favor of an IP  
phone supported arbitrary operations on two calls using one line. For  
example, once I had an active call and pressed the Conference button,  
my first call was placed on hold and I could make a new call.  However,  
I could switch back and forth between the two calls, drop one or both  
calls, transfer one to the other (in either direction), or place them  
in a conference.  The PBX did not need to know what I was intending to  
do in advance.  This is especially important because people change  
their minds.  (Yes, the caller ID and connected party ID worked  
properly).

That your PBX is so rigid that it required some type of "precognition"  
is extremely unfortunate. While I empathize that you are just trying to  
do as much as possible with this PBX you are using, I don't think this  
lack of functionality on the PBX side merits hacking up the SIP  
protocol, and possibly harming interop with clients that want to offer  
arbitrary manipulations of multiple call legs.

thanks,
-rohan

> IP                                                            PBX
>        dialog1  | INVITE/200  
> OK/ 
> ACK                                                     |               
>        dialog1  | INVITE (hold)/200  
> OK/ 
> ACK                                                                     
>            |                                 
>        dialog2  | INVITE (hold)/200  
> OK/ 
> ACK                                                                     
>            |
>        dialog1  | REFER (Refer-To:sip:TransferTarget?Replaces=dialog2) 
>                                                                         
>   transfer call
>                                                                         
>   
>  
>  
> When the gateway receives the initial INVITE for dialog2, it needs to  
> know if the intent of the call is to eventually transfer dialog1 to  
> dialog2 in order to perform an attended transfer on the PBX side.
>  
> If the gateway does NOT know the intent upfront, it will merely place  
> the dialog1 call onhold in order to originate the dialog2 call. When  
> the gateway subsequently receives the REFER request, the gateway can  
> not simply complete a transfer, since a transfer was never started.  
> onhold-pend-transfer), and then complete the transfer. The PBX  
> transfer target party would be disconnected and then a new call would  
> ring in on the PBX transfer target party. It would not be a true  
> attended transfer on the PBX side of the gateway.
>  
> If the gateway DOES know the intent upon receiving the initial INVITE  
> for dialog2, it can initiate a transfer immediately and dial the  
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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?
>
>  
>
> 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
>
>  
>
>  
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> OfGreier, Tom
> Sent:Friday, August 29, 200312: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.
>
>  
>
> 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  
> 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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP