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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Sep 2003 09:44:46 -0400

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.

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]

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 04 Sep 2003 09:59:12 -0500

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