Re: [splices] SIP INVOKE method
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 18 May 2011 17:37 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D276FE06C8 for <splices@ietfa.amsl.com>; Wed, 18 May 2011 10:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YZShMkeOWYq for <splices@ietfa.amsl.com>; Wed, 18 May 2011 10:37:39 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7551BE074D for <splices@ietf.org>; Wed, 18 May 2011 10:37:39 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-9c-4dd403e2cc91
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 30.A9.09774.2E304DD4; Wed, 18 May 2011 19:37:38 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 18 May 2011 19:37:37 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Peter Musgrave <musgravepj@gmail.com>
Date: Wed, 18 May 2011 19:34:31 +0200
Thread-Topic: [splices] SIP INVOKE method
Thread-Index: AcwVgSXc7HGaFOYOS82gk0LsXngJ6QAALKRo
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se>
References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com> <BANLkTinLjrS3DocT=_MbnDrHdoTLs7RuhQ@mail.gmail.com> <6369CB70BFD88942B9705AC1E639A33822CBDA9548@DC-US1MBEX4.global.avaya.com> <4DD2C7BF.1030000@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C339@DC-US1MBEX4.global.avaya.com> <4DD3C26A.9050705@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C465@DC-US1MBEX4.global.avaya.com> <BANLkTi=RrRrJEqrqVoWkS428y4-=TPZ16A@mail.gmail.com> <6369CB70BFD88942B9705AC1E639A33822CBE5C63F@DC-US1MBEX4.global.avaya.com> <BANLkTikSBqp3bVHvX57Ekm07s+SDvcHGeA@mail.gmail.com>, <4DD401F4.6050502@cisco.com>
In-Reply-To: <4DD401F4.6050502@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "splices@ietf.org" <splices@ietf.org>
Subject: Re: [splices] SIP INVOKE method
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2011 17:37:40 -0000
Hi, I have a similar comment, regarding the applicability. The draft says that each "action" must be represented by a URN that is defined by IANA. But, there are no restrictions regarding what types of "actions" are allowed - or even a description about what the criterias for an "action" are in the first place. Regards, Christer ________________________________________ From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] Sent: Wednesday, May 18, 2011 8:29 PM To: Peter Musgrave Cc: splices@ietf.org Subject: Re: [splices] SIP INVOKE method On 5/18/2011 11:43 AM, Peter Musgrave wrote: > If INVOKE is to become a general method, then I could easily see people > wanting to use e.g. an XML body to specify an action. If a new method is > being defined then I would think making it fairly general would be a > good idea - and limiting an action to one text line in a header might > be considered limiting. Hence a body would be more flexible. > > One the other hand being too general will likely get is into trouble > again (e.g. the five uses of REFER) - so maybe being very specific is a > good thing. In this case I could see just a header sufficing. > > A very classic dilemma... > > Do people feel that a general INVOKE mechanism is missing in SIP - or do > we want to just focus on UA actions and the SPLICES requirement? I think it needs to be general in the sense of not limited to the set of things decided at this time. But not so general that it becomes a general purpose tunnel-over-sip mechanism. There needs to be a scope of applicability. I'm thinking its limited to controlling the behavior of a sip device with respect to the mapping of call streams to devices, initiating, terminating and otherwise managing calls, ... AFAIK the main objection to bodies is the need to create a new parser. With a sip header you take advantage of the sip parser, though you may need to extend it to handle a new method. Some might object to XML bodies in particular because they require a fairly heavy parser, which can be a problem in limited devices. In some other devices of course that stuff is already present and so no burden. Of course sip headers are just a special case of mime headers. Were we to choose as a body type another extension of mime, then it might still be possible to reuse a parser. This clearly requires more discussion. We might want to bring in a security guru sooner rather than later. I think there will likely be many concerns to be addressed, and addressing them may constrain the shape of the solution. > Does this debate need to include sipcore? You have me. :-) It will certainly involve sipcore at some point. I think we can explore the options for awhile before worrying too much about that. I'm more worried about security. Thanks, Paul > Peter > > > > On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) > <rifatyu@avaya.com <mailto:rifatyu@avaya.com>> wrote: > > Hi Peter, > > Yes, I expect others to try to define new category of actions, but > these must be registered with IANA. > > I am not clear on how this strengthens the case for using a body. > > Regards, > > Rifaat > > *From:*Peter Musgrave [mailto:musgravepj@gmail.com > <mailto:musgravepj@gmail.com>] > *Sent:* Wednesday, May 18, 2011 9:32 AM > > > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* Paul Kyzivat; splices@ietf.org <mailto:splices@ietf.org> > > *Subject:* Re: [splices] SIP INVOKE method > > Rifaat, > > I agree with Paul - a body may make sense. > > If we are going as far as defining a new SIP METHOD - does it make > sense to have separate problem domains for the URNs? Do we think in > the future others might want a different "package" of actions for > some other purpose? If so, I think this strengthens the case for > using a body. > > Peter > > On Wed, May 18, 2011 at 9:25 AM, Shekh-Yusef, Rifaat (Rifaat) > <rifatyu@avaya.com <mailto:rifatyu@avaya.com>> wrote: > > Paul, > > I am not talking about any intermediary, but about application > servers on the call path in an enterprise. > Some application servers might be interested in a specific action to > push application to the phone. > I agree that strong security is required and we are asking the > client to only allow authorized users to invoke an action by > challenging the INVOKE-Issuer. > > Regards, > Rifaat > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > <mailto:pkyzivat@cisco.com>] > > Sent: Wednesday, May 18, 2011 8:58 AM > > To: Shekh-Yusef, Rifaat (Rifaat) > > > Cc: splices@ietf.org <mailto:splices@ietf.org> > > Subject: Re: [splices] SIP INVOKE method > > > > > > > > On 5/18/2011 7:29 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Hi Paul, > > > > > > I think that the main reason for using Headers for actions and > parameters is > > to allow for proxy applications on the call path to recognize the > requested > > action, as some UAs might encrypt the body part. > > > > Hmm. That seems to me to be more reason to use a body part! > > > > What possible reason would an intermediary have for snooping into > these > > actions? > > > > Note that this functionality is *very* sensitive - in the wrong hands > > this stuff can do great damage. I predict that there will be a lot of > > demand for very strong security considerations. Putting the > action in a > > body and encrypting it might be a good approach. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: splices-bounces@ietf.org > <mailto:splices-bounces@ietf.org> [mailto:splices-bounces@ietf.org > <mailto:splices-bounces@ietf.org>] On Behalf > > Of > > >> Paul Kyzivat > > >> Sent: Tuesday, May 17, 2011 3:09 PM > > >> To: splices@ietf.org <mailto:splices@ietf.org> > > >> Subject: Re: [splices] SIP INVOKE method > > >> > > >> > > >> > > >> On 5/17/2011 2:20 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > >> > > >>> Yes, and I have the following open question about these > parameters: > > >>> Should a separate header be defined for action parameters? > > >> > > >> I can be convinced otherwise (by a good justification), but > I'm inclined > > >> toward describing the action and any parameters in a body part. > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> splices mailing list > > >> splices@ietf.org <mailto:splices@ietf.org> > > >> https://www.ietf.org/mailman/listinfo/splices > > > > _______________________________________________ > splices mailing list > splices@ietf.org <mailto:splices@ietf.org> > https://www.ietf.org/mailman/listinfo/splices > > _______________________________________________ splices mailing list splices@ietf.org https://www.ietf.org/mailman/listinfo/splices
- Re: [splices] SIP INVOKE method gao.yang2
- [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method - implicit regist… Christer Holmberg
- Re: [splices] SIP INVOKE method - implicit regist… Adam Roach
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Parthasarathi R (partr)
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Parthasarathi R (partr)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Parthasarathi R (partr)
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Salvatore Loreto
- Re: [splices] SIP INVOKE method Paul Kyzivat
- Re: [splices] SIP INVOKE method Peter Musgrave
- Re: [splices] SIP INVOKE method Christer Holmberg
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method R.Jesske
- Re: [splices] SIP INVOKE method Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method Hutton, Andrew