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

[Christer Holmberg <[e-mail]>]

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Andrew Allen
> Sent: 10. marraskuuta 2010 3:20
> To: [e-mail]; [e-mail]
> Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- 
> why not just use Supported
> 
> 
> 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:[e-mail]]
> Sent: Tuesday, November 09, 2010 07:04 PM
> To: [e-mail] <[e-mail]>
> Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- 
> why not just use	Supported
> 
> 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
> 
> On 11/10/2010 4:42 AM, Cullen Jennings wrote:
> >
> > 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-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
> >> _______________________________________________
> >> sipcore mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain 
> confidential information, privileged material (including 
> material protected by the solicitor-client or other 
> applicable privileges), or constitute non-public information. 
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender 
> and delete this information from your system. Use, 
> dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and 
> may be unlawful.
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>