Re: [splices] SIP INVOKE method
<R.Jesske@telekom.de> Thu, 19 May 2011 08:52 UTC
Return-Path: <R.Jesske@telekom.de>
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 8ADEAE0749 for <splices@ietfa.amsl.com>; Thu, 19 May 2011 01:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 5aLMHHCaZ7Mx for <splices@ietfa.amsl.com>; Thu, 19 May 2011 01:52:18 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F3E0727 for <splices@ietf.org>; Thu, 19 May 2011 01:52:17 -0700 (PDT)
Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 19 May 2011 10:51:08 +0200
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 May 2011 10:50:52 +0200
From: R.Jesske@telekom.de
To: rifatyu@avaya.com, christer.holmberg@ericsson.com, pkyzivat@cisco.com, musgravepj@gmail.com, splices@ietf.org
Date: Thu, 19 May 2011 10:50:51 +0200
Thread-Topic: [splices] SIP INVOKE method
Thread-Index: AcwVgSXc7HGaFOYOS82gk0LsXngJ6QAALKRoAARnCWAAGt3ZsA==
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840E94313@HE111648.emea1.cds.t-internal.com>
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> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3A6@ESESSCMS0356.eemea.ericsson.se> <6369CB70BFD88942B9705AC1E639A33822CBE5CBD4@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBE5CBD4@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 19 May 2011 08:52:19 -0000
Dear Rifaat, I'm a little puzzled about the whole discussion about a new Method INVOKE without having any defined requirements. Is there anywhere a requirements definition where I can see what is needed. For me it looks that INVOKE is a new Method that is aimed only to be used for a "Conferencing (like) service" purposes. Are there any more used cases, like other service invocations like a call forwarding, Call Transfer ect.? What is other than I could do with INVITE, REFER, SUBSCRIBE/NOTIFY and INFO? I do not want to destroy your new method but I would like to see rational around it. And how we could use such method in a general way. Thank you and Best Regards Roland > -----Ursprüngliche Nachricht----- > Von: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org] Im Auftrag von Shekh-Yusef, > Rifaat (Rifaat) > Gesendet: Mittwoch, 18. Mai 2011 21:42 > An: Christer Holmberg; Paul Kyzivat; Peter Musgrave > Cc: splices@ietf.org > Betreff: Re: [splices] SIP INVOKE method > > Can you, or someone else, propose some text around this? > > Regards, > Rifaat > > > -----Original Message----- > > From: splices-bounces@ietf.org > [mailto:splices-bounces@ietf.org] On Behalf Of > > Christer Holmberg > > Sent: Wednesday, May 18, 2011 1:35 PM > > To: Paul Kyzivat; Peter Musgrave > > Cc: splices@ietf.org > > Subject: Re: [splices] SIP INVOKE method > > > > 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 > > _______________________________________________ > > splices mailing list > > 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