Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

Hadriel Kaplan <> Tue, 28 September 2010 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9FFF3A6D1A for <>; Tue, 28 Sep 2010 10:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q5+7Fcqb1anF for <>; Tue, 28 Sep 2010 10:25:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C76FA3A6B6C for <>; Tue, 28 Sep 2010 10:25:54 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 28 Sep 2010 13:26:35 -0400
Received: from ([]) by mail ([]) with mapi; Tue, 28 Sep 2010 13:26:32 -0400
From: Hadriel Kaplan <>
To: Christer Holmberg <>
Date: Tue, 28 Sep 2010 13:26:29 -0400
Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
Thread-Index: ActfMko7GgIhjib/QcOI+UgTLz20Zw==
Message-ID: <>
References: <> <> <>, <> <>, <> <>, <> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Sep 2010 17:25:59 -0000

On Sep 28, 2010, at 12:30 PM, Christer Holmberg wrote:

>> While the ATCF need not be a "pure" proxy, it is not supposed to modify the dialog identifiers. Without going into details, ATCF 
> acting as B2BUA and changing the dialog identifier would raise a number of issues related to functions like inter UE transfer, access 
> transfer etc. 

What dialog identifiers?  We're talking about a Contact of a REGISTER, no?

> Also note that ATCF adding a feature tag into the Contact header field in REGISTER request would also cause reg event package 
> NOTIFY to contain the added feature tag. The UE receiving the reg event package NOTIFY would be quite confused as its contact 
> address would have additional feature tags. Parsing and modifying the XML is not desired.

Don't bother keeping it that way then.  This is already a private network thing to begin with, so specify that the S-CSCF treats that 3gpp.svcc thing of a REGISTER as the network-inserted indication that it is, rather than as opaque UE capabilities (ie, so it won't show up in XML stuff, because it won't be stored in the UE's normal Registered feature tags set in the databases).  Or are you worried about a case of the REGISTER going to another domain (like through a Visited to a Home domain)?