Re: [sipcore] #29: B2BUAs passing H-I through?, #28 UAC adds initial HI

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 17 September 2010 18:21 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B333A689B for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 11:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level:
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 g2w8UDvzArOs for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 11:21:31 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id C685B3A688E for <sipcore@ietf.org>; Fri, 17 Sep 2010 11:21:31 -0700 (PDT)
Received: by gwb20 with SMTP id 20so1135722gwb.31 for <sipcore@ietf.org>; Fri, 17 Sep 2010 11:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=h2UN5th0pPFSy2T7rYt0zJ4/UOgtg7CmHDwLD3vXhR0=; b=xIWEkCE/Rovyb7Nvp31q37XoXvsaOfhZni7DfK3knfC93I9hWqtWw8C7ZSwAUJHHLh i561t8UntAihDw1zE2lGm/XWI1XbijGdW4QqLtCpE8opznlWCN8bniG9/UJMZ5W5xW0K R7GpxWLxNIoGBsaFUQAiKO8yE8YV5PqdsQoW8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CnhQDZbLY+5CyJIKDLF25TCCp7lMzXwU+8oRRIsbn8S9bee5Z3mAxdVwi54mjKrYbY eyTaPN2DKtZ50cjbiRkFHxUKyK5YWps0qiie5Un0DkSkRCfCvVcMaT0slTZj8mLJwXg+ KaPa555M59R4ZWO/WnJR5stN/k9mlw58tGWys=
MIME-Version: 1.0
Received: by 10.151.99.19 with SMTP id b19mr5870181ybm.178.1284747713068; Fri, 17 Sep 2010 11:21:53 -0700 (PDT)
Received: by 10.236.108.172 with HTTP; Fri, 17 Sep 2010 11:21:53 -0700 (PDT)
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C63@DC-US1MBEX4.global.avaya.com>
References: <AANLkTi=SaY6hNPHCUU6d0mWmK7cZuL9py9z4Ui1Ym=Gt@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79C63@DC-US1MBEX4.global.avaya.com>
Date: Fri, 17 Sep 2010 13:21:53 -0500
Message-ID: <AANLkTikK-svMrD0_af0zSqEJ3i++27hy+DV3rJGEiWvw@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] #29: B2BUAs passing H-I through?, #28 UAC adds initial HI
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2010 18:21:32 -0000

Dale,

I think you totally  missed my point. My suggestion is to add a MAY in
terms of UAC b2bua behavior, something like the following (removing
the text about "Normally,...,")
   In the case of a B2BUA implementation,
   a UAC MAY add the hi-entries received in the incoming request at the
   UAS to the subsequent outgoing request.

We cannot however mandate B2BUA behavior since there are no normative
specifications for B2BUA behavior.

Mary.

On Fri, Sep 17, 2010 at 1:02 PM, Worley, Dale R (Dale)
<dworley@avaya.com> wrote:
> ________________________________________
> From: Mary Barnes [mary.ietf.barnes@gmail.com]
>
> There is text that says that a UAC can add History-Info in section
> 4.1, which is the text Hadriel refers to in the original issue.
>   "Normally, UACs are not expected to include a History-Info header
> in an initial
>   request as it is more of a Proxy function; the main reason it is
>   allowed is for B2BUAs who are performing proxy-like functions such as
>   routing."
>
> Issue #29 suggests this should to be stated normatively (as well as
> including this in the UAS section). It seems to me that we can make
> that a MAY strength. It's not clear to me that we need to add anything
> to the proxy section for B2BUAs as I really don't want to get into
> trying to define B2BUA behavior beyond what is absolutely necessary in
> this document.
> _______________________________________
>
> Well, strictly speaking, a B2BUA isn't a proxy.  The behavior we want to enable is part of the UAC function of the B2BUA.  But it seems to me that we want to enable this behavior normatively, and describe it much more clearly.  The current text mentions it only in passing, and while "there is only one thing that it could mean", that is not a good specification.
>
> Dale
>