Subject: Re: [Sip] Communications Resource Priority Header

From: [email-masked]
Date: Fri, 9 Nov 2001 14:57:02 EST

In a message dated 11/9/01 1:27:55 PM Eastern Standard Time, 
[email-masked] writes:

> [email-masked] wrote:
>  > 
>  > Subject: Communications Resource Priority Header
>  > 
>  > 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.
>  
>  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.
>  
I guess it's not clear to me how Registration fits in. I presumed that, in a 
real situation, Registration needs to be done, for example, when a uses turns 
on a SIP telephone device (maybe including some authentication process, 
biometrics, password, etc). The proxy indicates (as more than just advice) 
"your highest priority is X". It must tell it lots of other things it can do. 
Unless a device is intentionally modified to falsely use a higher value than 
authorized, this indication from the Proxy tells it what it can do. Yes, the 
proxy further authenticates any value used, but I see the CRP as possibly 
impacting the ability to get the first message to the proxy to set up an 
important call. So the Priority value used in that first message is critical. 
(Kind of analogous to "Priority Dial Tone" in the PSTN.)

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 15:24:11 -0500

[email-masked] wrote:

> biometrics, password, etc). The proxy indicates (as more than just advice)

In general (as opposed to the 3GPP model), you do not need to REGISTER
to send a SIP INVITE (make a call). You do have to register to *receive*
a call.

> authorized, this indication from the Proxy tells it what it can do. Yes, the

I doubt that assuming trusted end systems is going to fly.

> (Kind of analogous to "Priority Dial Tone" in the PSTN.)

Again, no REGISTER is needed. The outbound proxy would look at the CRP
value and the user identity, suitably authenticated, and decide whether
the user is authorized to use that value. If not, it could then either
downgrade the CRP or return an error.

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

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 14 Nov 2001 17:10:23 -0600

> > biometrics, password, etc). The proxy indicates (as more than just
advice)

And Vijay further informed
> to send a SIP INVITE (make a call). You do have to register to *receive*

We should have called REGISTER something less conflicted, like SET-CONTACT.
Despite the persistence of 3G's misunderstanding,  REGISTER is NOT an
authentication mechanism, NOT a mechanism for establishing message routing,
and NOT REQUIRED OR NEEDED before one may establish a session. It exists
ONLY to publish dynamic contact information. REGISTER is not even required
to be able to receive a session -- it is just one of a set of techniques for
putting information into a location server, analagous to dynamic DNS
updates.

It would almost be worth changing the name of the REGISTER method in bis-06
(keep the old name as an alias, but deprecate its usage) just to make this
frequent misunderstanding go away. Maybe we could subsume the functionality
of REGISTER into the proposed PUBLISH message, and just deprecate REGISTER.

--
Dean (the unREGISTERed)

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 14 Nov 2001 20:09:00 -0500

> > to send a SIP INVITE (make a call). You do have to register to *receive*

Well, I applaud your belief in the power of words, but I doubt that 3G
or kindred spirits will be deterred from requiring whatever method we
name for unintended purposes, since they want this "ask first before you
can send IP packets" functionality, however misguided and bell-headed
this may be. The only consequence will be that we'll end up with two
methods, with overlapping functionality and mass confusion.