Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (2)

From: [email-masked]
Date: Fri, 12 Nov 2004 19:30:47 EST

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, 
[email-masked] writes:

> 2. Is it wise or valid to explicitly allow a proxy to "upgrade" or 
> "downgrade" the  n-p values in a message?
> ---- I'm coming at this from the DSN perspective, but wps and/or ets may 
> allow this kind of thing.  While the DSN/DSRN/(Q735) would not, that 
> does not invalidate the concept.
> 

If one understands the "proxy" to be the entity which provides call 
processing logic and which validates the calling party's authority to use the priority 
level which they signaled in the INVITE (see 
draft-pierce-tsvwg-assured-service-arch-01), then it should be valid for that proxy to "downgrade" the signaled 
value to the level allowed for that user before forwarding the INVITE rather 
than blocking the call. This behavior should not be disallowed by the R-P 
header draft for any namespace.

I can't think of any "upgrading" case, but there is not reason for the R-P 
header draft to disallow it.

Mike Pierce
Artel
_______________________________________________
Sip mailing list  https://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: David R Oran <[email-masked]>
Date: Sat, 13 Nov 2004 11:09:37 -0500

On Nov 12, 2004, at 7:30 PM, [email-masked] wrote:

> processing logic and which validates the calling party's authority to 
> use the priority level which they signaled in the INVITE (see 
> draft-pierce-tsvwg-assured-service-arch-01), then it should be valid 
> for that proxy to "downgrade" the signaled value to the level allowed 
> for that user before forwarding the INVITE rather than blocking the 
> call. This behavior should not be disallowed by the R-P header draft 
> for any namespace.
>
As long as you have the concept of namespaces, with different policies 
for different namespaces, it follows logically to allow such policies. 
If someone wants a namespace that has a "reject call rather than 
downgrade" as its policy, why prohibit it? Or are you arguing that the 
R-P draft should be silent on upgrade/downgrade/reject other than to 
point out that the allowed behaviors are part of the namespace policy 
definition? If that's what you're saying, I'm ok with that.

Dave.

> I can't think of any "upgrading" case, but there is not reason for the 
> R-P header draft to disallow it.
>
> Mike Pierce
> Artel_______________________________________________
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 15 Nov 2004 12:52:26 -0600

specifying which proxy does any header changes is a market requirement - 
not a protocol requirement - therefore will not be included in the document

At 07:30 PM 11/12/2004 -0500, [email-masked] wrote:
>processing logic and which validates the calling party's authority to use 
>the priority level which they signaled in the INVITE (see 
>draft-pierce-tsvwg-assured-service-arch-01), then it should be valid for 
>that proxy to "downgrade" the signaled value to the level allowed for that 
>user before forwarding the INVITE rather than blocking the call. This 
>behavior should not be disallowed by the R-P header draft for any namespace.
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented