[sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported

Cullen Jennings <fluffy@cisco.com> Tue, 09 November 2010 20:41 UTC

Return-Path: <fluffy@cisco.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 95A363A692E for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 12:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.565
X-Spam-Level:
X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 DQzvS2vKynyw for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 12:41:20 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E28D73A6A08 for <sipcore@ietf.org>; Tue, 9 Nov 2010 12:41:17 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIGACNB2UyrR7Ht/2dsb2JhbACUJY4CcaJym1KFSgSEWYV9gww
X-IronPort-AV: E=Sophos;i="4.59,175,1288569600"; d="scan'208";a="379183016"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2010 20:41:42 +0000
Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA9KfeDk022920; Tue, 9 Nov 2010 20:41:41 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se>
Date: Tue, 09 Nov 2010 13:42:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D39A3CEB-E8DA-4B4E-A221-A6726AEE2E01@cisco.com>
References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se>
To: sipcore@ietf.org
X-Mailer: Apple Mail (2.1081)
Subject: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported
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: Tue, 09 Nov 2010 20:41:22 -0000

So, in my week of agreeing with Hadriel, I think he got it exactly right when he said there is pretty much no feature a "plain" proxy would need for this. If we are talking about things that would be a strict technical read be considered B2BUA even if they are implemented a lot like a proxy, then I can why something provided something like this functionality would be needed. 

But given this would be used by a B2BUA, I don't see why you need anything more than just normal option tags. Say a SIP message comes from A to B to C and now the response is coming back. C says it supports feature c1, c2, and c3. B knows that it can transparently forward on whatever is needed for c1, c2, but not c3 and it knows that in additional to this it can do features b4 and b5. It modifies the Supported header to have c1,c2,b4, and b5. and sends that back to A. 

If the real uses cases have to do with caller pref features, then B can modify those in the same way. 

Anyways, I think we are way way ahead of ourselves discussing mechanism before we even understand what the use cases are we are trying to solve. I'd like to see some specific real world use cases and so we can work out the real requirements. I'm expect the uses cases will contain B2BUA in the call flows - that's reality. 


On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote:

> 
> 
> Hi,
> 
> I've submitted a draft, which extends the rr-param rule, allowing proxies to indicate supported features using feature tags in Path, Record-Route etc.
> 
> The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-feature-00.txt
> 
> As I indicated earlier on the list, and as you can read in the draft, there is a 3GPP use-case where we believe the mechanism could be used. But, there is nothing 3GPP specific about the mechanism as such.
> 
> Regards,
> 
> Christer
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore