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

The general problem stated in this draft of the need to identify in the
various SIP routing headers the presence of an intermediary that can
perform particular features for the UA is I believe a problem worth
working on.

In SIP networks intermediaries (such as IP-PBXs and Application Servers)
sometimes act as proxies but also as UAs (or B2BUAs). In order to
initiate features provided by these intermediaries a UA may need to send
them SIP requests. However in order to act as a proxy and provide
transparency of the Contact header the intermediary should be passing
the Contact header transparently. 

However this presents the problem that a UA may need to send this
intermediary a SIP request (such as a REFER) but does not have a contact
address of the intermediary to include in the Request-URI. If the
intermediary can provide an indicator in a Record-Route header then this
could enable the UA to identify the presence of the intermediary and the
features supported by it and obtain from the Record-Route header the URI
to address requests that are needed to be sent to that intermediary in
order to initiate the features supported by the intermediary.

I would like to see a generic solution for this. The details of the
technical solution is a matter for the usual debate and discussion but I
think the draft is a good starting point for initiating this discussion.

Andrew

-----Original Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
Behalf Of Paul Kyzivat
Sent: Monday, September 27, 2010 9:47 AM
To: Christer Holmberg
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature
[was: Feature-tags in the Path header field]

[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

On 9/24/2010 7: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-feat
ure-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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.