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

From: "Schroeder, Tim" <[email-masked]>
Date: Wed, 7 Jun 2000 15:18:33 -0500

> > 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.
> > (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).
> >
> > (4) is actually (4a) "this particular transfer will not be attempted"
> > and (4b) "no transfer will be attempted."
 
> Addressing 4b) first : if the transferee has instructed his UA to accept
> no transfers, then the UA could return a 405 Method not Allowed.

Agreed.

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

Maybe. :-)

One example might be if the transferor might consider retrying the TRANSFER,
perhaps after some time had passed, perhaps after doing some out-of-band
thing to make it more likely that the transfer would succeed.  Maybe the
Bonds Department tries to TRANSFER the call to the IRA Department, and it
fails because everyone is busy.  But when a busy response is generated, a
page goes out to have all the loiterers get back to the phones, so a little
later the call might succeed.  That TRANSFER failure would be different than
a Decline (meaning "don't you dare transfer me to the IRA Department -- they
transferred me to you!").

The difference might also be useful in planning one's call handling
scenarios.  If a high proportion of transfers from "General Support" to "OS
Support" are not succeeding, it's different if they are failing because "OS
Support" is understaffed and the calls are failing, vs. callers are
declining to be transferred to "OS Support" (because "General Support" is
cavalierly transferring callers there when the callers are sure it's an
application problem, or because they've had bad experiences with OS Support
in the past, or ...).

I could maybe contrive some more examples, but these are the two that come
to mind first.  I guess if the transferor and the target are un-related, it
doesn't make much difference if the transfer fails because it was tried and
failed, or because it was declined.  But in the cases where the transferor
and the target are more tightly coupled (in the same umbrella organization,
perhaps), it does seems to make a difference.  The user-to-user session can
proceed differently if the TRANSFER failed because the transferee
declined/balked, or whether the TRANSFER failed despite the agreeableness of
the transferee.

So, using my numbering scheme, I still like
(1)  400-600-class failure [problem with the TRANSFER request]
(2)  200 OK [transfer attempted and succeeded]
(3)  ??? [some response that specifically means transfer attempted but
failed]
(4a) 603 Decline [this particular transfer will not be attempted]
(4b) 405 Method Not Allowed [no transfer method will be attempted]

(If the transfer was actually attempted, even knowing *why* the transfer
failed could be useful in some cases.  If Boss transfers calls to Peon, Boss
may be interested in knowing whether the failure was because Peon is
responding with 603 Decline or because of 500 Internal Server Error.  I
suppose in case (3), the transferee's UA could optionally include a reason
phrase conveying any desired information about the transfer failure, while
still using the status code that means only "transfer actually attempted but
failed".)

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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Jun 2000 17:15:18 -0400

> (3)  ??? [some response that specifically means transfer attempted but

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". Thats exactly the case here. You could even
include a Retry-After in the response indicating when to try.

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