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

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

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.

_______________________________________________
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:09 +0530

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