Subject: [SIP] comments on draft-sparks-sip-cc-transfer-00.txt

From: "Schroeder, Tim" <[email-masked]>
Date: Mon, 5 Jun 2000 16:59:05 -0500

Section 4.3: "A TRANSFER method must not contain a body."
 
I'm wondering about the motivation for this blanket restriction.  It seems
to me that just like a TRANSFER tells the transferee whom to invite, there
are also cases where the transferor would like to indicate some of the
parameters of that new call.  Using the ATM-enabled SDP being worked in the
mmusic group now, for example, the transferor might want to indicate some
suggested QoS parameters that the transferee should use for the new call.
Or perhaps the transferor (particularly if there has been contact with the
target, as in a transfer-with-consultation) wishes to suggest some
particular codecs for the new call.  At the very least, the transferor might
want to indicate whether the transferee should initiate an audio-only call
or a multimedia call to the target.  Moving away from SDP, one could imagine
sending an infamous .jpg file of the target, or perhaps a URL to view while
waiting for a transfer to complete.
 
-----
 
Section 4.5: "If the transferee's agent decides to attempt the transfer, a
200 OK response must be returned by the [sic] if it was able to establish a
session with the transferor, otherwise a 603 Decline must be returned."
 
There's a missing word in here, hence the "sic" above.  And do you mean
"establish a session with the target", not establish a session with the
*transferor*?
 
In any case, there are four possible outcomes that I see for a TRANSFER: 
 
(1) There's something wrong with the request.  I think this is dealt with in
that any appropriate 400-600 class response may be returned.  (This is
specified just before the quote I extracted above.)
(2) The transfer is attempted, and succeeds.  The section quoted above seems
to say that 200 OK should be returned in this case, and I agree.
(3) The transfer is attempted, but fails.
(4) The transfer is not even attempted.
 
The section quoted above seems to mandate 603 Decline for both cases (3) and
(4).  I would think that there are cases where the transferor would like to
distinguish between the cases.  For example, I can try to transfer someone
to party A, and if that fails try to transfer them to party B, etc., perhaps
even indefinitely.  Whereas if the transferor doesn't want to be
transferred, there's no point in trying another transfer.  In fact, I would
think (4) is actually (4a) "this particular transfer will not be attempted"
and (4b) "no transfer will be attempted."
 
I'd like to see 603 Decline used only for case (4), and a different
"transfer failed" code returned for case (3).  And I'd like to see some way
to distinguish between cases (4a) and (4b), along the lines of "Busy Here"
vs. "Busy Everywhere".  Probably 603 Decline should mean Decline All (a la
600 Busy Everywhere), and a new 400-class code would be the simple transfer
Decline (a la 486 Busy Here).  I thought about the Retry-After header, but
it wouldn't be clear whether to retry this transfer, or a different one.
 
-----
 
Section 4.6: "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, the UA must submit an INVITE to the resource ..."
 
I don't think that sending the INVITE is necessarily the correct behavior if
the user is not queried.  Certainly if the user is queried and replies, the
action is obvious.  But if the user is not queried, I think there are
scenarios where the INVITE should not be done -- in secure environments,
with a transfer target outside the security boundary, for example.  I think
in the absence of a query or response from the user, the behavior should be
up to the UA implementer, who will probably make it some sort of
configurable option.  But I think "MUST" is too strong here for the default
behavior.  If you do want to mandate some default behavior, I think in the
absence of a user query/response or known user configuration, it would be to
respond with a Decline All.
 
-----

Tim Schroeder 
[email-masked] 
SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX  78759 

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

---

From: "Robert Sparks" <[email-masked]>
Date: Tue, 6 Jun 2000 10:58:58 -0500

> I'm wondering about the motivation for this blanket restriction.

There was list discussion on that matter near the end of March (look
to the archives for my original motivation) and discussion at the
Adelaide meeting. The decision reached was to remove the restriction.

> There's a missing word in here, hence the "sic" above.

Actually, there was an extra "the"

>  And do you mean

Definitely!

> In any case, there are four possible outcomes that I see for a TRANSFER:

More on that section later.

> respond with a Decline All.

I will reword this so that it is obvious that local configuration
can affect the behavior.

For the last statement - if an implementation doesn't (or can't) query
a user, and is by policy not going to accept transfers, why not have
it return a Method Not Allowed?

Robert Sparks

---

From: "Robert Sparks" <[email-masked]>
Date: Tue, 6 Jun 2000 16:51:20 -0500

> it wouldn't be clear whether to retry this transfer, or a different one.

Addressing 4b) first : if the transferee has instructed his UA to accept
no transfers, then the UA could return a 405 Method not Allowed.

Can you sketch an example where it would make a difference to the
transferor's UA if a 603 response was due to 3) or 4a)? From its
perspective, should it care if the response came from the transferee
deciding "I don't want to talk to _that_ person" or "I tried, but
nobody answered".

RjS