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

From: "Schroeder, Tim" <[email-masked]>
Date: Wed, 7 Jun 2000 14:26:01 -0500

Sorry about missing the decision to remove the blanket restriction against
bodies in TRANSFER messages.

> > 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.
> 
> Actually, there was an extra "the".

My copy still doesn't read right after taking out "the", but I trust you
will make the final copy make sense. :-)

> > I think in the absence of a user query/response or known user
configuration, it
> > would be to respond with a Decline All.
>
> 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?

That sounds good.  I suppose you could even use it if the transferee was
queried and the response was "for this session, I am unwilling to consider
being transferred".  As far as the particular session was concerned, the
TRANSFER method would no longer be allowed.  The transferee could even try a
few proposed transfers that turned out to fail (or decline them one-by-one,
or a mixture of both) and eventually give up in disgust and send back a
Method Not Allowed.  

There is a difference between TRANSFER being unsupported by the software and
TRANFERs being declined wholesale by the user, but I'm not sure it's
important to relay that information to the transferor.  It might even be
considered a privacy issue to convey it.

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: "Schroeder, Tim" <[email-masked]>
Date: Tue, 13 Jun 2000 08:58:44 -0500

> > (1) 400-600-class failure [problem with the TRANSFER request]
> > (2) 200 OK [transfer attempted and succeeded]
> > (3) ??? [response that specifically means transfer attempted but failed]

[Jonathan R. responds:]
> I would say this is a 500 class response. I believe 500 class responses
> generally mean, "this request failed this time, but the same request
> might succeed later on". That's exactly the case here. You could even
> include a Retry-After in the response indicating when to try.

With the Retry-After probably copied from the response to the failed
transfer INVITE, if present.  I say "probably" because one could likely
contrive an example where the transferee has additional knowledge that
enables it to generate a better Retry-After value.  But the normal case
could be to copy the Retry-After value, in effect saying, "I tried the
transfer and it failed; they told me to try again in this many minutes; send
me another TRANSFER then if you'd like me to do that."

Tim Schroeder
[email-masked]