Re: [splices] SIP INVOKE method

["Hutton, Andrew" <[e-mail]>]

Hi,

I agree with Roland and would also like see a statement on what requirements are being addressed by this draft.

I also don't see the how this draft relates to the SPLICES WG the charter for which states:

"The objective of this working group is to develop a framework for disaggregated media in "loosely-coupled" scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master".

I was not really convinced that the draft-yusef-dispath-action-ref addressed the same problem space as covered by the SPLICES charter however it seemed that at least there was a chance that it could be one possible use case. However the INVOKE draft seems very far removed from what SPLICES was set up to achieve.

The SPLICES WG charter also states:

"While the framework may describe how to use existing mechanisms (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms".

Is this draft defining a "new device coordination mechanism" ?

How does this draft relate to a framework for disaggregated media in loosely-coupled scenarios? It looks like it does not so probably should go back to DISPATCH.

I also agree with others that a body would seem to make more sense and that an XML body would most likely be needed.

Regards
Andy





> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Shekh-Yusef,
> Rifaat (Rifaat)
> Sent: 19 May 2011 14:11
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [splices] SIP INVOKE method
>
> 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
> > >
>