Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

From: "Andrew Allen" <[email-masked]>
Date: Fri, 21 Jan 2011 16:25:26 -0600

I have reviewed this draft and basically I am supportive of the
objective of this work.

I think the current use cases are very specific and the problem itself
is even more general.

I think the general requirement is that it is useful for UAs and other
intermediaries to be able to detect the presence of an intermediary  on
the path of a registration or the route of a dialog when that
intermediary provides some feature or service and be able to identify
the URI of that intermediary in order to be able to address requests to
it . In addition to the 3GPP specific use cases currently in the draft I
think there are others including:

Dealing with call feature interactions

In a deployment where different intermediaries provide different call
features it is sometimes necessary to be able to detect that another
intermediary has invoked a particular feature as that may mean that a
particular feature should not be invoked or should be invoked in a way
that takes account of the invocation of the feature by the other
intermediary in order to prevent conflicts between different call
features.

Detecting the presence of a SIP PBX

SIP PBXs may be present in a network and may provide call features and
other services on behalf of the UA. In some cases the UA may need to
address requests to the PBX to invoke some features or services.
Although presence of the PBX could be indicated using configuration this
isn't really effective when there are mobile UAs moving between
enterprise networks that have PBXs and public networks that don't.  

Detecting the presence of a telephony application server.

In 3GPP IMS Multimedia Telephony Service (MMTel) there is a Telephony
Application Server (TAS) that provides call features on behalf of the
UA. However not all 3GPP networks will necessarily deploy MMTel so it is
necessary that a UA be able to identify that a TAS is involved in the
call and be able to send requests such as REFER to the TAS in order to
perform functions like call transfer. Having the TAS always act as a
full B2BUA and overwrite the Contact is not a good solution as this will
cause the loss of the GRUUs of the far end UAs.

In addition since the same intermediary may perform multiple features or
services it is useful for the URI that is provided to identify the
related call feature or service so that when the UA addresses a request
to the intermediary the intermediary knows what feature or service the
request is related to. 

Some detailed comments:

Section 6

   NOTE: If a route set is built using Path, Record-Route or Service-

   Route header fields, any inserted feature tag will be copied into the

   associated Route header fields, together with other header field

   parameters.  This specification does not define any specific meaning

   of the feature tags present in Route header fields in such cases. 

      I think the meaning of  the feature tag in the Route header is the
same it means that the entity whose URI is on the Route supports the
feature

Section 7

  I think the direction issue may need more work. It would I think be
useful to indicate the directionality.

 I believe that SIPCORE should adopt this and work on a solution.

Andrew

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
Sent: Tuesday, December 07, 2010 7:38 AM
To: [email-masked]
Subject: [sipcore] Draft new version:
draft-holmberg-sipcore-proxy-feature

Hi,

I've submitted a new version of the proxy-feature draft.

It now contains more use-cases, for which the usage of the draft have
been discussed in 3GPP.

In the examples there is also some wording about why the usage of the
Contact header field is not seen as appropriate.

I have added some text about the "direction" of capabilities.

Regards,

Christer

---------------------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jan 2011 20:00:45 -0500

(speaking as an individual)

Inline...

> think there are others including:

A major thing that is lacking here is any explanation of what it *means* 
for an intermediary to "offer a feature" - what sorts of features those 
are, and how one might avail oneself of them.

In the case of callerprefs/callee caps and currently defined, the 
intermediary is a proxy that does address translation based on a 
registrar. One knows that the way to avail themselves of the features is 
to send a request to an AOR with registrations and use callerprefs to 
request routing to a device with those features.

Or, one might learn about capabilities because they are returned 
attached to a contact in a dialog, and then one avails oneself of the 
capabilities by sending a subsequent request to that contact.

Now maybe this draft implies no more - that the capabilities are ones 
that I can get access to by sending a request to the address I find in 
the Route header. But of course its not normal to send a request with 
the R-URI being an address taken from a Route header.

I think this is the usual thing - there is a framework within which this 
makes sense, but its defined in IMS. And as usual, the inclination is to 
say: please say more than that you want this to use in some unspecified 
way with IMS.

	Thanks,
	Paul

> intermediary in order to prevent conflicts between different call features.

So in this case it is not about detecting *capabilities* that might be 
used, but rather about detecting behavior that is already being applied?

> address requests to the PBX to invoke some features or services.

This is more what I was getting at. But its not clear to me what the 
model is for "addressing requests to the PBX to invoke some features or 
services".

> isn’t really effective when there are mobile UAs moving between
> enterprise networks that have PBXs and public networks that don’t.
>

This begs some higher level model of the possible components in a system 
and their potential relationships to one another. I realize IMS has 
this, that doesn't help in defining this in the ietf context. We are 
starting to have such things in the work that was done in BLISS. But I 
don't know if that is similar. And of course a bunch of ietf folk 
believe that IMS has it all wrong.

> I think the meaning of the feature tag in the Route header is the same
> it means that the entity whose URI is on the Route supports the feature

Yes. Those other headers only exist to form Routes. I would think that 
it is presence on the Route that would matter, except in cases where 
presence on Record-Route leads something along the way to block the call.

> I believe that SIPCORE should adopt this and work on a solution.

I hear you. Lets see what others have to say.

	Thanks,
	Paul

> Andrew
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Christer Holmberg
> *Sent:* Tuesday, December 07, 2010 7:38 AM
> *To:* [email-masked]
> *Subject:* [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature
>
> Hi,
>
> 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.
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 22 Jan 2011 10:32:03 +0100

Hi Paul,

The idea is that each feature specification defines what indicating support of a feature means - in the same way it is done for UAs.

For example, just because a proxy indicate support of a feature, it doesn't automatically mean that others will address requests towards that proxy. It may for example mean that another entity, when it sees the feature tag, does not trigger some action.

I am sure there are things in the draft than can be clarified, including the 3GPP use-cases, but I think it would be useful to know (for me personally, and for 3GPP that wants to use the mechanism) whether the WG is willing to start this work. Nobody has objected to the work as such (you even say yourself that it might be useful :), and all questions and issues that have been raised will of course have to be solved (like we always do).

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Saturday, January 22, 2011 3:00 AM
To: [email-masked]
Subject: Re: [sipcore] Draft new        version:        draft-holmberg-sipcore-proxy-feature

Inline...

        Thanks,
        Paul

        Thanks,
        Paul

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 09:51:08 +0100

I support the work. From my side we can start the work on Christer's draft.

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Christer Holmberg
> Gesendet: Samstag, 22. Januar 2011 10:32
> An: Paul Kyzivat; [email-masked]
> Betreff: Re: [sipcore] Draft new version:
> The idea is that each feature specification defines what
> indicating support of a feature means - in the same way it is
> done for UAs.
>
> For example, just because a proxy indicate support of a
> feature, it doesn't automatically mean that others will
> address requests towards that proxy. It may for example mean
> that another entity, when it sees the feature tag, does not
> trigger some action.
>
> I am sure there are things in the draft than can be
> clarified, including the 3GPP use-cases, but I think it would
> be useful to know (for me personally, and for 3GPP that wants
> to use the mechanism) whether the WG is willing to start this
> work. Nobody has objected to the work as such (you even say
> yourself that it might be useful :), and all questions and
> issues that have been raised will of course have to be solved
> (like we always do).
>
> Regards,
>
> Christer
>
>
>
> From: [email-masked] [[email-masked]] On
> Behalf Of Paul Kyzivat [[email-masked]]

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 Jan 2011 16:32:50 +0100

Just picking on one particular example from Andrew's post: 

> SIP PBXs may be present in a network and may provide call 
> features and other services on behalf of the UA. In some 
> cases the UA may need to address requests to the PBX to 
> invoke some features or services. Although presence of the 
> PBX could be indicated using configuration this isn't really 
> effective when there are mobile UAs moving between enterprise 
> networks that have PBXs and public networks that don't.  
[JRE] Although we all perhaps have a similar notion of what a PBX is, this is not a tightly defined term in the SIP context (the nearest we have is the MARTINI notion of SIP-PBX in the context of bulk registration, but I suspect that is not what you have in mind). A PBX could do all sorts of things differently from some other SIP entity (such as a Service Provider SIP proxy), but particular behaviour is very much dependent on the design of a PBX and how it is deployed. If proxy features are indeed to be indicated (I have not yet formed an opinion on this), they should be more precisely defined, i.e., at the level of particular features that the PBX can perform, rather than just the fact it is a PBX.

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 Jan 2011 16:33:35 +0100

Well, if everyone says they won't perform a feature because somebody else is going to do it, that seems like a recipe for not having the feature performed at all. There would need to be some rules on which entity performs the feature and which entities do not perform the feature. I am not sure this was clear from the draft.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 22 January 2011 09:32
> To: Paul Kyzivat; [email-masked]
> features and

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jan 2011 16:42:47 +0100

Hi John, 

>Well, if everyone says they won't perform a feature because 
>somebody else is going to do it, that seems like a recipe for 
>not having the feature performed at all. There would need to 
>be some rules on which entity performs the feature and which 
>entities do not perform the feature.

Absolutely. The feature tag definition needs to contain/refer these kind of rules.

>I am not sure this was clear from the draft.

It is intended to be covered in section 6, but we for sure can add more text to make it clearer.

Regards,

Christer

> > The idea is that each feature specification defines what indicating 
> > support of a feature means - in the same way it is done for UAs.
> > 
> > For example, just because a proxy indicate support of a feature, it 
> > doesn't automatically mean that others will address 
> requests towards 
> > that proxy. It may for example mean that another entity, 
> when it sees 
> > the feature tag, does not trigger some action.
> > 
> > I am sure there are things in the draft than can be clarified, 
> > including the 3GPP use-cases, but I think it would be 
> useful to know 
> > (for me personally, and for 3GPP that wants to use the mechanism) 
> > whether the WG is willing to start this work. Nobody has 
> objected to 
> > the work as such (you even say yourself that it might be useful :), 
> > and all questions and issues that have been raised will of 
> course have 
> > to be solved (like we always do).
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > From: [email-masked] [[email-masked]] 
> On Behalf Of 
> > Paul Kyzivat [[email-masked]]
> > A major thing that is lacking here is any explanation of what it 
> > *means* for an intermediary to "offer a feature" - what sorts of 
> > features those are, and how one might avail oneself of them.
> > 
> > registrar. One knows that the way to avail themselves of 
> the features 
> > is to send a request to an AOR with registrations and use 
> callerprefs 
> > to request routing to a device with those features.
> > 
> > I think this is the usual thing - there is a framework within which 
> > this makes sense, but its defined in IMS. And as usual, the 
> > inclination is to
> > say: please say more than that you want this to use in some 
> > unspecified way with IMS.
> > 
> >         Thanks,
> >         Paul
> > 
> > model is for "addressing requests to the PBX to invoke some 
> features 
> > or services".
> > 
> > This begs some higher level model of the possible components in a 
> > system and their potential relationships to one another. I 
> realize IMS 
> > has this, that doesn't help in defining this in the ietf 
> context. We 
> > are starting to have such things in the work that was done 
> in BLISS. 
> > But I don't know if that is similar. And of course a bunch of ietf 
> > folk believe that IMS has it all wrong.
> >

---

From: "Andrew Allen" <[email-masked]>
Date: Mon, 24 Jan 2011 09:45:17 -0600

John

I agree the indication needs to identify the features supported not just the presence of an entity.

Andrew

----- Original Message -----
From: Elwell, John [mailto:[email-masked]]
Sent: Monday, January 24, 2011 09:32 AM
To: Andrew Allen; Christer Holmberg <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [sipcore] Draft new version:draft-holmberg-sipcore-proxy-feature

John

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jan 2011 09:29:40 -0600

[as an individual]

> I am sure there are things in the draft than can be clarified, including the 3GPP use-cases, but I think it would be useful to know (for me personally, and for 3GPP that wants to use the mechanism)…

I don't think it's completely accurate to say that no objections have 
been registered. Cullen's message on November 9th was a pretty clear 
objection. Others -- like Dale -- have expressed confusion about how 
this mechanism is supposed to be used (and whether we're really talking 
about proxies, B2BUAs, or something else entirely that lives outside of 
the valid behavior defined by SIP). Many of the other responses have 
been somewhat pro-forma "3GPP wants this, so let's do it" messages 
without any other content. I'm not discounting them as meaningless, but 
they don't get us any closer to understanding what you're trying to do 
or addressing the concerns that have been expressed.

So, I think we need to back up and get everyone on the same page. The 
use cases you've added to the document are a good start, but I note that 
the section headings all start with the same word.

I would suggest -- and I'm doing this as an individual, not as a chair 
-- that you produce a "draft-holmberg-sipcore-proxy-feature-reqs" 
document that:

   1. contains a concise description of the problem being solved;
   2. contains one or more general (non-IMS, applicable to the Internet)
      use cases;
   3. contains a list of requirements on the solution; and
   4. [this is the most important part] contains no protocol mechanism
      discussion at all.

I think RFC5947 is a good example of how such a document can look.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Jan 2011 17:33:45 +0100

Hi, 

>I am sure there are things in the draft than can be clarified, including the 3GPP use-cases, but I think it would be useful to know (for me personally, 
>and for 3GPP that wants to use the mechanism) whether the WG is willing to start this work. Nobody has objected to the work as such (you even say 
>yourself that it might be useful :), and all questions and issues that have been raised will of course have to be solved (like we always do).
>		
>
>I don't think it's completely accurate to say that no objections have been registered. Cullen's message on November 9th was a pretty clear objection.

I didn't read his message as an objection, but more as a question why we can't use a B2BUA instead. 

>Others -- like Dale -- have expressed confusion about how this mechanism is supposed to be used (and whether we're really talking about proxies, B2BUAs, 
>or something else entirely that lives outside of the valid behavior defined by SIP).

I tried to address Dale's issues in the latest version of the draft, but I may have missed something.

>Many of the other responses have been somewhat pro-forma "3GPP wants this, so let's do it" messages without any other content. I'm not discounting them 
>as meaningless, but they don't get us any closer to understanding what you're trying to do or addressing the concerns that have been expressed.
>	
>So, I think we need to back up and get everyone on the same page. The use cases you've added to the document are a good start, but I note that the 
>section headings all start with the same word.
>	
>I would suggest -- and I'm doing this as an individual, not as a chair -- that you produce a "draft-holmberg-sipcore-proxy-feature-reqs" document that:
>
>	2.	contains one or more general (non-IMS, applicable to the Internet) use cases; 
>
>	4.	[this is the most important part] contains no protocol mechanism discussion at all. 

I'll try to put something together.

But, just for my understanding: what happens if there are no non-IMS use cases?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jan 2011 13:24:21 -0600

[as individual]

> But, just for my understanding: what happens if there are no non-IMS use cases?

Then we need to try to figure out whether the inapplicability of the 
problem is due to the fact that it is being stated in overly-narrow 
terms (i.e., is there a more general problem here that does have 
applicability to the Internet?), or whether it is due to the fact that 
it only arises because of a specific architecture.

If it's the first case, we'll probably need to generalize the problem to 
include the Internet (you know, the "I" in "IETF"). Then, you'll have a 
much easier time getting the WG to adopt it and the IESG to approve it.

If the problem only exists because of certain walled-garden 
architectures, then things get trickier -- both in the WG and in the IESG.

/a

---

From: <[email-masked]>
Date: Wed, 26 Jan 2011 14:07:49 +0100

Hi,
there is an scenario which I would see also within the Internet approach. Perhaps others too.

When you register it would be useful to know if the proper emergency service is served by the provider you are connected to.
Such an explicit indication would help.

   Alice                             P1                     REGISTRAR
          |                           |                           |
          |--- REGISTER-------------->|                           |
          |                           |                           |
          |                           |--- REGISTER-------------->|
          |                           |    Path: P1;emergency     |
          |                           |                           |
          |                           |                           |
          |                           |<-- 200 OK ----------------|
          |                           |    Path: P1;emergency     |
          |                           |    Service-Route: REG     |
          |<-- 200 OK ----------------|                           |
          |    Path: P1;emergency     |                           |
          |    Service-Route: REG     |                           |
          |                           |                           |

So that Alice is now sure that an emergency call will get thought and the correct emergency centre will be reached. Which is not even guaranteed in an pure internet environment depended which service provider is chosen.

Best Regards

Roland

> [mailto:[email-masked]] Im Auftrag von Adam Roach
> Gesendet: Dienstag, 25. Januar 2011 20:24
> An: Christer Holmberg
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2011 12:34:40 -0500

inline

> So that Alice is now sure that an emergency call will get thought and the correct emergency centre will be reached. Which is not even guaranteed in an pure internet environment depended which servi…

Why is presence of this parameter on *Path* appropriate? Path has 
nothing to do with new calls originated by Alice. If anything were 
relevant, it would be Service-Route, which Alice would include in Route 
when making a new call.

And, what does the "emergency" capability *mean*? Does it mean that it 
can route requests with urn:sos as the R-URI? Or that it recognizes URIs 
containing dial strings that contain emergency numbers? Or what? (If the 
latter, emergency numbers for what locale(s)?, and encoded in what manner?)

But, why is this needed? Why not just send the request and cope with 
failure to route if/when it happens?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 14:55:25 +0100

Hi,

Eventhough I would be happy to see usage outside of IMS for the mechanism, I don't see why 3GPP people should have to try to invent such use-cases "by force". 

I think there could be usages for SIP-PBXs, but I don't have any specific requirement/use-case to put on the table.

Regarding the WG and IESG, we have specified mechanisms for 3GPP before, e.g based on RFC 4083, and my understanding is that there is some kind of agreement between 3GPP and IETF. I do realize that we are not talking about a P- header in this case, but that should not change the fundamental agreement.

But, if you now are saying that, unless there is a non-IMS use-case, IETF (or, at least SIPCORE) is no more going to accept doing any work for 3GPP, I really think 3GPP should be informed about that.

BTW, there is an *I* in IMS also :)

Regards,

Christer

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 25. tammikuuta 2011 21:24
> To: Christer Holmberg
> Cc: Paul Kyzivat; [email-masked]
> Then we need to try to figure out whether the inapplicability 
> of the problem is due to the fact that it is being stated in 
> overly-narrow terms (i.e., is there a more general problem 
> here that does have applicability to the Internet?), or 
> whether it is due to the fact that it only arises because of 
> a specific architecture.
> 
> If it's the first case, we'll probably need to generalize the 
> problem to include the Internet (you know, the "I" in 
> "IETF"). Then, you'll have a much easier time getting the WG 
> to adopt it and the IESG to approve it.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 09:08:28 -0500

Christer,

The reason for including something for non-IMS usage is to motivate 
those not involved in IMS to be interested in the work. I guess that a 
sufficient mass of IMS participants would work, but its harder to get 
consensus without some of the others.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 15:22:20 +0100

Hi, 

>The reason for including something for non-IMS usage is to motivate those not involved in IMS to be interested in the 
>work.

I understand that, and I encourage people to think of use-cases that could make the feature useful also outside IMS. Because, there is nothing IMS specific with the feature itself, eventhough the current use cases come from IMS.

But, I would be very surprised if the lack of non-IMS use-cases would become a show stopper.

>I guess that a sufficient mass of IMS participants would work, but its harder to get consensus without some of 
>the others.

Well, I think that a number of IMS participants, that also attend SIPCORE, have indicated support of the draft. I have also received comments on the draft itself from many of those, so there is interest in actually participating in the work.

Regards,

Christer

> > Eventhough I would be happy to see usage outside of IMS for 
> the mechanism, I don't see why 3GPP people should have to try 
> to invent such use-cases "by force".
> >
> > I think there could be usages for SIP-PBXs, but I don't 
> have any specific requirement/use-case to put on the table.
> >
> > Regarding the WG and IESG, we have specified mechanisms for 
> 3GPP before, e.g based on RFC 4083, and my understanding is 
> that there is some kind of agreement between 3GPP and IETF. I 
> do realize that we are not talking about a P- header in this 
> case, but that should not change the fundamental agreement.
> >
> > But, if you now are saying that, unless there is a non-IMS 
> use-case, IETF (or, at least SIPCORE) is no more going to 
> accept doing any work for 3GPP, I really think 3GPP should be 
> informed about that.
> >
> >> applicability to the Internet?), or whether it is due to the fact 
> >> that it only arises because of a specific architecture.
> >>
> >> If it's the first case, we'll probably need to generalize 
> the problem 
> >> to include the Internet (you know, the "I" in "IETF"). 
> Then, you'll 
> >> have a much easier time getting the WG to adopt it and the IESG to 
> >> approve it.
> >>
> >> architectures, then things get trickier -- both in the WG 
> and in the 
> >> IESG.
> >>
> >> /a
> >>
>

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 16:20:52 +0100

Hi Paul,
I tried to express a possible use case more in general.
So "emergency" means that the Call is passed through an Server that assures that a INVITE with a URI addressing a emergency number e.g. 110@domain or 999@domain or it could also use sos@domain will be handled correctly by the AS and will be forwarded to the next emergency centre.

My example was pointing to a use-case that could be happen within the internet, when service provider will support emergency. Und the user will be informed that he is sure that the emergency call will be passed through with the first INVITE. And not waiting for certain responses if the call will not succeed.

My intension was to try to point to possible internet applications that could use Christers draft.

Best Regards

Roland

> [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Mittwoch, 26. Januar 2011 18:35
> An: [email-masked]
> > When you register it would be useful to know if the proper
> emergency service is served by the provider you are connected to.
> >     Alice                             P1
>  REGISTRAR
> > So that Alice is now sure that an emergency call will get
> thought and the correct emergency centre will be reached.
> Which is not even guaranteed in an pure internet environment
> depended which service provider is chosen.
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Jan 2011 09:33:42 -0600

I think what Paul is saying is that the "emergency" capability would 
have to be in the service route, not the path -- since the Path has 
zero, zilch, nada, nothing to do with calls *made* by the handset.

For my own part, I have some serious concerns about this kind of 
example, as it relies on named services, not capabilities. I suggest you 
very carefully read sections 5 and 6 of RFC5897.

/a

---

From: "Andrew Allen" <[email-masked]>
Date: Thu, 27 Jan 2011 09:35:49 -0600

Paul,

I expressed already that I think that solving this problem is also
useful for non IMS environments such as IP PBXs in enterprises. More
generally it could be useful in an internet environment whenever a SIP
proxy wishes to advertise its support for some feature or capability.

I also would like to point out that some of the features developed in
SIP over the past decade that were initially seen as IMS only or IMS
requirements initiated features have later been seen to be useful to the
wider community and included as part of the solutions for other later
SIP work and made it into the Hitchikers guide. Some examples include:

P-Asserted-Identity header field,
UPDATE method,
Path header field,
Registration Events Package

I also would like to indicate that I am willing to contribute and review
this work if it is adopted.

Andrew 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Thursday, January 27, 2011 8:08 AM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] Draft new
version:draft-holmberg-sipcore-proxy-feature

Christer,

	Thanks,
	Paul

On 1/27/2011 8:55 AM, Christer Holmberg wrote:
>
> Hi,
>
> Eventhough I would be happy to see usage outside of IMS for the
mechanism, I don't see why 3GPP people should have to try to invent such
use-cases "by force".
>
> I think there could be usages for SIP-PBXs, but I don't have any
specific requirement/use-case to put on the table.
>
> Regarding the WG and IESG, we have specified mechanisms for 3GPP
before, e.g based on RFC 4083, and my understanding is that there is
some kind of agreement between 3GPP and IETF. I do realize that we are
not talking about a P- header in this case, but that should not change
the fundamental agreement.
>
> But, if you now are saying that, unless there is a non-IMS use-case,
IETF (or, at least SIPCORE) is no more going to accept doing any work
for 3GPP, I really think 3GPP should be informed about that.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 17:00:58 +0100

Hi, 

>I think what Paul is saying is that the "emergency" 
>capability would have to be in the service route, not the 
>path -- since the Path has zero, zilch, nada, nothing to do 
>with calls *made* by the handset.

According to RFC 5626, a UAC can use the "ob" parameter - present in the Path header field - at least to determine whether to send keep-alives.

But, in networks that support emergency calls, and the feature tag, the registrar can also use the Path to generate the Service-Route (which means the feature tag will be inserted in the Service-Route).

>For my own part, I have some serious concerns about this kind 
>of example, as it relies on named services, not capabilities. 
>I suggest you very carefully read sections 5 and 6 of RFC5897.

You asked for non-IMS use-cases, and you got a proposal. I think we could do some brainstorming around it, and see whether it could result in something useful.

Regards,

Christer

> > So "emergency" means that the Call is passed through an 
> Server that assures that a INVITE with a URI addressing a 
> emergency number e.g. 110@domain or 999@domain or it could 
> also use sos@domain will be handled correctly by the AS and 
> will be forwarded to the next emergency centre.
> >
> > My example was pointing to a use-case that could be happen 
> within the internet, when service provider will support 
> emergency. Und the user will be informed that he is sure that 
> the emergency call will be passed through with the first 
> INVITE. And not waiting for certain responses if the call 
> will not succeed.
> >
> > My intension was to try to point to possible internet 
> applications that could use Christers draft.
> >
> > Best Regards
> >
> > Roland
> >
> >>>             |                           |                 
>           |
> >>>             |                           |                 
>           |
> >>>             |                           |    Path: 
> P1;emergency     |
> >>>             |                           |                 
>           |
> >>>             |                           |                 
>           |
> >>>             |                           |    Path: 
> P1;emergency     |
> >>>             |                           |    
> Service-Route: REG     |
> >>>             |    Path: P1;emergency     |                 
>           |
> >>>             |    Service-Route: REG     |                 
>           |
> >>>             |                           |                 
>           |
> >> Which is not even guaranteed in an pure internet 
> environment depended 
> >> which service provider is chosen.
> >>
> >> relevant, it would be Service-Route, which Alice would include in 
> >> Route when making a new call.
> >>
> >> And, what does the "emergency" capability *mean*? Does it 
> mean that 
> >> it can route requests with urn:sos as the R-URI? Or that it 
> >> recognizes URIs containing dial strings that contain emergency 
> >> numbers? Or what? (If the latter, emergency numbers for what 
> >> locale(s)?, and encoded in what manner?)
> >>

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Jan 2011 10:02:27 -0600

[as an individual]

> But, if you now are saying that, unless there is a non-IMS use-case, IETF (or, at least SIPCORE) is no more going to accept doing any work for 3GPP, I really think 3GPP should be informed about tha…

Heh. If I were to make that kind of statement, it would be as a chair, 
and in coordination with the area directors. But that's not what I said, 
or meant to imply. I said things would "get trickier," meaning you'll 
face opposition from the members of the working group that hold 
generality as a key SIP attribute.

I'm pointing out, just as a participant, that you will have a harder 
time drumming up interest for a niche mechanism than you will for a 
general one.

Another hurdle you're going to face is harmonizing your proposal with 
RFC 5897. All three of your examples rely on doing, just about as 
vigorously as possible, precisely what RFC 5897 says not to do.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 17:07:48 +0100

Hi,

One general use-case that I have been thinking about is a feature tag indicating 
forking capability.

Now, such indicator as such might not be very useful, but the feature 
tag could also have values indicating what kind of forking has taken 
place. I think that could be useful information in issues related to 
forking, e.g. decissions regarding early media etc.

For example:

Record-Route: sip:myProxy.com;forking-para=4 

(4 here indicates how many parallel forks have been created)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 11:14:35 -0500

inline replies to both Adam and Roland

> zero, zilch, nada, nothing to do with calls *made* by the handset.

Yep. This is a key reason for the importance of use cases. Without this 
case, would we have had a hint that these features should go into 
Service-Route?

Worse, would we be having UAs checking Record-Route in order to make 
decisions about what will happen when the UA originates requests?

> very carefully read sections 5 and 6 of RFC5897.

+1

>> So "emergency" means that the Call is passed through an Server that
>> assures that a INVITE with a URI addressing a emergency number e.g.
>> 110@domain or 999@domain or it could also use sos@domain will be
>> handled correctly by the AS and will be forwarded to the next
>> emergency centre.

This is where it gets dicy. How would the UAC know that something 
advertising support for "emergency" was compatible with the UAC?

For instance, does the UAC encode a dial string like "110" into a URI in 
a way that the "emergency" service will recognize as a dial string, and 
will the emergency service recognize the emergency dial strings that the 
user of the device is likely to use?

One answer to that is that it isn't "emergency" that is reported as a 
capability, its "IMS-Vx.y-emergency", and there is an external spec 
somewhere that spells out in detail what behavior that implies.

But that presents a very difficult model for interoperation.

>> My example was pointing to a use-case that could be happen within the
>> internet, when service provider will support emergency. Und the user
>> will be informed that he is sure that the emergency call will be
>> passed through with the first INVITE. And not waiting for certain
>> responses if the call will not succeed.

We have a solution for emergency calls - its the sos urn. And IIRC there 
has been some discussion of ways that a UAC could "test the path" to 
that URN when it connects to a network so it could inform the user if 
that will work or not.

I'm pretty sure ecrit would have something to say about this example.

>> that could use Christers draft.

Thank you for trying. So far what it has done is act as a counter example.

	Thanks,
	Paul

>>> mean that it

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 17:15:23 +0100

Hi, 

>I'm pointing out, just as a participant, that you will have a 
>harder time drumming up interest for a niche mechanism than 
>you will for a general one.

I think a number of people have already shown interest for this.

>Another hurdle you're going to face is harmonizing your 
>proposal with RFC 5897. All three of your examples rely on 
>doing, just about as vigorously as possible, precisely what 
>RFC 5897 says not to do.

Feature tags indicate support of a capability. EVERY feature tag does that - even if inserted in a Contact header field by a UA - and the feature tag specification needs to define the meaning of that capability.

The important thing is that it cannot be assumed that other entities understand the meaning of the feature tag in order to progress a call (in such cases you will also need an option-tag, inserted in a Require/Proxy-Require header field).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 17:32:16 +0100

>>capability would have to be in the service route, not the path -- since the Path has 
>Yep. This is a key reason for the importance of use cases. 
>Without this case, would we have had a hint that these 
>features should go into Service-Route?
> 
>Worse, would we be having UAs checking Record-Route in order 
>to make decisions about what will happen when the UA 
>originates requests?
> 
>>example, as it relies on named services, not capabilities. 

I am not sure what the difference between a feature and a service is...

For example, RFC 5897 seems to call things like call forwarding and call screening as features, while I am sure others would call them services. 

I also see the IMS use-cases in the draft as features provided in IMS networks. Being able to handle emergency calls could also be seen as a feature. 

So, I think it would be a waste of time to argue about whether something is a service or a feature.

Again, the important thing, which I think was also raised many times during the good old days of service-id discussions, is that indicating support of a capability is just that - indicating support of a capability. Others may choose to enable that capability, or they may not. But, in order to execute the capability, one must of course implement the associated feature specification (whether it's an RFC or some other specification).

Regards,

Christer

> Server that 
> This is where it gets dicy. How would the UAC know that 
> something advertising support for "emergency" was compatible 
> with the UAC?
> 
> For instance, does the UAC encode a dial string like "110" 
> into a URI in a way that the "emergency" service will 
> recognize as a dial string, and will the emergency service 
> recognize the emergency dial strings that the user of the 
> device is likely to use?
> 
> One answer to that is that it isn't "emergency" that is 
> reported as a capability, its "IMS-Vx.y-emergency", and there 
> is an external spec somewhere that spells out in detail what 
> behavior that implies.
> 
> within the 
> We have a solution for emergency calls - its the sos urn. And 
> IIRC there has been some discussion of ways that a UAC could 
> "test the path" to that URN when it connects to a network so 
> it could inform the user if that will work or not.
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Jan 2011 10:42:26 -0600

> I am not sure what the difference between a feature and a service is...

Then it's a good thing RFC 5897 provides guidance on that front:

   "The best way to avoid this problem is to use feature tags that can be
    matched to well-defined signaling features -- media types, required
    SIP extensions, and so on.  In particular, the golden rule is that
    the granularity of feature tags must be equivalent to the granularity
    of individual features that can be signaled in SIP."

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 18:06:48 +0100

Hi, 

>"The best way to avoid this problem is to use feature tags 
>that can be matched to well-defined signaling features -- media 
>types, required SIP extensions, and so on.  In particular, 
>the golden rule is that the granularity of feature tags must be 
>equivalent to the granularity of individual features that can be 
>signaled in SIP."

I am not sure how much the text really clarifies.

But, assuming it does, it probably works for pure SIP features, associated with a single dialog. For example, I think the forking capability indicator I suggested fits fine into that.

But, the features in the draft are more complex than that, and may include multiple dialogs etc.

Having said that, if you think there is a better way of solving the use-cases in the draft, I am willing to hear about it.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Jan 2011 11:09:30 -0600

[as an individual]

On 1/27/11 11:06 AM, Christer Holmberg wrote:
> Having said that, if you think there is a better way of solving the 
> use-cases in the draft, I am willing to hear about it.

Splendid. What are your requirements? Answer in internet-draft form, please.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 18:13:25 +0100

Hi, 

>Splendid. What are your requirements? Answer in internet-draft form, please.

I already indicated that I will do that.

What I am trying to figure out, based on the feedback I have got from you and Paul, is whether writing such a draft would be a waste of time, unless I can come up with non-IMS use-cases.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 12:15:52 -0500

> The important thing is that it cannot be assumed that other entities understand the meaning of the feature tag in order to progress a call (in such cases you will also need an option-tag, inserted…

There was also an extended discussion (battle?), around the time the 
callerprefs came out, about the validity of using feature-tags 
(capabilities) to identify arbitrary *services* where the service was to 
be defined in some external, potentially restricted document.

The crux of the argument was whether capabilities were orthogonal to one 
another or not. The concern was (and remains) that interoperability is 
severely limited if there are potentially many ways of specifying the 
same capability, as part of this service or that service.

(IIRC, one of the examples used was video calling, where somebody might 
describe a capability "video-phone" that implies a particular 
combination of audio and video. Two UAs that supported this might work 
well together, but somebody with a UA that supports exactly the same 
media types and *could* interoperate if connected, might fail to 
interoperate for lack of specifying the proper feature-tag.)

We run a risk of going through the same thing here. That is what 5897 
was about too.

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Thu, 27 Jan 2011 12:20:20 -0500

Adam,

Could you please consult with the AD and chairs on Christer's question?
It would be useful for 3GPP to understand the working relationship.

Regards,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
Sent: Thursday, January 27, 2011 11:02 AM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [sipcore] Draft new
version:draft-holmberg-sipcore-proxy-feature

[as an individual]

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 12:24:07 -0500

> So, I think it would be a waste of time to argue about whether something is a service or a feature.

IMO the key differences are:

- the definition must be publicly available
- capabilities/feature-tags should be orthogonal

(And of course it is impossible to verify orthogonality without the 
definitions being available.)

My gut feeling is that most "services" are an assemblage of a number of 
capabilities.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 18:26:39 +0100

Hi, 

>(And of course it is impossible to verify orthogonality 
>without the definitions being available.)

As far as I know, all 3GPP specifications are publicly available.

Regards,

Christer

> 
> > Again, the important thing, which I think was also raised 
> many times during the good old days of service-id 
> discussions, is that indicating support of a capability is 
> just that - indicating support of a capability. Others may 
> choose to enable that capability, or they may not. But, in 
> order to execute the capability, one must of course implement 
> the associated feature specification (whether it's an RFC or 
> some other specification).
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >
> >>
> >>> /a
> >>>
> recognize as a 
> >> dial string, and will the emergency service recognize the 
> emergency 
> >> dial strings that the user of the device is likely to use?
> >>
> reported as a 
> >> We have a solution for emergency calls - its the sos urn. And IIRC 
> >> there has been some discussion of ways that a UAC could "test the 
> >> path" to that URN when it connects to a network so it could inform 
> >> the user if that will work or not.
> >>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 18:40:13 +0100

Hi, 

>>>proposal with RFC 5897. All three of your examples rely on doing, just about as 
>>Feature tags indicate support of a capability. EVERY 
>>feature tag does that - even if inserted in a Contact header 
>>field by a UA - and the feature tag specification needs to 
>>define the meaning of that capability.
>>
>>The important thing is that it cannot be assumed that other 
>>entities understand the meaning of the feature tag in order 
>>to progress a call (in such cases you will also need an 
>>option-tag, inserted in a Require/Proxy-Require header field).
>> 
>>There was also an extended discussion (battle?), around the 
>>time the callerprefs came out, about the validity of using 
>>feature-tags (capabilities) to identify arbitrary *services* where the 
>>service was to be defined in some external, potentially 
>>restricted document.

3GPP specifications are as external as IETF RFCs.

It is also important to remember that the proposed work is not about specifying specific feature tags, but a generic mechanism to carry proxy-inserted feature tags. 

I have no problem to include a statement saying that feature tags specifications that use the mechanism MUST be publicly available.

>The crux of the argument was whether capabilities were 
>orthogonal to one another or not. The concern was (and 
>remains) that interoperability is severely limited if there 
>are potentially many ways of specifying the same capability, 
>as part of this service or that service.

Yes, but that relates to most things we do.

>(IIRC, one of the examples used was video calling, where 
>somebody might describe a capability "video-phone" that 
>implies a particular combination of audio and video. Two UAs 
>that supported this might work well together, but somebody 
>with a UA that supports exactly the same media types and 
>*could* interoperate if connected, might fail to interoperate 
>for lack of specifying the proper feature-tag.)
> 
>We run a risk of going through the same thing here. That is 
>what 5897 was about too.

The procedures associated with the 3GPP feature tags are very well documented, rather than being something general as "audio" and "video".

And, take sip.instance as an example. It is useless unless entities support procedures associated with it. But, if UA_A inserts sip.instance, and UE_B does not support it, they will still be able to communicate. But, if they want to use features associated with the feature tag, they need to support the procedures defined for that feature. There is nothing in the "SIP signalling" that tells the entities what to do, if the sip.instance e.g. is going to be used outside the dialog (e.g in a REFER request).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 12:57:32 -0500

> As far as I know, all 3GPP specifications are publicly available.

I wasn't trying to imply that they are not, just putting a stake in the 
ground generally.

The orthogonality also ties into the quote Adam cited. I had forgotten 
exactly how that was stated. It goes further.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 13:15:48 -0500

> proxy wishes to advertise its support for some feature or capability.

I still think there *might* be something of general interest and value 
here.

When I look at it as an abstraction, it seems like a plausible one, and 
I like going for general capabilities rather than very specialized ones.

BUT, we have often gotten ourselves caught up in problems from 
over-generality. It is really good to have some important use cases. And 
having ones that many people can relate to is especially helpful.

I have a suspicion that there are use cases that much of the community 
can understand and relate to. They just haven't been discovered yet.

> Registration Events Package

I'm not sure that UPDATE is really form IMS. (It was called something 
else before UPDATE, but that is *way* back.) And IIRC the registration 
event package had broader support than IMS right from the beginning. But 
I take your point.

> this work if it is adopted.

Thanks for that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 19:27:46 +0100

Hi,

In my opinion the big difference (a little simplified) from when we had the service-id discussion is the following:

- The service-id is used by the sender to REQUEST the receiver to do something. If the receiver doesn't do it (e.g. because it doesn't understand the service-id) the sender might not get the assumed result in the particular dialog.

- The feature tag is used by the sender to INFORM the receiver about a feature that it supports. It's up to the receiver to determine whether it wants to use that information for anything. And, if it doesn't (or, it doesn't even understand the meaning of the feature tag), nothing will go wrong in the particular dialog, because the sender didn't assume the receiver to do anything.

sip.instance is a very good example of informing. The sender doesn't really expect the receiver to do anything with the information (unless there is an associated option-tag), but the receiver MAY use it e.g. to later do a call transfer.
 
So, in my opinion, THAT is the separation we need to do, rather than arguing about terminology. 

(We know that people have changed "service" to "feature" in their drafts simply because of "political reasons", so I think it's really worthless trying to categorize)

Regards,

Christer

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Thursday, January 27, 2011 7:57 PM
To: Christer Holmberg
Cc: Adam Roach; [email-masked]; [email-masked]
Subject: Re: [sipcore]  Draft   new     version:        draft-holmberg-sipcore-proxy-feature

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 13:51:20 -0500

> It is also important to remember that the proposed work is not about specifying specific feature tags, but a generic mechanism to carry proxy-inserted feature tags.

What I'm still missing is a generic definition of what it means for an 
intermediary in sip signaling (especially a proxy) to have capabilities.

With 3840/3841 I have a general understanding that:
- I can use callerprefs to suggest policies for getting my request
   to a UAS that has the stated capabilities
- that I can use fairly obvious sip signaling to make use of the
   capabilities. (E.g. if the video feature tag is present then I can
   expect that video lines in my offers will at least be understood.)

I'm not getting that level of understanding with this proposal yet. What 
I understand is that a server wanting to announce a capability is 
expected to put the feature tag on its record-route entry. I don't know 
if that is intended to convey information to the UAC or the UAS, or to 
other intermediaries on one side or the other (or both) in the 
transaction? And are these intended to apply for the dialog being 
established, or more broadly? (R-R only applies to the dialog.)

Nor do I understand *how* such features would be invoked? Again, is this 
*within* the dialog? Or is this through a new dialog or a transaction 
outside a dialog?

For instance, I suppose that if the feature were attached to an entry in 
a Service-Route header, then it would be copied into a Route header for 
requests outside an existing dialog, and them *maybe* the UAC could 
infer that something specific might happen to those requests. But that 
is strange to me - I expect that Route headers are used to steer a 
request through a sequence of proxies before getting to a particular 
destination. But I don't expect those proxies to do anything except 
ensure that the request actually reaches the R-URI and then works in 
accord with the request I sent for the UAS.

If the feature was attached to an entry in a Path header, then the same 
considerations might apply but from the perspective of the "proxy" 
associated with the registrar. These would become Route headers on 
requests outbound from it.

While there are certainly feature-specific things to be said, the 
general model of what is going on is still not clear to me.

> Yes, but that relates to most things we do.

And its something we must constantly be mindful of.

> And, take sip.instance as an example. It is useless unless entities support procedures associated with it. But, if UA_A inserts sip.instance, and UE_B does not support it, they will still be able t…

sip.instance may have been a mistake. It makes sense as a Contact header 
parameter, but whether it is truly a capability/feature is a bit shaky. 
Even so, its not an "outbound" feature, and its inclusion does not mean 
that you want outbound functionality. It merely says "this is who I am" 
and thus can be used for many things.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 23:22:46 +0100

Hi,

>  expect that video lines in my offers will at least be understood.)

That might have been the use-cases we were aware of when writing 3840/3841, but there is nothing in the general feature tag defintion that makes that limitation.

>established, or more broadly? (R-R only applies to the dialog.)

On a high level, it's about indicating support of a capability to other entities.

But, as the draft also says, each feature specification has to define the usage of the feature tag, and what indicating support of the capability really means - in the same way when a UA indicates support of a capability (except for the purpose of making forking decissions, when nobody really needs to know the semantics of the feature tag).

It is also true that R-R only applies to the dialog, but I don't think it's explicitly forbidden to use information received from a dialog in other dialogs. 

But, the scope of a feature tag needs to be described in the feature tag definition.

>*within* the dialog? Or is this through a new dialog or a transaction

Again, that needs to be described in the feature tag definition.

>accord with the request I sent for the UAS.

You need to define in which header fields the feature tag has a meaning, and what that meaning is.

>requests outbound from it.

Yes, and you would need to define that the feature tag only has meaning when present in a Path header field.

Take the "ob" parameter as an example. It's inserted in the Path header field. It may therefore be copied into the Route header fields, but it doesn't (AFAIR) really have any meaning there.

Take the Contact header field as an example. When you register the UA with the registrar, you may include features tags indicating capabilities that your support. The registrar will them insert them into the R-URI of an incoming INVITE, but they don't really have any meaning there. There are only there because the registrar copies the Contact into the R-URI. And, they are going to be there during the whole dialog, eventhough they won't be used for anything.

It's part of the SIP design that sometimes we copy paste things from one header field to another, eventhough all information as such might not be needed. We need to define what meaning, if any, the information has in specific header fields and situations.

>While there are certainly feature-specific things to be said, the general model of what is going on is still not clear to me.

The general model is pretty much the same as for UAs - indicating support of a capability - eventhough I agree that you need to consider more things (e.g. the meaning in different header fields) when defining the usage by a proxy. I try to explain that in the draft.

>And its something we must constantly be mindful of.

And that's why we have different review procedures etc to handle that. 3GPP is also looking for existing mechanisms first.

>> And, take sip.instance as an example. It is useless unless entities support procedures associated with it. But, if UA_A inserts sip.instance, and UE_B does not support it, they will still be able to 
>>communicate. But, if they want to use features associated with the feature tag, they need to support the procedures defined for that feature. There is nothing in the "SIP signalling" that tells the entities what 
>>to do, if the sip.instance e.g. is going to be used outside the dialog (e.g in a REFER request).
>

I agree. It doesn't really indicate support of a feature, unless you would define it as "the capability to be globally reachable".

BUT, it's still one of the most used feature tags in SIP :)

>and thus can be used for many things.

Exactly.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 28 Jan 2011 18:26:45 +0100

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 27 January 2011 15:21
> To: [email-masked]; [email-masked]
[JRE] This doesn't make sense to me. How can a single feature tag indicating support for emergency tell me how to code the URI (with 110@domain or 999@domain or sos@domain, etc.)?

John

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Jan 2011 13:39:40 +0200

Christer,

the challenge is to figure out whether there are more generic usage 
patterns that can be identified. The idea of developing these more 
generic features is that you could re-use them in different usage 
environments. Standardizing point-solutions is quite expensive and the 
results often do not see deployment.

Specifically, there is the question about how much standardization is 
necessary to get the basic level of interoperability to let those 
players in the application eco-system extend their software in a way 
that it works with others. In general, it is fair to say that 
standardizing each application has not been very successful.

Does that make sense?

Ciao
Hannes

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Jan 2011 13:42:03 +0100

Hi, 

>the challenge is to figure out whether there are more generic usage patterns that can be identified. The idea of developing these more generic features is that you could re-use them in different usage 
>environments. Standardizing point-solutions is quite expensive and the results often do not see deployment.

Use-cases don't come up just like that. They might come later, or the might never come. Curently 3GPP has identified a number of use-case, and for that a solution is needed.

>Specifically, there is the question about how much standardization is necessary to get the basic level of interoperability to let those players in the application eco-system extend their software in a 
>way that it works with others. In general, it is fair to say that standardizing each application has not been very successful.
>
>Does that make sense?

Not really. I am not asking IETF to standardize an application, only a generic indication mechanism.

OR, are you saying that 3GPP should just go ahead and do this, without any IETF standardization (after all, there are no backward compability issues, as the feature tags will simply be seen as unsupported parameters by entities not supporting them).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 Jan 2011 11:40:59 +0100

Hi, 

>[JRE] This doesn't make sense to me. How can a single feature tag indicating support for emergency tell me how to code the URI (with 110@domain or 999@domain or sos@domain, etc.)?

Feature tags can have values, which could be used to indicate that. For example: emergency="999@domain".

However, I am not sure that the use-case was about informing what the emergency number is, but to indicate that the proxy can handle emergency calls - whatever the URI to indicate emergency calls within that network is.

Regards,

Christer

> > And, what does the "emergency" capability *mean*? Does it mean that

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 31 Jan 2011 15:15:19 +0100

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 31 January 2011 10:41
> To: Elwell, John; [email-masked]; [email-masked]; 
> [email-masked]
> >[JRE] This doesn't make sense to me. How can a single 
> feature tag indicating support for emergency tell me how to 
> code the URI (with 110@domain or 999@domain or sos@domain, etc.)?
> 
> Feature tags can have values, which could be used to indicate 
> that. For example: emergency="999@domain".
> 
> However, I am not sure that the use-case was about informing 
> what the emergency number is, but to indicate that the proxy 
> can handle emergency calls - whatever the URI to indicate 
> emergency calls within that network is.
[JRE] I too am not sure we should bend the feature tag mechanism to use it for informing a UA what dial string to use. I guess the point behind my comment was why are we talking about dial strings here, why not the SOS URN? Also, are we talking about the case where the UA has identified a call as an emergency call but has not resolved the SOS URN (by doing a LOST look-up and populating the Route header field)? Or the case where the UA does not have access to location information? If the UA has performed all these functions, I don't see what special support is needed from the proxy. In other words, to understand Roland's use case, I really need more information about what function the proxy is expected to perform and how the UA knows that it needs the proxy to do this.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2011 09:31:26 -0500

We are well into speculation for this hypothetical (I think) emergency 
service. I've changed the title to protect the innocent.

To summarize a bit, I guess you are saying:

- a proxy that somehow got brought in while an initial REGISTER message 
was being processed could mark the Path header indicating that it 
supports this "emergency" service.

- the registrar might then take the information from that Path header to 
construct a Service-Route header for the UAC. This could still contain 
that indication of support for the "emergency" service.

- the UAC, upon receiving the response to REGISTER, with a 
Service-Route, *could* analyze the Service-Route for service 
"advertisements", for services such as this emergency service.

- The UAC would then have to analyze those service advertisements for 
ones that are applicable to it.

- in the case of emergency services, the UAC might have to use the value 
of the emergency feature tag to decideeee one or more of the following:
   * this service treats calls addressed to 999@domain as emergencies.
     I had better encode my emergency calls that way. (Even if my user
     usually types 911 for an emergency.)

   * this service treats calls addressed to 999@domain as emergencies.
     My user usually types 911 for emergency, so this service does me
     no good. I should find another way to handle my emergency calls.

   * this service treats calls addressed to 999@domain as emergencies.
     999 is not an emergency number for my user. In fact it is a valid
     non-emergency number. So I had better encode calls to 999 using
     something other that sip:999@domain.

Note, I don't think we want to debate which of these is the "right" 
answer - we are way too far into the hypothetical.

A more interesting thing to take from this is that its about "service 
discovery". That's especially true when used with REGISTER and 
Service-Route. But I think it may also be true with Record-Route for 
dialog establishment - to the extent that there is such a thing as 
services within a dialog. (And I think we do have examples of such things.)

Then draft-holmberg-sipcore-proxy-feature can be seen as a proposed 
mechanism in support of service discovery. As usual, I think we would be 
better off backing up and defining *requirements* for service discovery 
in sip. Certainly there exist service discovery mechanisms for other 
environments. I can see how one might like to query for available 
Music-on-Hold services, conference mixers, etc. (AFAIK this is typically 
done via configuration or proprietary mechanisms right now.)

While I want to discuss it further, I think I could get on board to an 
activity to define how to query for SIP URIs that one could send 
requests to in order to get specific kinds of behavior. This is at a 
higher level than "supports audio", "supports video" kinds of things. 
Its more about "once connected, what's in the audio and video?" E.g. "a 
music-on-hold server near me that plays pop oldies and supports wideband 
audio".

	Thanks,
	Paul