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

["Leis, Peter (NSN - DE/Munich)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of ext Christer Holmberg
> Sent: Wednesday, November 10, 2010 4:01 AM
> To: Andrew Allen; [e-mail]; [e-mail]
> 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.
> 
> 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
> >
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore