Re: WG Review: Call Control UUI for SIP (cuss)

Laura Liess <laura.liess.dt@googlemail.com> Mon, 05 July 2010 13:10 UTC

Return-Path: <laura.liess.dt@googlemail.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 EFB1A3A687D; Mon, 5 Jul 2010 06:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level:
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622]
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 lqdGDVZ7tPrg; Mon, 5 Jul 2010 06:10:46 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id B5AE33A67F9; Mon, 5 Jul 2010 06:10:45 -0700 (PDT)
Received: by wwb13 with SMTP id 13so461558wwb.1 for <multiple recipients>; Mon, 05 Jul 2010 06:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MhF5M3aNzr0hS6hiyOSLobHhMLeOVcP/3HMZGnHIpco=; b=JI8Av8QlVwe9zLRnGDQsebd+NED3o7fv/GXQ+1vVwkpCSTWNyFwNrDN6Jr5dScYlX0 AVJQrG7D7MlegKc0oLf7kEGF42BaX1NpeEYlRTZ//vSLiECm7mlSxJnlG7miWoc3WcKa 86sA2TFtUqN/cN9WZXJ7GOVQ2mhktMa7g0hls=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G5qF+UT9DbG8Y37UDHosU+NYQ3/J+H79odZY3MJq1KhpZdGZJCnvoWrZanbQY0iYU7 BsqNGu9vyjxBYWQXChfZNB0lyduhVHzQC22vw6GBPOCPfv+umGi7O0wslusWhKVlkkVm 6rkRPWJV0y6vLhP6qCNNRWoIHHZFjr3aGUlyM=
MIME-Version: 1.0
Received: by 10.227.145.1 with SMTP id b1mr3419998wbv.132.1278335438223; Mon, 05 Jul 2010 06:10:38 -0700 (PDT)
Received: by 10.216.181.6 with HTTP; Mon, 5 Jul 2010 06:10:38 -0700 (PDT)
In-Reply-To: <4C2C5AB4.5020705@ericsson.com>
References: <20100622170002.02B053A683E@core3.amsl.com> <74B1068E-86C0-426E-8E9B-841C23EE9965@cisco.com> <A444A0F8084434499206E78C106220CAE7F5D3AB@MCHP058A.global-ad.net> <BD4EE5F8-6111-45C2-935D-A71E1527C8A5@cisco.com> <4C2C5AB4.5020705@ericsson.com>
Date: Mon, 05 Jul 2010 15:10:38 +0200
Message-ID: <AANLkTing5tcNW3VELKWkh3VJhqAmYsAogGdh5XjMqPif@mail.gmail.com>
Subject: Re: WG Review: Call Control UUI for SIP (cuss)
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH <dispatch@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>, Roland Jesske <R.Jesske@telekom.de>
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: Mon, 05 Jul 2010 13:10:48 -0000

Gonzalo,

> Would a proxy reject a whole request because it carries some type of
> information (without the proxy knowing the exact contents of the
> information)?... or would the proxy remove the information and proxy the
> remainder of the request?.

Today, in the PSTN, DT uses both methods, and needs this also for SIP.
The decision depends on different criteria, e.g. the message source
(different policies for different customers or different application
servers).

>.. or would the proxy need access to the
> contents of the information in order to decide what to do?

There is no need for the proxy to access the content  of the
information and it does not understand it.

 >Also, will
> intermediaries applying policies be proxies or some type of a B2BUA?

The decision is taken by the S-CSCF which is a proxy.

This is the DT point of view. Maybe other service providers or
PBX-systems have different scenarios.

Thanks a lot,
Laura

2010/7/1 Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>:
> Hi,
>
> let's not start discussing (again) whether this information in carried
> in a header field or in a body part. Let's discuss the requirement below
> instead, which seems to be what needs to be clarified in the charter
> (the details on how to encode this will be largely determined by the
> requirements the solution should meet).
>
>>  5. SIP elements may need to apply policy about passing and screening
>>   the information.
>
> I agree the charter needs to be clearer on what types of policies are
> expected and what is needed to apply them. Discussing about the
> granularity of those policies would be useful as well. The charter
> should clarify the questions below:
>
> Would a proxy reject a whole request because it carries some type of
> information (without the proxy knowing the exact contents of the
> information)?... or would the proxy remove the information and proxy the
> remainder of the request?... or would the proxy need access to the
> contents of the information in order to decide what to do? Also, will
> intermediaries applying policies be proxies or some type of a B2BUA?
>
> Thanks,
>
> Gonzalo
>
>
>
> On 01/07/2010 5:31 AM, Cullen Jennings wrote:
>>
>> On Jun 29, 2010, at 3:25 AM, Elwell, John wrote:
>>
>>> Cullen,
>>>
>>> Whilst neither agreeing nor disagreeing with the charter, I did not find anything in the charter that said the information had to be in the SIP header rather than in the body. On what basis do you make that deduction?
>>>
>>> John
>>
>> When I read
>>  5. SIP elements may need to apply policy about passing and screening
>>   the information.
>>
>> And the discussion about it's not just UA. I reached that perhaps flawed conclusion that proxies needed to be able to change the information when "screening" and thus it needed to be in a header. Note I would have far less of an issue with an opaque container for proprietary information if it was in a body instead of a header and had the types of constraints that SIP-T has.
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>