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

"Worley, Dale R (Dale)" <> Wed, 10 November 2010 09:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F4C73A6A95 for <>; Wed, 10 Nov 2010 01:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.334
X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5pd9eIgobKDb for <>; Wed, 10 Nov 2010 01:32:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CC69B3A6A89 for <>; Wed, 10 Nov 2010 01:32:02 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANf12UyHCzI1/2dsb2JhbACiNHGicwKZA4VKBIRaiSI
X-IronPort-AV: E=Sophos;i="4.59,177,1288584000"; d="scan'208";a="44856449"
Received: from unknown (HELO ([]) by with ESMTP; 10 Nov 2010 04:32:05 -0500
X-IronPort-AV: E=Sophos;i="4.59,177,1288584000"; d="scan'208";a="536248751"
Received: from (HELO ([]) by with ESMTP; 10 Nov 2010 04:31:30 -0500
Received: from ([]) by ([::1]) with mapi; Wed, 10 Nov 2010 04:31:29 -0500
From: "Worley, Dale R (Dale)" <>
To: Cullen Jennings <>, "" <>
Date: Wed, 10 Nov 2010 04:27:00 -0500
Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported
Thread-Index: AcuATo5opL7VcYtzQX+LAIL4E9EdAgAat9Au
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
Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported
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: Wed, 10 Nov 2010 09:32:19 -0000

From: [] On Behalf Of Cullen Jennings []

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.

The use cases seem to revolve around the dialog passing through a chain of quasi-proxies, where one quasi-proxy needs to know if it should perform a particular function, or if it can delegate performing the function to a downstream quasi-proxy.  (A quasi-proxy is an element that generally acts like a proxy, but at times performs actions that a proxy is forbidden to perform.)

The "feature tags" seem to be envisioned to be from the same namespace as caller-preference feature tags, but to describe entirely independent features.  So it's not entirely clear why that particular namespace is chosen as the features aren't intended to be UA features.

I think Cullen's suggestion is a good one.  If quasi-proxy C implements a feature, it can insert "Supported: feature-foo" into the response to an INVITE.  Then quasi-proxy B can see that it can delegate feature-foo actions downstream.  B doesn't need to know *which* downstream quasi-proxy will implement the feature.