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

"Leis, Peter (NSN - DE/Munich)" <peter.leis@nsn.com> Tue, 30 November 2010 08:50 UTC

Return-Path: <peter.leis@nsn.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E544B3A6B3F for <sipcore@core3.amsl.com>; Tue, 30 Nov 2010 00:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d08x+NbuqLiM for <sipcore@core3.amsl.com>; Tue, 30 Nov 2010 00:50:09 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5192E3A69C5 for <sipcore@ietf.org>; Tue, 30 Nov 2010 00:50:08 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oAU8pDTr029055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Nov 2010 09:51:13 +0100
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oAU8pBuG028631; Tue, 30 Nov 2010 09:51:13 +0100
Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Nov 2010 09:51:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Nov 2010 09:51:05 +0100
Message-ID: <79C4240C13B4C84B910850B96B1B431201CCCCB8@DEMUEXC035.nsn-intra.net>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502F9C72C@ESESSCMS0356.eemea.ericsson.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported
Thread-Index: AcuAat6XIt/v9PlARv6xOHOMfSzVMAACn+BqAANhOpAD+bjPkA==
References: <4CD9E189.6050704@cisco.com><BDBFB6CE314EDF4CB80404CACAEFF5DE06AE1E80@XCH02DFW.rim.net> <7F2072F1E0DE894DA4B517B93C6A058502F9C72C@ESESSCMS0356.eemea.ericsson.se>
From: "Leis, Peter (NSN - DE/Munich)" <peter.leis@nsn.com>
To: <sipcore@ietf.org>
X-OriginalArrivalTime: 30 Nov 2010 08:51:07.0049 (UTC) FILETIME=[BA3A8990:01CB906B]
Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2010 08:50:12 -0000

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: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of ext Christer Holmberg
> Sent: Wednesday, November 10, 2010 4:01 AM
> To: Andrew Allen; pkyzivat@cisco.com; sipcore@ietf.org
> 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: sipcore-bounces@ietf.org
> > [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen
> > Sent: 10. marraskuuta 2010 3:20
> > To: pkyzivat@cisco.com; sipcore@ietf.org
> > 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:pkyzivat@cisco.com]
> > Sent: Tuesday, November 09, 2010 07:04 PM
> > To: sipcore@ietf.org <sipcore@ietf.org>
> > 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
> > >> sipcore@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/sipcore
> > >
> > > _______________________________________________
> > > sipcore mailing list
> > > sipcore@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > 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
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore