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
>