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

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

> Is it possible to skin this differently?
Yes, probably
 
> 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.
Well, I would have said we are having problems with model differences,
but sure.

> 
> 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.
I agree that we want to do what you propose vis-a=vis conferencing.
I'm not at all sure that any of the possible solutions I've thought
of will break that idea.

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

> 
> 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.
I think that's wrong, because by the time the gateway gets the
Replaces, it's too late.  

Remember, that in this sequence, the gateways sees:
	The Invite from Alice to Bob
	Then the hold from Bob To Alice
	Then the Invite from Bob to Carol
	Then the hold from Bob to Carol
	Then the Refer/Replaces from Bob to Alice

We need to know that the call will be a transfer either at the
first hold (the original posting), or at least by the Invite from
Bob to Carol, to distinguish the call from a 3 way, second line, ...
call.  The unfortunate part here is that the PBX sequence won't allow
you to turn a second call on the line into a transfer target.

> 
> 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? 
No, the problem is that the call from Bob to Carol comes from a PBX
extension that isn't Bob's.

You also get a bad experience at Carol's end.  She gets a call from
an anonymous extension.  She talks to Bob.  She has to hang up, then
she gets a call from Bob that is actually Alice.

> 
> 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.
I don't know enough about the other system's to comment.  
In general, it's pretty hard for most systems I know about to maintain
correct callerId if the call comes from different gateways, assuming
that the gateways are user (line) side, and not network (trunk) side.
Any customer served by DID, T1 (CAS), etc. has this problem.  ISDN
can span multiple physical trunks, but have a common D channel, so
I think you couldn't have multiple gateways there either.
Whether any system can complete transfer where the transfer target is 
some existing call, I don't know, but I've never seen one.
That's the fundamental model difference.  The Refer/Replaces
operation says "Replace two existing calls with one new call"
In the middle of the sequence, there are three active calls.
In every PBX that I know, there are only two active calls at any
time.

Look at what Tom suggests: add a header to Invite that says "with intent
to transfer".  That tells the gateway that a transfer operation is
contemplated.  It's a piece of state, and that will cause us some
difficulty.  That piece of information is enough to let the gateway
know what to do when the Invite from Bob to Carol occurs.  It knows
it is NOT a 3 way, or second line call, but an attended transfer.
The operation can be aborted, and we have to clean up the state,
so probably the header has to be on every message from Bob to the gateway
until the call is complete; if the gateway sees Refer, the
Transfer is occurring.  If it sees a Bye from Bob or Carol before
the Refer, it knows that the transfer is abandoned.

Brian

> 
> RjS
> 
> On Thu, 2003-09-04 at 08:44, Rosen, Brian wrote:
> > 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
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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 15:14:47 -0500

inline responses (with portions I'm not responding to snipped)

> I'm not at all sure that any of the possible solutions I've thought

I don't yet see clearly the solutions you've thought of.

What I want to avoid is requiring that every 2nd call-like INVITE
a UA issue be forced to carry the new state you're proposing below
in case it might become the second leg of a transfer later.  I'd also
like to make sure that we preserve the ability to reverse the transfer
direction (transferring B to C instead of C to B) if we discover
midstream that the security properties between us and the associated
gateways indicate that we should do so. 

> you to turn a second call on the line into a transfer target.

Both you and Tom already spoke to one way this could be done with a
less-than preferable transfer target user experience for someone on the
PBX side, so it is possible with warts - the next question is how far
back into the SIP protocol side of the operation do we need to affect
things to reduce the warts - and do we push back into any at all without
requiring an explicit declaration of support for an extension.

> contemplated.

My problem with this is that it only works if the user knows he might
attempt to transfer that connection. The simple "Well we know because
the user pushed a transfer button" approach requires assuming that
it is always the second leg that gets transferred to the first leg
(cutting into our security options and into the deployment of different
user-experience situations like the local mixing ad-hoc conference I
mentioned earlier. It would be a loss if the PBX gateway above
prevented me from doing that if I wanted to when I can clearly do that
if I'm talking to vanilla SIP endpoints).

So, the kinds of solutions I think we need to be looking towards are
more along the lines of indicating that somehow the second invite
might be associated with the first (A "Related-To" header field
for an off-the cuff way to think of it - a statement of a property,
not a statement of intent). And we might need a way for the gateways to
tell the clients "Hey, I'm a PBX gateway and need you to provide extra
information to me if you're going to try do transfer through me". 

>   It's a piece of state, and that will cause us some
(to push a horse that I've probably beaten to hard already:) And if
Bob decides to talk to Carol and Alice at the same time, mixing his
own media, what happens?

RjS

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 12 Sep 2003 10:00:46 -0700

Brian,

Lets be clear here.  This experience at Carol's end only happens due to 
the limitations of the signaling of *this* specific PBX.  I can 
construct a gateway that mimics a PBX phone of a different brand which 
will make this look exactly like transfers, new calls, and conferences 
from a PBX phone.  With this other call, Carol gets a call from Bob, 
she answers, suddenly she is talking to Alice and her connected party 
information is updated to show that.

thanks,
-rohan