RE: [dispatch] WG Review: Call Control UUI for SIP (cuss)

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Thu, 15 July 2010 15:31 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7583A6A7C; Thu, 15 Jul 2010 08:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.129
X-Spam-Level:
X-Spam-Status: No, score=-4.129 tagged_above=-999 required=5 tests=[AWL=2.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4-Lwxi54L3M; Thu, 15 Jul 2010 08:31:33 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7D7313A6AAD; Thu, 15 Jul 2010 08:31:32 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6FFVd50031833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Jul 2010 17:31:40 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 15 Jul 2010 17:31:39 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Cullen Jennings <fluffy@cisco.com>, Gonzalo Camarillo <gcamaril@gmail.com>
Date: Thu, 15 Jul 2010 17:31:39 +0200
Subject: RE: [dispatch] WG Review: Call Control UUI for SIP (cuss)
Thread-Topic: [dispatch] WG Review: Call Control UUI for SIP (cuss)
Thread-Index: AcskJwQ62AMUW7QnQ6C5gSykgn3XKAAC0q5A
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2140B2241@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <4C28F980.3040702@ericsson.com> <AANLkTinf6-mtUKbdtw0p2j0xJQPBr4S-XCiimSNoKNdC@mail.gmail.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> <4C3D7496.8020905@gmail.com> <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com>
In-Reply-To: <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13
X-Mailman-Approved-At: Fri, 16 Jul 2010 12:35:14 -0700
Cc: DISPATCH list <dispatch@ietf.org>, IESG IESG <iesg@ietf.org>, IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2010 15:31:36 -0000

At least from my perspective (which is from supporting the capabilities of the ISDN User-to-User service) the answer is No. This is information above the SIP layer in an application, and to look at the contents, one must come out above the SIP layer into that application. 

It could be conditional that the SIP message itself is not processed if the information is not there, and the SIP request therefore rejected, but this has nothing to do with the contents. And personally, I do not believe that bit will every happen at a proxy, but will be at the recipient UA.

regards

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org 
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings
> Sent: Thursday, July 15, 2010 3:06 PM
> To: Gonzalo Camarillo
> Cc: DISPATCH list; IESG IESG; IETF-Discussion list
> Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss)
> 
> 
> I don't think this resolves the issue. The issue is if this 
> information is used for a call control. Basically do proxies 
> need to be able to look at this to make decision about what 
> they are going to do. We at least need a Yes/No answer to 
> this question from the proponents of this work and the 
> charter to make that clear. 
> 
> 
> On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote:
> 
> > Hi,
> > 
> > thanks for your comments on the charter proposal. Per the comments 
> > received, we will modify bullet 5 as follows so that it is clearer:
> > 
> > OLD:
> > 5. SIP elements may need to apply policy about passing and screening
> >   the information.
> > 
> > NEW:
> > 5. SIP elements may need to apply policy about passing and filtering
> >   UUI.  The included application, encoding, semantics, and content
> >   information will allow endpoint or intermediary SIP elements to
> >   allow or block UUI based on the type and originator, not based on
> >   the actual UUI data, which may be end-to-end encrypted by the
> >   application.
> > 
> > Further discussions on this topic should happen on the 
> mailing list of 
> > this WG.
> > 
> > Cheers,
> > 
> > Gonzalo
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>