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

Janet P Gunn <jgunn6@csc.com> Mon, 15 November 2004 15:00 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29700 for <sip-web-archive@ietf.org>; Mon, 15 Nov 2004 10:00:41 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTiNU-0000KM-MQ for sip-web-archive@ietf.org; Mon, 15 Nov 2004 10:02:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTiDg-0002Y9-JS; Mon, 15 Nov 2004 09:52:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTi78-0001NF-Ui; Mon, 15 Nov 2004 09:45:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28611; Mon, 15 Nov 2004 09:45:53 -0500 (EST)
Received: from amer-mta01.csc.com ([20.137.2.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTi99-0008Tc-Pa; Mon, 15 Nov 2004 09:48:00 -0500
Received: from csc.com (va-fch34.csc.com [20.6.39.227]) by amer-mta01.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAFEjWce007612; Mon, 15 Nov 2004 09:45:32 -0500 (EST)
Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (2)
To: David R Oran <oran@cisco.com>
X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002
Message-ID: <OF35672629.9CF94F6A-ON85256F4D.0050B559-85256F4D.0051378E@csc.com>
From: Janet P Gunn <jgunn6@csc.com>
Date: Mon, 15 Nov 2004 09:47:06 -0500
X-MIMETrack: Serialize by Router on VA-FCH34/SRV/CSC(Release 6.0.3|September 26, 2003) at 11/15/2004 09:46:25 AM
MIME-Version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, sip-bounces@ietf.org, Mpierce1@aol.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Content-Transfer-Encoding: quoted-printable

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:      Mpierce1@aol.com                                         
                      @cisco.com>              cc:      sip@ietf.org                                             
                      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, Mpierce1@aol.com wrote:

> In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time,
> coreya@nortelnetworks.com 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_______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran@cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip