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

Christer Holmberg <> Tue, 28 September 2010 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 622E73A6B65 for <>; Tue, 28 Sep 2010 09:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.861
X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kAAubmQyDudD for <>; Tue, 28 Sep 2010 09:30:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8B20B3A6BA7 for <>; Tue, 28 Sep 2010 09:30:11 -0700 (PDT)
X-AuditID: c1b4fb3d-b7cbfae00000264e-27-4ca2183c4e6a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 64.57.09806.C3812AC4; Tue, 28 Sep 2010 18:30:52 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Tue, 28 Sep 2010 18:30:47 +0200
From: Christer Holmberg <>
To: Hadriel Kaplan <>, Paul Kyzivat <>
Date: Tue, 28 Sep 2010 18:30:47 +0200
Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
Thread-Index: ActfHl2/Hl5/whWKTTGEN/6XxT026AAAH1nd
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
X-Brightmail-Tracker: AAAAAA==
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 16:30:18 -0000


>Part of me feels like this makes a lot of sense, because indicating 
>proxy capabilities in a Path/Rec-route is similar to Contact, and it would be nice to be able to indicate some capabilities.
>The other part of me thinks "what the heck capabilities can a *PROXY* 
>possibly have"?  A B2BUA would have lots, sure.  But not a real Proxy.  
>(and frankly every 3GPP "proxy" is a B2BUA in all but name)  So if we're talking about B2BUA's indicating capabilities, I've got 
>some comments but I'll send them separately.

Well, we are talking about entities inserting Path and/or Record-Route. Sure, some of them might not be "pure" proxies.

>But for this service continuity use in particular: I don't know why 
>3gpp's bothering to go this route - the ATCF/P-CSCF/whatever is a 
>B2BUA.  It can change the Contact, so have it insert the feature tag in the Contact of the REGISTER, and delete it in the response.
>Problem solved.

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. 

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.



if UE supports multiple registrations and registers over two different access networks and subscribes to reg event package over each registration, then the UE will get the NOTIFYies over both registrations. 
ATCF will however be involved only in the registration over the GPRS/EPS access networks.
Let alone that it would mean quite a lot of XML parsing and assembling.

On Sep 27, 2010, at 10:46 AM, Paul Kyzivat wrote:

> [as chair]
> To all sipcore participants:
> Christer has been looking for a way to accomplish a particular function
> that 3gpp wants. This proposal seems a plausible way to do that. But it
> is of necessity defining a more general mechanism.
> I'd really appreciate comments from others (including people in no way
> involved with 3gpp) regarding this mechanism. For instance, do you
> consider the semantics to be well defined? Do you see need for more
> about security implications?
> How many would find this useful to have?
>       Thanks,
>       Paul