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

Hadriel Kaplan <> Tue, 28 September 2010 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEF2A3A6CA8 for <>; Tue, 28 Sep 2010 08:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pk5O91-AiAvS for <>; Tue, 28 Sep 2010 08:03:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0640D3A6953 for <>; Tue, 28 Sep 2010 08:03:14 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 28 Sep 2010 11:03:55 -0400
Received: from ([]) by mail ([]) with mapi; Tue, 28 Sep 2010 11:03:54 -0400
From: Hadriel Kaplan <>
To: Paul Kyzivat <>
Date: Tue, 28 Sep 2010 11:03:53 -0400
Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
Thread-Index: ActfHl2/Hl5/whWKTTGEN/6XxT026A==
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 15:03:16 -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.

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.


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