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

From: [email-masked]
Date: Tue, 12 Oct 2010 23:44:50 +0800

Hi Paul and Christer,

We now use this draft in our IMS(3GPP's SRVCC), currently in standard 
level.

So, we support this one.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2010-09-27 22:46

收件人
Christer Holmberg <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
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-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
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 13 Oct 2010 11:04:26 +0200

Actually 3GPP does not. It is under discussion, but no CR has yet been approved. That might well happen by December, but it has not yet.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 12, 2010 4:45 PM
To: Paul Kyzivat; Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

Hi Paul and Christer,

We now use this draft in our IMS(3GPP's SRVCC), currently in standard level.

So, we support this one.

Thanks,

Gao

2010-09-27 22:46

收件人
Christer Holmberg <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

[as chair]

                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-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

---

From: [email-masked]
Date: Wed, 13 Oct 2010 17:30:16 +0800

I just showed the vendor's viewpoint. 

It is better to replaces "our IMS(3GPP' SRVCC)" by "our IMS(SRVCC)". So, I 
means "We now use this draft in our IMS(SRVCC), currently in standard 
level." 

And what I means about "in standard level", is that ZTE's 3GPP people 
support this one now. And considering system level, we will support the 
final approved one.

Thanks,

Gao

"DRAGE, Keith (Keith)" <[email-masked]> 
2010-10-13 17:04

收件人
"[email-masked]" <[email-masked]>, Paul Kyzivat 
<[email-masked]>, Christer Holmberg <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: 
Feature-tags in the Path header field]

Actually 3GPP does not. It is under discussion, but no CR has yet been 
approved. That might well happen by December, but it has not yet.
 
Keith

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Tuesday, October 12, 2010 4:45 PM
To: Paul Kyzivat; Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature 
[was: Feature-tags in the Path header field]

Hi Paul and Christer, 

So, we support this one. 

Thanks, 

Gao 

收件人

[as chair]

                Thanks,
                Paul

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 15 Oct 2010 04:57:48 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Monday, September 27, 2010 9:47 AM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature
[was: Feature-tags in the Path header field]

[as chair]

	Thanks,
	Paul

> The draft can also be found at:
http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-feat
ure-00.txt

---------------------------------------------------------------------
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.

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 15 Oct 2010 08:59:58 -0500

Hadriel

And there I was thinking that SBCs were these amazingly flexible devices
that could remove, modify or add any SIP primitive to any message based
on the service providers desires - but now it turns out that in reality
that they can't even add a feature tag to a routing header!

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Tuesday, September 28, 2010 9:29 AM
To: Peter Musgrave
Cc: [email-masked]
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature
[was: Feature-tags in the Path header field]

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).  

There already is a feature tag for ICE ("sip.ice"), but such a thing
would break immediately - since ICE is a new thing, legacy SBC's
wouldn't know to say they don't do it, and there is no "!(feature-tag)"
anyway; and the UA doesn't know whether it's talking through SBC's or
plain proxies to begin with, and if they're plain proxies they wouldn't
say anything about ice ever... so the UA can never guess this right.  If
it gets back "sip.ice" then it knows for that one hop that said so it's
ok, but it knows nothing about the rest.  

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Oct 2010 15:53:51 -0500

On Sep 27, 2010, at 9:46 AM, Paul Kyzivat wrote:

> 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?
>

I think it's important to note that we're talking about a way of  
advertising "option tags" -- the same option tags that theoretically  
get added to the "Supported" headers in lots of messages, and that the  
"Options" request was particularly designed to collect.

Specifically, Christer has identified a use case where it is important  
for other nodes to understand the options supported by a proxy in the  
registration path, when that proxy is reasonably expected to be on the  
request path for future requests using that registration.

If, OTOH, we're really talking "feature tags" that refer to vendor- 
tree specific feature identification -- well, then we're back to the  
old service-identifier problem.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 Oct 2010 16:00:15 -0500

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

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Oct 2010 08:32:22 +0200

Hi,

>old service-identifier problem.

Actually, the draft DOES talk about feature tags.

And, yes, we could start to talk about service-ids again, but that is a much wider topic, and is related to the usage of feature tags in general.

UAs are already allowed to indicate capabilities using feature tags, and the draft allows intermediaries to do the same.

But, of course, if one *requires* someone else to support something, option-tags should be used, but insertion of option-tags by intermediaries is outside the scope of the draft.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 25 Oct 2010 17:21:27 -0500

> Actually, the draft DOES talk about feature tags.

So you mean "RFC 3840 media feature tags"?

In your model, do they indicate that a particular feature is supported  
by the node, or do they indicate that a particular feature is being  
enforced by the node? Or do they indicate a request for delivery of  
functionality by other nodes -- that is, do they inform other nodes so  
that routing decisions can be made?

The reason I ask is that I think we're talking about a family of  
"features" that are not really consistent with RFC 3840/41 media  
feature tags.

That said, I'm fairly convinced that the whole capability negotiation  
model(s) in SIP is(are) an () ugly hack(s).

--
Dean

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 09:41:52 +0200

Hi Christer,
Thank you for this draft. I think this delivers a useful mechanism for some of our use-cases in our network.
I'm also willing to participate in the work of the draft.

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Freitag, 24. September 2010 13:04
An: [email-masked]
Betreff: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Oct 2010 09:48:19 +0200

Hi Dean,

>>>Specifically, Christer has identified a use case where it is important for other nodes to understand the options supported by a proxy in the
>>>registration path, when that proxy is reasonably expected to be on the request path for future requests using that registration.
>>>
>>>If, OTOH, we're really talking "feature tags" that refer to vendor-tree specific feature identification -- well, then we're back to the

Correct.

>In your model, do they indicate that a particular feature is supported by the node, or do they indicate that a particular feature is being enforced by the node? 
>Or do they indicate a request for delivery of functionality by other nodes -- that is, do they inform other nodes so that routing decisions can be made?

Eventhough I guess one can make routing decissions based on whatever information, the basic purpose of a feature tag is NOT to indicate "routing policies" - it's to indicate that a particulare feature is suppored by the node that inserted the feature tag.

Regards,

Christer