Subject: [SIP] Re: Comments on transfer draft (sparks-sip-cc-transfer-00)

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:19 +0530

Jonathan Rosenberg wrote:

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

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

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

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

>
> The draft says:
> > UA receiving a well-formed TRANSFER request SHOULD request approval
> >    from the user to proceed. In the absence of that request, or upon
> >    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.
>
> 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

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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:22 +0530

Robert Sparks wrote:
>
> > 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.
>
> 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.

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.

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

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.

> 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

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.

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

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.

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