Subject: Explicit Status Codes for Redirection (I-D v.12)

From: "Jens Lundström" <[email-masked]>
Date: Fri, 5 Mar 1999 10:38:39 +0100

Hi all, 

at the risk of beeing flamed for trying to *add_yet_
another_status_code_to_take_care-of*, here are 
three additional Status Codes for Redirection 
who I think will help give more explicit and valuable
behavioral if added to the Draft.

They can be seen as clearifications/extensions to the 
"300 Multiple Choices" code and are the following :

*** 381     Find First in Multiple Choices ***

A seq of ordered choices of URI's, try to connect in 
this order and stop with first that accepts

*** 382     Find Any in Multiple Choices ***

A seq of non-ordered choices of URI's, 
try to connect with them and stop when 
first accepts

*** 383    Find All Multiple Choices ***

Redirect to several URI's, all *should* be 
followed and accept and if not, stop the 
session.

*** 384   Find As Many as Possible Multiple Choices ***

A seq of none ordered URI's, connect with 
as many as possible

Examples of Usage :
================

381 can be used as standard "VAS" service, e.g. 
first try me, then my friend, then my friends friend 
and so on... Stop as soon as some one accepts.

382 as 381 but I do not have a total ordering of my friends

383 can be used when a session is set up and 
where the callee should e.g. both get trough a 
VoIP session and get a homepage 
shown to him (helpdesk scenario).

384 as response used when the initally called 
SIP URL acts as an alias for several other SIP 
URL's, i.e. as a group alias.

Comments :
==========

The 300 response code states only that there are 
multiple choice and that they might have an 
prefeered ordering among them (q-value).
from our prototypin we have found that it 
could be useful to have a clearer semantic in this case.

The behavioral given by 381-384 can be handled 
by a SIP Proxy Server but with regards to performance
 and scaling I would like to see it possible to explicitly 
state the above behavioral and have the SIP UA handle it.

In some sense the "q-value" on pp.37 (I-D v.12) states 
the relative priority of Contacts within a 300 response but 
it does not tell anything of it is a "first" or "all" or "as 
many as possible" behavioral that is wanted. This 
"q-value" should be used within a 381 response and
is what will be used to decide the ordering.

It might be possible to replace the proposed 382 
repsonse by a 381 reponse where "q-values" are 
left out of the "contacts" however I feel it is better to 
have to separate response codes with well defined semantics.

mvh / Jens

-- 
Jens Lundstrom, M.Sc.       e-mail    [email-masked]
Ellemtel Utvecklings AB     tel       +46.8.681 26 55
MG/EUB                      cellular  +46.70.667 84 98
S-126 25 Stockholm          fax       +46.8.681 20 66
Sweden                      http://www.ellemtel.se

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Mar 1999 16:03:27 -0500

There is a subtle underlying assumption with this proposal which
warrants discussion. The assumption is that it is the server which makes
the determination about whether its find first, find any, find all, etc.
As you point out, different services are enabled depending on the
interpretation of the Contact list. However, I would argue that it is
the caller who ultimately specifies what the service they want is, not
the server.

For example, when I call [email-masked], I want to reach just one
person. If the server returns 383, what does that mean? I don't want to
speak with each one. I want only one of them. Whats needed is way for me
to tell the server that I want just one, and not a group. This, in fact,
is one of the motivations for our caller preferences draft,
draft-ietf-mmusic-sip-caller-00.txt. This draft allows a caller to
specify their preferences for the call. These are then merged with
administrator and callee preferences. For example, I might call
[email-masked] and express a preference for a single person, with
video, that speaks Spanish. I might then get redirected to a priority
listed set (by q value) of microsoft personnel that speak Spanish and
have video capabilities. 

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen