Re: [splices] SIP INVOKE method

[<[e-mail]>]

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: [e-mail]
> [mailto:[e-mail]] Im Auftrag von Shekh-Yusef,
> Rifaat (Rifaat)
> Gesendet: Mittwoch, 18. Mai 2011 21:42
> An: Christer Holmberg; Paul Kyzivat; Peter Musgrave
> Cc: [e-mail]
> Betreff: Re: [splices] SIP INVOKE method
>
> Can you, or someone else, propose some text around this?
>
> Regards,
>  Rifaat
>
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]] On Behalf Of
> > Christer Holmberg
> > Sent: Wednesday, May 18, 2011 1:35 PM
> > To: Paul Kyzivat; Peter Musgrave
> > Cc: [e-mail]
> > 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: [e-mail] [[e-mail]]
> On Behalf Of Paul
> > Kyzivat [[e-mail]]
> > Sent: Wednesday, May 18, 2011 8:29 PM
> > To: Peter Musgrave
> > Cc: [e-mail]
> > 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)
> > > <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
> > >     <mailto:[e-mail]>]
> > >     *Sent:* Wednesday, May 18, 2011 9:32 AM
> > >
> > >
> > >     *To:* Shekh-Yusef, Rifaat (Rifaat)
> > >     *Cc:* Paul Kyzivat; [e-mail] <mailto:[e-mail]>
> > >
> > >     *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)
> > >     <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
> > >     <mailto:[e-mail]>]
> > >      > Sent: Wednesday, May 18, 2011 8:58 AM
> > >      > To: Shekh-Yusef, Rifaat (Rifaat)
> > >
> > >      > Cc: [e-mail] <mailto:[e-mail]>
> > >      > 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: [e-mail]
> > >     <mailto:[e-mail]>
> [mailto:[e-mail]
> > >     <mailto:[e-mail]>] On Behalf
> > >      > Of
> > >      > >> Paul Kyzivat
> > >      > >> Sent: Tuesday, May 17, 2011 3:09 PM
> > >      > >> To: [e-mail] <mailto:[e-mail]>
> > >      > >> 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
> > >      > >> [e-mail] <mailto:[e-mail]>
> > >      > >> https://www.ietf.org/mailman/listinfo/splices
> > >      > >
> > >     _______________________________________________
> > >     splices mailing list
> > >     [e-mail] <mailto:[e-mail]>
> > >     https://www.ietf.org/mailman/listinfo/splices
> > >
> > >
> > _______________________________________________
> > splices mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/splices
> > _______________________________________________
> > splices mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/splices
> _______________________________________________
> splices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/splices
>