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

Dean Willis <dean.willis@softarmor.com> Fri, 22 October 2010 20:58 UTC

Return-Path: <dean.willis@softarmor.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 1DF863A695A for <sipcore@core3.amsl.com>; Fri, 22 Oct 2010 13:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.026
X-Spam-Level:
X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=0.573, 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 FL+znFGGqGuP for <sipcore@core3.amsl.com>; Fri, 22 Oct 2010 13:58:40 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 17D4B3A68BA for <sipcore@ietf.org>; Fri, 22 Oct 2010 13:58:39 -0700 (PDT)
Received: by yxp4 with SMTP id 4so1112336yxp.31 for <sipcore@ietf.org>; Fri, 22 Oct 2010 14:00:18 -0700 (PDT)
Received: by 10.101.6.30 with SMTP id j30mr2542235ani.168.1287781218370; Fri, 22 Oct 2010 14:00:18 -0700 (PDT)
Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) by mx.google.com with ESMTPS id 13sm4019389anq.10.2010.10.22.14.00.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 14:00:17 -0700 (PDT)
Message-Id: <AE80C7A9-D12C-4E0A-99B3-24F0128C806A@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
In-Reply-To: <FB2F77FC-79D9-45CB-8635-0F5A09D3B0E4@acmepacket.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 22 Oct 2010 16:00:15 -0500
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> <4CA0AE61.7060003@cisco.com> <AANLkTinOrkS-_n8jbbLzhqEhPBPYiJs33V2ie3XoO=He@mail.gmail.com> <FB2F77FC-79D9-45CB-8635-0F5A09D3B0E4@acmepacket.com>
X-Mailer: Apple Mail (2.936)
Cc: "sipcore@ietf.org" <sipcore@ietf.org>, Peter Musgrave <peter.musgrave@magorcorp.com>
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
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, 22 Oct 2010 20:58:41 -0000

On Sep 28, 2010, at 9:29 AM, Hadriel Kaplan wrote:

>
> On Sep 27, 2010, at 7:14 PM, Peter Musgrave wrote:
>
>> Hi,
>>
>> I read the draft and I think the semantics are ok (although John's
>> point about multiple proxies with these tags is a good one).
>>
>> One use which occurred to me - but which is no doubt controversial  -
>> is whether a proxy/B2B which is an SBC could provide a feature tag
>> indicating it is an SBC - so that UAs which register and call through
>> it could skip adding ICE candidates. (My point is merely that I
>> suspect other uses for this capability will be found - even if you
>> think this  particular idea is mis-guided).
>>
>
> Right, that particular idea is mis-guided. :)
>
> What you'd really do for that is indicate whether or not the b2bua  
> supports ICE (since some SBC's do, and some don't, indicating you're  
> an SBC doesn't help).

Opposite: You want to know that the sbc masks (that is, breaks) ICE,  
so that (based on the presumption that if you don't have any  
information you should try ICE), you can choose not to ICE if you know  
it's going to fail.

Option-tag: icebreaker. Semantic: a node that supports this extension  
is going to piddle in your ICE. Send traffic at room-temperature  
instead of iceing it unless you like yellow drinks.

--
Dean