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

From: [email-masked]
Date: Sat, 13 Nov 2004 13:46:39 EST

In a message dated 11/13/2004 11:09:54 AM Eastern Standard Time, 
[email-masked] writes:

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

Absolutely. Rejecting a call for this reason is perfectly okay. The R-P 
document should be silent on these types of issues, or, at the most, can mention 
the different types of behavior which "MAY" be used, but not attempt to 
associate each possible behavior with various namespaces.

Mike

_______________________________________________
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: Janet P Gunn <[email-masked]>
Date: Mon, 15 Nov 2004 09:47:06 -0500

As I understand it, the proxy would only be allowed to upgrade or downgrade
the value if that were the behavior specifically identified for THAT
namespace.

As far as I know, neither ets nor wps have current requirements to do that.
But the circuit switched versions DO have the concept of a "default
priority value" under certain circumstances.  If that concept were applied
to the IP side, it MIGHT involve upgrading or downgrading to the default
level.

I am comfortable with it being left in as a possible behavior, if and only
if that behavior is explicitly specified for that namespace.

Janet

----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

                      David R Oran                                                                               
                      <oran                    To:      [email-masked]                                         
                      @cisco.com>              cc:      [email-masked]                                             
                      Sent by:                 Subject: Re: [Sip] -resource-priority-05.txt: Comments and        
                      sip-bounces              Recommendations (2)                                               

                      11/13/2004 11:09                                                                           
                      AM                                                                                         

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

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