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

From: "Greier, Tom" <[email-masked]>
Date: Wed, 3 Sep 2003 13:36:26 -0400

Hello,

Thank you for the reference. I don't believe that Referred-By would give me what I need, since I need to specify a dialog id in the header (to specify the dialog that will be the transferee). It doesn't look like Referred-By can specify that.

Thanks,
Tom

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2003 2:40 PM
To: Greier, Tom
Cc: [email-masked]
Subject: Re: [Sip] Proposal for 'Transfer-From' INVITE header.

Hi,

Have you seen this?

http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.txt

thanks,
-rohan

On Friday, August 29, 2003, at 11:14 AM, Greier, Tom wrote:

> 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]
>  

_______________________________________________
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

---

From: "Greier, Tom" <[email-masked]>
Date: Tue, 2 Sep 2003 09:53:27 -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.

	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

	Getzville, NY 14068

	Phone: (716) 639-3211

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 04 Sep 2003 10:54:19 +0100

Tom,
 
It is not clear what protocol is being used between the gateway and the PBX.
The need to initiate transfer at the time the first call is held and the
second call is established does not apply to QSIG or DPNSS, for example.
 
John ([email-masked] <mailto:[email-masked]> )
 
-----Original Message-----
From: Greier, Tom [mailto:[email-masked]] 
Sent: 02 September 2003 19:30
To: Greier, Tom
Cc: [email-masked]
Subject: RE: [Sipping] Proposal for 'Transfer-From' INVITE header.

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
                   |
|                                  |
 
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.

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?

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.

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

Getzville, NY 14068

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

---

From: "Greier, Tom" <[email-masked]>
Date: Thu, 4 Sep 2003 09:57:21 -0400

John,
 
That is correct. That protocol between the gateway and the PBX is the
PBX's proprietary digital station protocol. It is not QSIG nor DPNSS.
The PBX's proprietary digital station protocol imposes this transfer
limitation.
 
Thanks,
Tom

	-----Original Message-----
	From: Elwell, John [mailto:[email-masked]] 
	Sent: Thursday, September 04, 2003 5:54 AM
	To: Greier, Tom
	Cc: [email-masked]
	Subject: RE: [Sipping] Proposal for 'Transfer-From' INVITE
header.

	Tom,
	 
	It is not clear what protocol is being used between the gateway
and the PBX. The need to initiate transfer at the time the first call is
held and the second call is established does not apply to QSIG or DPNSS,
for example.
	 
	John ([email-masked])
	 
	-----Original Message-----
	From: Greier, Tom [mailto:[email-masked]] 
	Sent: 02 September 2003 19:30
	To: Greier, Tom
	Cc: [email-masked]
	Subject: RE: [Sipping] Proposal for 'Transfer-From' INVITE
header.

		          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
|                                  

|----------------------------------------------->|   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

				Getzville, NY 14068

				Phone: (716) 639-3211

---

From: "Greier, Tom" <[email-masked]>
Date: Thu, 4 Sep 2003 12:06:45 -0400

Brian,

Yes, and thank you for the clear explanation. I always have trouble
describing this problem since I don't want to burden the description
with too much of the PBX details, but I understanding those issues are
key to understanding the problem. 

Everything you state is exactly correct, and in fact, we currently do
NOT place the transferee call ONHOLD upon receiving the Re-INVITE (hold)
request, since the call would then have to be removed from hold later if
a PBX transfer is requested. Instead, we merely stop the media between
the gateway and the SIP call.

What we do now is that the SIP transferor must send our proprietary
header, 'Transfer-From', in the second INVITE (transfer target)
specifying the SIP transferee dialog id. That way, the gateway can find
the PBX call and the gateway PBX port on which the transfer setup should
take place to generate the outbound call created by the second INVITE
request.

Thanks,
Tom
	
-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, September 04, 2003 9:45 AM
To: Greier, Tom; Hearty, John
Cc: [email-masked]
Subject: RE: [Sipping] Proposal for 'Transfer-From' INVITE header.

Tom

I think your explanation is not quite as clear as it could be,
and starts with one assumption that could be corrected, although
it doesn't fix the problem.

The assumption is that you should put the PBX call on hold when you
get a Re-Invite(Hold).  While that may be expedient, and in some sense
"correct", it starts getting you in trouble, as you note.  If you
instead simply keep the PBX call active, but have the gateway
play a hold tone, then you might think this would fix the problem.

Alas, I don't think that is enough.

The basic problem, as you have explained, is that both the transferee
and the transfer target are PBX subscribers, while the transferor
is a SIP UA.  When you start the transfer, you have a PBX call up
to a specific port on the gateway, and a SIP call from that port to
the transferor.  The transferor wants to make an attended transfer
to the transfer target.  At the end of the transfer, there will be
a PBX call between the transferee and the transfer target, and there
will be no SIP call; the gateway will be out of the loop.

In the middle of the transfer, there are two PBX calls, one on hold
between
the transferor and the transferee, and one active between the transferor
and the transfer target.  The difficulty is that this MUST be on the
same
port of the gateway in order that callerID be correct.  You might point
out to others that this gateway is emulating phones on the PBX.  To keep
callerId to the transfer target correct, the call has to go out the same
PBX port on the gateway as the call from the transferee to the transfer
target.

So, getting back to why it's not enough to fix the hold:
you have a call from Alice to Bob, through the gateway.
Bob is transferring to Carol, also through the gateway.
The gateway first sees:
	Re-Invite(hold)   - as pointed out, you can implement this
without
					putting the PBX call on hold
The problem is that the next message you get is:
	Invite Carol
	From Bob
Now, the gateway, and the PBX, can handle this, even though it already
has a call up from Alice to Bob.  It can put Alice on hold and call Bob.
The problem is that you don't know, at that point, whether you are in
an attended transfer, a 3 way, or just a "second line" call.
If you do the PBX hold at this point, you are back to the problem;
you need to know that the next message you are going to get is
Refer/Replaces, and what you wanted to do is PBX transfer.

Brian
-----Original Message-----
From: Greier, Tom [mailto:[email-masked]]
Sent: Tuesday, September 02, 2003 9:53 AM
To: Hearty, John
Cc: [email-masked]; Greier, Tom
Subject: RE: [Sipping] Proposal for 'Transfer-From' INVITE header.

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.

are

between

Consider the following:

                                     IP
PBX
              Transferor                                    Gateway
Transferee                    Transfer
                   |                                                 |
Target
                   |
|                                  |
 
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.

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.

understand

to

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.

dialed

the

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

Phone: (716) 639-3211

---

From: "Greier, Tom" <[email-masked]>
Date: Thu, 4 Sep 2003 12:23:47 -0400

Robert,

You asked:

>What do you lose if you use a second port until the REFER is issued and
then start what
>the PBX expects for a transfer? Anything more than just an idle port
>for the time one leg is on hold?

What would be lost is the PBX transfer target's perception of an
attended transfer. If the call to the PBX transfer target is made on a
different PBX/gateway port than the PBX transferee call, the gateway
would have to drop the call to the PBX transfer target and then
re-establish it from the gateway port on which the PBX transferee call
resides in order to transfer the call. To the PBX transfer target
subscriber, this would look like a dropped call and then a new inbound
ringing call, which is not an attended transfer.

I agree that it would be useful to have a resolution that works in the
abstract case.  That is what I am hoping for.

Thanks,
Tom

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Thursday, September 04, 2003 10:59 AM
To: Rosen, Brian
Cc: Greier, Tom; Hearty, John; [email-masked]
Subject: RE: [Sipping] Proposal for 'Transfer-From' INVITE header.

Is it possible to skin this differently?

Part of the problem is that there is a mismatch in the capabilities
of the service being built on SIP devices and what your PBX expects.

The way we've constructed transfer, the transferor does not need to
make the decision that it is engaged in a transfer operation until
_after_ the conversation with the potential transfer target has
started. This is behavior we want to preserve - I expect it to have
significant utility assisting with conferencing for example. If nothing
else, it adds the ability to host a locally-mixed ad-hoc conference
at the tranferror's endpoint before the transferror drops out using
REFER and BYEs.

You want to make sure you _can_ traverse a signaling sequence that
results in your gateway dropping out of the path entirely.

I've had a generalized form of this question come up several times in
the last few weeks and I think we should spend some time on this list
talking about how to make sure there's enough information that it can be
made to work in the abstract case. My initial thoughts are that there is
already enough information that can be carried in Replaces to get to the
desired end-state.

Its the transition states that might be able to use more information.
In your case, you want to be able to know if/when you can reuse a
particular port on your PBX for the second call. What do you lose if
you use a second port until the REFER is issued and then start what
the PBX expects for a transfer? Anything more than just an idle port
for the time one leg is on hold? 

Another problem for us to look at is making sure B and C can be
directly connected in a foreign system (a centrex system perhaps)
when the A-B and A-C connections are through different gateways.
If that turns out to be infeasible, we might want to look at ways
we can cause the A-B, A-C connections to be established through
a common gateway before casting off to the foreign system, even
if the original A-B, A-C connections were on different gateways.

RjS

between
same
without
that
between

know
in
the
gateway
complete
call
call
true
for
can
understand
upon
Greier,
> I am usually a passive reader of this forum, but there has been an
issue
call
then
the
key
dialed
the
this
hold
transfer
since
requester
INVITE
the
the
transfer
re-established
we
header
existing

---

From: "Greier, Tom" <[email-masked]>
Date: Tue, 9 Sep 2003 09:58:45 -0400

Hello again,

Any more thoughts on this? Is it worth working on to solve in the
general case, or shall it remain a specific solution to an
interface-specific problem?

Thank you for your help,
Tom Greier

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rosen, Brian
Sent: Thursday, September 04, 2003 9:45 AM
To: Greier, Tom; Hearty, John
Cc: [email-masked]
Subject: RE: [Sipping] Proposal for 'Transfer-From' INVITE header.

Tom