Subject: Comments on transfer draft (sparks-sip-cc-transfer-00)

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Mar 2000 13:35:23 -0500

A few low-level comments:

- I'm not sure "TRANSFER" is the right verb here, since transfer implies
moving something from one place to another. All TRANSFER does is
effectively ask the recipient to send another INVITE. It would be nice
if the same action could be used (say) for mesh conferences. While I
agree that using methods is better than adding headers, we don't want
one method per feature, if we can help it. (I.e., we should abstract
what's happening at the signaling layer and then decide what operations
are needed for that rather than just map feature to request name.)

Maybe PLEASE-INVITE or something along these lines. That way, if we need
a 'remote BYE', we can add 'PLEASE-BYE'.

- Using TRANSFER instead of INVITE with Also does have one major
disadvantage, since the originator of the request will retransmit with
T2 (4 seconds).

- According to the rules for feature names, IETF-based extensions are
single words, to avoid any possible confusion with proprietary
extensions having inverted domain names. Thus, it should probably just
be Requires: transfer rather than cc.transfer. (On the other hand, it's
not clear this is needed at all - we don't need Require for new methods,
since they already have a mechanism to say "sorry, je ne comprend pas").

- Telepathy transfer:

"UA receiving a well-formed TRANSFER request SHOULD request approval
   from the user to proceed. In the absence of that request, or upon
                                    ^^^^^^^^
--> If there's no request, the UAS spontaneously emits an INVITE?

   receiving approval from the user, the UA MUST submit an INVITE to
   the resource identified by the Transfer-To: header using the Call-ID
   from the TRANSFER request."

Should probably be UAS, to make things clearer.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Mar 2000 02:48:24 -0500

Henning Schulzrinne wrote:
> if the same action could be used (say) for mesh conferences. 

It would be nice, and indeed this is the motivation which led us to use
Also for both in the original call control draft. Problem is, a full
mesh conference requires much more than just "send an INVITE to
so-and-so". It requires a fair amount of synchronization and additional
semantics, beyond what is needed for transfer. 

However, I agree that the mechanism might have other uses besides
transfer, so something more functional would be nice. I also agree that
we should figure out the primitive functions we need to accomplish the
call control capabilities, and then specify extensions for the
primitives rather than the services. The services themselves can then be
described through informational documents that reference the extensions.
I think the idea proposed in the framework, of basically breaking call
control into separate pieces, is probably a good idea.

> disadvantage, since the originator of the request will retransmit with

An excellent point. Another advantage of BYE/Also over a new method is
that it saves two messages (separate TRANSFER/response and BYE/response)
when implementing your basic blind transfer.

However, I think a new method is better, in the end. It becomes
increasingly complex to figure out how to handle an INVITE or BYE
request if it can be filled with tons of headers, each doing a separate
thing. Also, by overloading BYE, the interpretation of the response
becomes harder. If the response to a BYE/Also was 400, was this because
the transfer failed, or because the BYE itself was bad? Using a specific
method makes it clear what the response means. Also, using a new method
means that the same mechanism can support unattended transfers, blind
transfers, and a bunch of others. 

So, if we go by the philosophy in the "Guidelines for Authors of SIP
Extensions" draft, generality and flexibility wins over efficiency,
which speaks for a new method.

> since they already have a mechanism to say "sorry, je ne comprend pas").

Require is definitely not needed. This is an advantage to new methods as
opposed to new headers in an existing method. 

It would be really nice, however, to know ahead of time whether all
parties supported transfer (and any other mechanisms to be defined). The
Supported extension draft defines a way in which the UAC would indicate
to the UAS that it knows the new mechanism, but that draft does not
mandate that a UAS return a Supported header in the response to any
method (only OPTIONS). We can add this, and say that if a UAS receives a
request (with any method) with a Supported header, it should place a
Supported header in the response and list those features it knows. This
would allow a caller to know whether the called party supports transfer
before trying it. Thoughts?

I noted the following in the transfer draft:
> Explicit non-Requirements
> 
>    1. There is no requirement for the Transfer Target to be notified
>    that he is receiving an INVITE as the result of a TRANSFER request
>    (see comment 2).

Why? I really liked the idea of knowing that this call was the result of
a transfer, and knowing who the transferor was. A UA can always ignore
this information, and then get the basic service you have today. 

The document says TRANSFER can't have a body. Why not? I can think of
some cool uses for this down the road. Why rule it out? 

The draft says:
> UA receiving a well-formed TRANSFER request SHOULD request approval
>    from the TRANSFER request.

This thing about the Call-ID being copied from the TRANSFER seemed odd.
Why is that? If you wanted to accomplish this, it seems better to have
the URL in the Transfer-To header contain the Call-ID as a URL
parameter. In other words, why not do:

Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Robert Sparks <[email-masked]>
Date: Thu, 16 Mar 2000 08:30:03 -0600

> control into separate pieces, is probably a good idea.

I agree with specifying primatives rather than services.

> this information, and then get the basic service you have today. 

I really like the idea too. Perhaps as part of the work right now we
can capture knowing that the call was the result of a transfer (by adding
an informational header to the invite - something that doesn't change
the invite semantics), but my preference is to wait for direction from
the SIP security task folks before addressing telling the transfer target
who the transferor was.

> some cool uses for this down the road. Why rule it out? 

For consistency of implementation? (btw - One of those cool uses could be
providing the identity of the transferor.) The presence of a body 
would likely affect the semantics of the operation (if it were honored,
hence the consistency comment) through side-effects if not directly,
so would it not make sense for the addition of a body to the base
method be an actual extention? Perhaps the restriction should be
loosened to allow any body which if processed, would not affect
the behavior of the request?

> Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays

Interesing thought! Can we explore your thinking more here?
Using this, the TRANSFER would look like

TRANSFER sip:transferee@transfereehost
Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
Call-ID: abc@eeOrorhost

Are you suggesting the subsequent invite look like this?

INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
Call-ID: def@eehost

What would the request-URI parameter be used for then? I'm 
not seeing obvious uses outside of event-logging.

On reflection, I specified this copy because it resulted in
a call-leg tuple that looked the same as it would have after
a sip-cc-01 blind transfer. The motivation that draft had for
this behavior may not apply here. Is there any value in keeping
the Call-ID information accross this function (thinking of it
as PLEASEINVITE instead of TRANSFER)?

RjS

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Mar 2000 11:59:18 -0500

Jonathan Rosenberg wrote:

> before trying it. Thoughts?

It might make sense to have both Allow and Supported in responses other
than OPTIONS. In this case, Allow seems the more appropriate solution,
given that it's a new method and that having two mechanisms to ask for
the same thing seems a bad design. Thus, suggesting that final responses
include Allow doesn't break anything (a UAC could have a simple logic
that did "if response didn't have Allow, send an OPTIONS just in case"),
but it does cut down on traffic. It's much nicer if the UAC can gray out
a Transfer button rather than pop up a failure note after the caller has
said "let me transfer you...".

> some cool uses for this down the road. Why rule it out?

If nothing else, one can always use it for "if you get dropped, here's
the URL to click on to call me back...".

> Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays

Somehow, the recipient of the transfer request must know which call id
this belongs to. It can either be a new call (when TRANSFER is really
acting as a 'create call leg, please' request) or an existing call
(standard transfer). Why create a new call-id if it relates to an
existing call?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Thu, 16 Mar 2000 19:57:26 -0500

Robert:
Thank you for putting the time into solving the problem
of confirmation of transfer completion. This has been on
our hit list as an awkward user experience.

Some comments below:

> said "let me transfer you...".

I agree there is definitely a requirement to know ahead of time whether
the transferee supports transfer.  This seems like a reasonable approach.

> (standard transfer). Why create a new call-id if it relates to an

There are some definite advantages to requiring the transferee
use the same callId as the existing leg with the transferor.  Starting
with the call flow in 5.2.1 and extending it a bit (see below).

The  transfer target can know that the invite from the transferee is
part of an existing call and automatically (or with user approval)
answer it.  This is closer to the typicall experience in a PBX
base transfer in that ther transfer targets phone does not ring
after the consultation with the transferor.

The transferor (after completing the transfer and dropping both
legs to the transferee and transfer target), remembering that
she wanted to pass on some information relative to the
conversation the other two are having, can rejoin the call by
simply sending and invite to either the tranferee or the
transfer target.  Because the tranferor knows the call-id for
the call in progress the same call-id can be reused indicating
to the transferee (or transfer target) that the transfer would
like to join that particular call.  If the transferee supports
bridging of calls this can be a conference, if not the legs
can be toggled to/from hold.

     Transferor           Transferee         Transfer
          |                    |               Target
          |                    |                    |
Call-ID:1 | INVITE/180/200/ACK |                    |
          |<-------------------|                    |

Transferor and Transferee talk

Call-ID:1 | INVITE (hold)/200 OK/ACK                |
          |------------------->|                    |
Call-ID:1 | INVITE/180/200/ACK |                    |
          |---------------------------------------->|

Transferor and Transfer Target talk
If Tranferor supports bridging, it can conference
Transferee back in by taking it off hold

Call-ID:1 | INVITE/200/ACK     |                    |
          |<-------------------|                    |

All three talk.
Transferor gets out of the call.

Call-ID:1 | INVITE (hold)/200 OK/ACK                |
          |---------------------------------------->|
Call-ID:1 | TRANSFER           |                    |
          |------------------->|                    |
          | 100 Trying         |                    |
          |<-------------------|                    |
Call-ID:1 |                    |  INVITE/200 OK/ACK |
          |                    |------------------->|

Transfer target automatically (or interactively)
answers the INVITE from transferee as the call ID
matches the existing call with transferee.

          | 200 OK             |                    |
          |<-------------------|                    |
Call-ID:1 | BYE/200 OK         |                    |
          |------------------->|                    |
Call-ID:1 | BYE/200 OK         |                    |
          |---------------------------------------->|
Call-ID:1 |                    |         BYE/200 OK |
          |                    |<-------------------|

Transferor remembers discussion point for
conversation between Transferee and Transfer
target after completing the transfer and byes.

Call-ID:1 | INVITE/180/200/ACK |                    |
          |<-------------------|                    |

Transferee bridges in Transferee (if not capable
of bridging puts transfer target on hold).  Etc. ...

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Mar 2000 01:09:55 -0500

> the SIP security task folks before addressing telling the transfer target

There isn't going to be any magic poof that causes a solution to be
generated. I think its the job of the author of the extension to propose
some security mechanism so that there can be a starting point for
discussion.

> method be an actual extention?

The presence of a body should not, in any way, alter the basic semantics
of the request. Treatment of a body in TRANSFER is no different than
bodies in any other request. If the UAS doesn't know what to do with it,
it sends a 415. If it does know what to do with  it, it gets processed.

> INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost

No, like this:

INVITE sip:transfer-target@targethost
Call-ID: abc@ee0rorhost

This way, the tranferror could ask the transferred party to add other
headers or even body elements. 

> as PLEASEINVITE instead of TRANSFER)?

Perhaps. By allowing the Call-ID to be used to be placed in the URL in
the Transfer-To header, the transferror can make the call-id the same,
different, or unspecified. This seems to result in maximum flexibility.

Later, Henning Schulzrinne writes:
> the same thing seems a bad design.

You're right, its Allow here, not Supported.

> Thus, suggesting that final responses

Definitely.

-Jonathan R.

---

From: Ilya Slain <[email-masked]>
Date: Fri, 17 Mar 2000 13:49:27 -0800

Robert,
Comment inline.

At 08:30 AM 3/16/00 -0600, Robert Sparks wrote:
>providing the identity of the transferor.)

Do you mean that this could be used for the Originator to
get the contact information of the Screener?  I would think
that hiding this information would be a good thing.

>The presence of a body 
____________________________________________________________________________

Ilya Slain                       ||        ||            Cisco Systems, Inc.
Technology Center               .||.      .||.                    Building 9
                               .||||.    .||||.        170 West Tasman Drive
Tel:    408.527.9446       ...||||||||..||||||||...      San Jose, CA  95134
Fax:    408.527.1221       C i s c o  S y s t e m s
E-Mail: [email-masked]
____________________________________________________________________________

---

From: Robert Sparks <[email-masked]>
Date: Mon, 20 Mar 2000 08:42:03 -0600

> that hiding this information would be a good thing.
No - I was refering more to the function of the security token
in sip-cc-01. The transferor could provide a body with the
appropriate proof of who the TRANSFER originated from.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 20 Mar 2000 14:53:21 -0600

> some security mechanism so that there can be a starting point for

OK - I guess I misunderstood what the security task force was 
supposed to be doing - I had expected an infrastructure as an
end result of their work. 

I am hesitant to integrate a new mechanism for proving the identity
of the transferor, or even reuse the pgp signature approach of 
sip-cc-01 if someone is working an infrastructure that should be used
instead. In any case, such a function should be generalized beyond
just this method, so, again, I am hesitant to place its definition
directly in this draft. Is this thinking way off base?

> it sends a 415. If it does know what to do with  it, it gets 

In those cases where the side-effect of processing the body doesn't
affect the processing of the method (like displaying an optional
visual thumb of the caller), I agree. I have no problem changing
the wording of the draft to allow that kind of body part. However,
if you give meaning to the body parts in the context of processing the
message (such as we have right now with application/sdp - the presence
or absence of that body part affects the state of a receiving SIP engine),
I disagree. What happens when we come up with a body part that affects 
the processing of the method differently depending on the extention?

> headers or even body elements. 

OK - I can see this for the other headers and body-elements, but for
Call-ID itself, are you not just adding redundant information to the
message? If its already in the Call-ID header in the request, how does
it help to have it also in the Request-URI? (My apologies if I'm being
dense).

Robert Sparks

---

From: "Li Li" <[email-masked]>
Date: Tue, 21 Mar 2000 10:38:53 -0500

Just a very simple question on the transfer flows in
the draft. Sorry for my limited understanding of this feature.
But is the reason for the INVITE(hold) from the transferor 
to the transferee just to tell him to hold (taking care of
the media path) and wait for a TRANSFER request (or later may 
be some other requests) to follow? So if the TRANSFER doesn't 
follow, what should be the behavior? Can we do without the 
INVITE(hold) message but just to use the TRANSFER with a (hold) 
to achieve the same thing? The transferee can respond to this 
TRANSFFER request to refuse the transfer. Or a 100 trying 
response tells the transferor he agrees to transfer and 
starts trying and holding the media path. The 200 OK response 
for the TRANSFER then tells the transferor that the transfer 
is successful. My two cents only. Correct me if I'm wrong.

Cheers,

li li 
SS8 Networks Ltd.
Kanata, Ont.
Canada
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Robert
Sparks
Sent: Monday, March 20, 2000 3:53 PM
To: 'Jonathan Rosenberg'
Cc: 'Henning Schulzrinne'; [email-masked]
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)

Robert Sparks

---

From: Robert Sparks <[email-masked]>
Date: Tue, 21 Mar 2000 10:39:42 -0600

Allowing the media relationship between the transferee
and the transferor to be handled outside of the TRANSFER
transaction gives us the greatest flexibility. The examples
I gave showed terminating streams with holds, but other
scenarios may be appropriate depending on the capabilities
of the UA.

RjS

> From: Li Li [mailto:[email-masked]]
> Sent: Tuesday, March 21, 2000 9:39 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Mar 2000 01:05:45 -0500

A few additional clarifications:

Robert Sparks wrote:
> > be some other requests) to follow?

Hold does not also indicate that the far side should wait for a
transfer. Its just a good way to smoothly hand off the media streams. 

 So if the TRANSFER doesn't
> > follow, what should be the behavior?

No different than if someone puts you on hold and never takes you off.
The hold is completely independent of the transfer.

 Can we do without the
> > to achieve the same thing?

You can't do transfer and hold atomically with one message. Thats
because the new TRANSFER method specifically doesn't carry a body such
as SDP. It is not meant to modifymedia session state. Using a single
method to convey multiple different semantics gets complicated, and this
was the whole difficulty with the BYE/Also in the first place.

 The transferee can respond to this
> > is successful. My two cents only. Correct me if I'm wrong.

You are again running into the same issues with BYE/ALso. You are trying
to place two behaviors into one method, so generating responses is hard.
I don't think doing this is a the best approach.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Mar 2000 02:02:00 -0500

> directly in this draft. Is this thinking way off base?

Not sure. Its worth discussing at the security design team meeting.

> or absence of that body part affects the state of a receiving SIP engine),

SDP doesn't affect the processing of the SIP engine, only the component
thats handling the media session. In general, a body should not change
the basic semantic of the request. If a UAS doesn't know what to do with
a body in a particular request, it should reject it.

> it help to have it also in the Request-URI? (My apologies if I'm being

Your not being dense. Its just to avoid special casing the Call-ID. 

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Mar 2000 09:30:40 -0600

> a body in a particular request, it should reject it.

The contents of the SDP body may not affect the processing 
in the SIP engine (past the inclusion of warning headers and
maybe choosing a different response code if it fails to parse),
but the presence/absence of the body in the INVITE request does. 

                            |
INVITE   200 OK     ACK     vs   INVITE    200 OK   ACK
SDP      SDP        noSDP   |    noSDP     SDP      SDP

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Mar 2000 00:44:41 -0500

I think we are now arguing about what consists of SIP engine, and what
doesn't. For the purposes of this draft, I think its OK to say the
request MAY contain a body, and that the UAS SHOULD reject the request
if it doesn't know how to handle that body (same as always) in a
TRANFER.

-Jonathan R.