Subject: [Sip] Communications Resource Priority Header

From: [email-masked]
Date: Fri, 9 Nov 2001 12:20:17 EST

Subject: Communications Resource Priority Header

I will start a new thread with a meaningful subject, instead of the 
"Introducing the new bis..." that I started. Hope this will catch on.

To summarize comments and conclusions so far:

Current SIP Priority Header and its values will not change. This is viewed as 
the priority from the "human" perspective to be used by the receiving user 
(for example, to sort calls to answer). Therefore, it is not necessary to 
define an order to these values.

A new header will be created (for MLPP-type priority, but not called "MLPP"). 
This defines the priority to be used by the network to allocate resources, 
etc. Call it a "Communications Resource Priority Header". This will not be 
defined in the MLPP description document. Contents to be determined, but it 
needs to include (or be able to include) the lower 5 levels defined in RFC 
791 as well as CRITIC/ECP. An order must be defined (or implicit) for all 
values.

Functionality required should be documented in a separate draft for MLPP. It 
could address not only the use of the CRP header, but other aspects such as 
the use of DiffServ, RSVP, etc.

My further comments:

1. The distinction between the Priority Header being for humans and the new 
CRP header being for the network to control resources isn't really that 
clean-cut (nor should it be). It is perfectly okay for the end device (a SIP 
phone designed for military use?) to mix the two concepts or to make the CRP 
values visible to the user and to not use the current 2543bis defined values 
at all. As Jim commented, "This [relationship] would be an administrative 
issue within the Domain implementing these features/functionalities".

2. To allow greater flexibility, we should define the values in the CRP 
header without referencing the actual English words used for the specific 5 
levels (for MLPP). Other applications may use more levels and would certainly 
call them something else. Note that other IETF work efforts on "Priority" 
have suggested 16 or 65k numeric values. Within a network or domain, the 
association between numeric values and the meaning in that network could be 
defined by local practices. It is assumed that there is no need to compare 
values between different networks or domains (just like MLPP does not include 
preemption of calls in other "domains".)

3. The CRP may be used to control access to both PSTN circuits and IP 
resources. We already know what this means for PSTN circuits. What "access to 
IP resources" means needs to be addressed, probably outside of SIP/SIPPING.

4. The issues of limiting access to priority levels is the same as limiting 
access to any other SIP defined capabilities. This is presumed to be a part 
of Registration.

5. If the definition of this new CRP header is one page, it would seem better 
to include it in the base document (2543bis). This could help to clarify the 
relationship/difference from the existing Priority Header.

Mike Pierce
Artel

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 09 Nov 2001 12:57:22 -0500

> To summarize comments and conclusions so far:

Thanks for trying to summarize.

> define an order to these values.

It is still useful to define an ordering. This is implicit right now,
but only requires a sentence. Presumably, new values for the header
would indicate their position ("between urgent and emergency"), but
treated by those not knowing the value as the lowest priority.

> 791 as well as CRITIC/ECP. An order must be defined (or implicit) for all

Yes.

> issue within the Domain implementing these features/functionalities".

Maybe; I suspect that there will be some clear uses for each header, for
example call routing to different devices will use Priority ("emergency
goes to cell phone"), while use of elevated priorities in gatewaying to
the PSTN will only use CRP. It would probably be useful to include such
examples in the respective definitions, even though they are only
examples. That should give people the right idea what to use when.

> preemption of calls in other "domains".)

Having different name spaces in the same header doesn't seem wise to me.
Either the name space needs to be labeled (CRP: 16 ;domain="foo.com") or
it should be the same. Messages always "leak" between domains, which
would make things confusing.

Just like message encoding, I find textual labels less error-prone, so
the basic 791 set should, in my opinion, have names, not numbers.

> IP resources" means needs to be addressed, probably outside of SIP/SIPPING.

Yes, and expect to wear an asbestos suit as you cross the layer chasm...

> access to any other SIP defined capabilities. This is presumed to be a part

No. Registration, at least in the SIP sense, has nothing to do with
this. Any enforcement would be part of the proxy's role. At best, at
REGISTER time, the registrar could indicate, as advice, "your highest
priority is X", but that has little value beyond information.

A new Warning header value may be useful here.

> relationship/difference from the existing Priority Header.

The spec becomes the Manhattan phone book one page at a time,
unfortunately.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs