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

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Nov 2010 13:42:02 -0700

So, in my week of agreeing with Hadriel, I think he got it exactly right when he said there is pretty much no feature a "plain" proxy would need for this. If we are talking about things that would be a strict technical read be considered B2BUA even if they are implemented a lot like a proxy, then I can why something provided something like this functionality would be needed. 

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. 

If the real uses cases have to do with caller pref features, then B can modify those in the same way. 

Anyways, I think we are way way ahead of ourselves discussing mechanism before we even understand what the use cases are we are trying to solve. I'd like to see some specific real world use cases and so we can work out the real requirements. I'm expect the uses cases will contain B2BUA in the call flows - that's reality. 

On Sep 24, 2010, at 5: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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Nov 2010 08:04:25 +0800

I'm tempted to agree with Cullen on this.
But I think it "depends".

If the B2BUA is a "proper" UA, and inserts its own Contact address in 
the call, then I think Cullen's description is right.

If its a B2BUA because it messes with things a proxy cannot, but 
*doesn't* modify the Contact address, then just manipulating Supported 
isn't enough. Then the features that *it* supports are obtainable 
directly only by sending a request to *it*, using the Route header, etc. 
to identify that address.

Its always seemed to me that a UA should always supply its own Contact 
address, but I've looked for verification of that in 3261 and not found it.

	Thanks,
	Paul

---

From: "Andrew Allen" <[email-masked]>
Date: Tue, 9 Nov 2010 19:19:49 -0600

I think the second case Paul describes is what in 3GPP is called a Routing B2BUA which sometimes behaves like a proxy and sometimes like a UA. IMHO these entities should use Record-Route to keep themselves on the path and not write their own URI in the Contact but pass the Contact header transparently. To do otherwise breaks things like GRUU and callee caps.

I support the solving in a general way of how an intermediary that provides some kind of funtionality on behalf of a UA can indicate its presence to other entities. 

Another use case for this is helping to solve service interaction problems where multiple application servers are involved and the service logic performed by one may need to be taken into account by the other.

I also think it is necessary that UAs can detect the presence of intermediaries such as IP-PBXs and application servers in the path of a session and obtain a URI to which they can send requests to invoke service logic at those servers without them having to overwrite the contact URI for the reasons stated above.

Andrew.

----- Original Message -----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, November 09, 2010 07:04 PM
To: [email-masked] <[email-masked]>
Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use	Supported

	Thanks,
	Paul

---------------------------------------------------------------------
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: Christer Holmberg <[email-masked]>
Date: Wed, 10 Nov 2010 04:01:19 +0100

Hi,

Andrew is correct: just because something isn't a "pure" proxy, it doesn't mean it is going to modify the Contact header, Supported header etc.

Also, I think the use-case (which I have presented on the list) where a proxy indicates that the Path address information can be used for routing requests in both direction is an example of a "pure" proxy use-case. That is also an old problem, that we have discussed earlier every now and then.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Allen
> Sent: 10. marraskuuta 2010 3:20
> To: [email-masked]; [email-masked]
> I think the second case Paul describes is what in 3GPP is 
> called a Routing B2BUA which sometimes behaves like a proxy 
> and sometimes like a UA. IMHO these entities should use 
> Record-Route to keep themselves on the path and not write 
> their own URI in the Contact but pass the Contact header 
> transparently. To do otherwise breaks things like GRUU and 
> callee caps.
> 
> I support the solving in a general way of how an intermediary 
> that provides some kind of funtionality on behalf of a UA can 
> indicate its presence to other entities. 
> 
> Another use case for this is helping to solve service 
> interaction problems where multiple application servers are 
> involved and the service logic performed by one may need to 
> be taken into account by the other.
> 
> I also think it is necessary that UAs can detect the presence 
> of intermediaries such as IP-PBXs and application servers in 
> the path of a session and obtain a URI to which they can send 
> requests to invoke service logic at those servers without 
> them having to overwrite the contact URI for the reasons stated above.
> 
> Andrew.
> 
> If the B2BUA is a "proper" UA, and inserts its own Contact 
> address in the call, then I think Cullen's description is right.
> 
> *doesn't* modify the Contact address, then just manipulating 
> Supported isn't enough. Then the features that *it* supports 
> are obtainable directly only by sending a request to *it*, 
> using the Route header, etc. 
> Its always seemed to me that a UA should always supply its 
> own Contact address, but I've looked for verification of that 
> in 3261 and not found it.
> 
> 	Thanks,
> 	Paul
> 
> > So, in my week of agreeing with Hadriel, I think he got it 
> exactly right when he said there is pretty much no feature a 
> "plain" proxy would need for this. If we are talking about 
> things that would be a strict technical read be considered 
> B2BUA even if they are implemented a lot like a proxy, then I 
> can why something provided something like this functionality 
> would be needed.
> >
> > 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.
> >
> > If the real uses cases have to do with caller pref 
> features, then B can modify those in the same way.
> >
> > Anyways, I think we are way way ahead of ourselves 
> discussing mechanism before we even understand what the use 
> cases are we are trying to solve. I'd like to see some 
> specific real world use cases and so we can work out the real 
> requirements. I'm expect the uses cases will contain B2BUA in 
> the call flows - that's reality.
> >
> >
> >> 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-f
> >> eature-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
> 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: Hadriel Kaplan <[email-masked]>
Date: Wed, 10 Nov 2010 01:37:58 -0500

Not to contradict myself, but hey it's a new week. :)
A rationale for it could be the cases in which a proxy is a proxy, but switches to b2bua behavior in certain cases. (Paul's regular reminder that being a proxy vs. a b2bua is a dynamic role not a permanent system type)  For example a proxy doing privacy service, or 3pcc for certain call cases, or a generating BYE due to rfc4028 timeouts.  So in the Register/Invite such a proxy would be a proxy, while during certain session/events it may behave as a b2bua?

But it would be good to see/discuss/explain/flesh-out example use-cases. (i.e., "the problem")

-hadriel

---

From: Shida Schubert <[email-masked]>
Date: Wed, 10 Nov 2010 16:21:45 +0900

One example may be an emergency call, AFAIK for 
emergency call defined in ECRIT to work, there are many 
features that are required from proxy(providing location, 
inserting sos URN, possibly looking up LoST etc.), 
especially when client doesn't support ECRIT at all. 

 I don't foresee simultaneous global deployment of 
ECRIT, so knowing if the roaming domain supports 
ECRIT may be important, so home network knows 
whether it can delegate the handling of emergency 
call. 

 Regards
  Shida

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 10 Nov 2010 04:27:00 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]

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.

Dale

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 30 Nov 2010 09:51:05 +0100

hello,

I support solving the 3GPP use case that Christer was refering to in the
draft, using the draft as the basis for the work.

regards
Peter

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Christer Holmberg
> Sent: Wednesday, November 10, 2010 4:01 AM
> To: Andrew Allen; [email-masked]; [email-masked]
> Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why
> notjust use Supported
> 
> 
> Hi,
> 
> Andrew is correct: just because something isn't a "pure" proxy, it
> doesn't mean it is going to modify the Contact header, Supported
header
> etc.
> 
> Also, I think the use-case (which I have presented on the list) where
a
> proxy indicates that the Path address information can be used for
> routing requests in both direction is an example of a "pure" proxy
use-
> case. That is also an old problem, that we have discussed earlier
every
> now and then.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Nov 2010 19:15:49 +0100

Hi,

At the previous 3GPP CT1 meeting, the group indicated willingness to use the mechanism in the draft in the work on session continuity.

There has been some comments on that we need text regarding "directionality", ie if an indicated capability is only valid in one direction, and I agree to that we need to address that.

But, in general I would like to know what to do in order to move the draft forward and adopt it as a working group item.

Regards,

Christer

________________________________________
From: Leis, Peter (NSN - DE/Munich) [[email-masked]]
Sent: Tuesday, November 30, 2010 10:51 AM
To: [email-masked]
Cc: Christer Holmberg; Andrew Allen; [email-masked]
Subject: RE: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust        use     Supported

hello,

regards
Peter

header
a
use-
every