Re: [splices] SIP INVOKE method

["Shekh-Yusef, Rifaat (Rifaat)" <[e-mail]>]

Hi Ronald,

During the last SPLICES meeting in Prague, we presented the SIP Action Referral draft, which allows applications to make a request to a user agent to perform a well defined action.
https://datatracker.ietf.org/doc/draft-yusef-dispatch-action-ref/

The SIP Action Referral mechanism uses REFER to invoke an action, but REFER has many limitation as described in slide 9 of the attached slide deck presented during the SPLICES WG meeting. The response we got from the people that expressed their opinion on this subject was mostly in favor of a new method to avoid the issues with the REFER method.

Both the SIP Action Referral and the SIP INVOKE method drafts have a list of actions that are either not possible or have a really cumbersome way of invoking them using other SIP methods.

Hope this helps.

Regards,
 Rifaat



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, May 19, 2011 4:51 AM
> To: Shekh-Yusef, Rifaat (Rifaat); [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: AW: [splices] SIP INVOKE method
> 
> 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
> >