Subject: [splices] SIP INVOKE method

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 17 May 2011 09:15:02 -0400

Hi,

As discussed in the last SPLICES WG meeting in Prague, the REFER method is overloaded and has limitations that prevents it from being the ideal method for action invocation.
We have worked on the following new draft that defines a new SIP method to be used for invoking actions:
https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/

We would appreciate it if people review the document and provide us with their feedback.

Regards,
Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 May 2011 15:26:38 +0200

Hi,
 
Section 3 says:
 
"An INVOKE request implicitly establishes a subscription to the 'invoke' event."

However, section 4.2.1 of the 3265bis draft (latest version has expired, but I assume it's still intended to be moved forward) has removed implicit registrations, saying that only SUBSCRIBE can be used to create subscriptions.

Regards,

Christer

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Shekh-Yusef, Rifaat (Rifaat)
	Sent: 17. toukokuuta 2011 16:15
	To: [email-masked]
	Subject: [splices] SIP INVOKE method

	Hi,

	Regards,

	Rifaat

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 May 2011 08:34:48 -0500

And, to be clear, experience has shown that this kind of dual action (do 
the invoke thing *and* create a subscription) ends up being a really bad 
idea. I haven't read the draft yet, so I don't have an opinion on the 
INVOKE mechanism itself, but the way we would do something like REFER 
with the tools we have today would involve explicit subscriptions to a 
GRUU associated with the UAS if (and only if) the UA sending the REFER 
has an interest in the outcome.

/a

On 5/17/11 08:26, May 17, Christer Holmberg wrote:
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 09:51:14 -0400

Rifaat,

I just did a quick read of this.
Some things I like, others not so much.

I like using something other than REFER.

I don't like defining something new that creates an implicit 
subscription. In retrospect the implicit subscription of REFER is widely 
thought to have been a mistake - one we won't do again. As co-chair of 
sipcore I can safely promise that it won't be approved in that form.

Some off-the-cuff thoughts about how to change this to address the concern:

Define an event package. (You already have that.) But require a 
subscription to that package to be overtly established (with subscribe).

Then do one of the following to deliver the action:
- make the action a header in the subscribe request
- encode the action in the body of the subscribe request
- define an in-dialog method to deliver the action within
   the subscribe request.

Of those, I'm tending to the method approach. It would allow use of the 
body to convey extra information about the action.

Perhaps there are cases where the method could be sent without a 
subscription when there is no need to learn the outcome.

In cases where you want to have an ongoing control relationship with 
another device you could just establish the subscription once, and then 
send a series of action requests to it.

	Thanks,
	Paul

On 5/17/2011 9:15 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> Hi,
>
> As discussed in the last SPLICES WG meeting in Prague, the REFER method
> is overloaded and has limitations that prevents it from being the ideal
> method for action invocation.
>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 17 May 2011 11:37:59 -0400

Hi Rifaat,

Overall this is clearly described and I can see the utility.

I agree with other comments that explicit subscriptions are evil.

If find the method name INVOKE very unfortunate - since my brain when
parsing the example actually skipped the INVOKE message thinking it was an
INVITE. Semantically this method is somewhat like HTTP POST - but I think
overloading that term might not be viewed favourably. Maybe ACTION?

Do you foresee having actions which accept parameters? For example there is
a special case of an action 'sendvm' that could be generalized to something
like 'redirect vm'. I could also see a case where terminate might wish to
specify the error code to be used to reject the call.

Will the gory details of what a UA must do for each action be something
which is added to the document?

Regards,

Peter Musgrave

On Tue, May 17, 2011 at 9:15 AM, Shekh-Yusef, Rifaat (Rifaat) <
[email-masked]> wrote:

> Hi,
>
>
>
> As discussed in the last SPLICES WG meeting in Prague, the REFER method is
> overloaded and has limitations that prevents it from being the ideal method
> for action invocation.
>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 17 May 2011 13:13:38 -0400

Doh! I meant implicit subscriptions.

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 17 May 2011 13:27:15 -0400

Thank you all for your quick review and feedback so far.
I will work on a new version of the draft that removes the implicit subscription.

Please, let me know if you have any other comments beside the implicit subscription issue.

Regards,
Rifaat

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shekh-Yusef, Rifaat (Rifaat)
Sent: Tuesday, May 17, 2011 9:15 AM
To: [email-masked]
Subject: [splices] SIP INVOKE method

Hi,

Regards,
Rifaat

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 17 May 2011 14:20:45 -0400

Inline...

> -----Original Message-----
> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Tuesday, May 17, 2011 11:38 AM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: [email-masked]
> Subject: Re: [splices] SIP INVOKE method
> 
> Hi Rifaat,
> 
> If find the method name INVOKE very unfortunate - since my brain when parsing
> the example actually skipped the INVOKE message thinking it was an INVITE.
> Semantically this method is somewhat like HTTP POST - but I think overloading
> that term might not be viewed favourably. Maybe ACTION?
> 
I am not sure that the fact that INVOKE is close to INVITE is an enough justification to change the name.
Anybody else has an opinion on this?

> Do you foresee having actions which accept parameters? For example there is a
> special case of an action 'sendvm' that could be generalized to something like
> 'redirect vm'. I could also see a case where terminate might wish to specify
> the error code to be used to reject the call.
> 
Yes, and I have the following open question about these parameters:
Should a separate header be defined for action parameters?

> Will the gory details of what a UA must do for each action be something which
> is added to the document?
> 
Yes, these details will come. 
I just wanted to get something out there to start a discussion on the idea of a new SIP method for invoking actions.

> Regards,
> 
> Peter Musgrave
> 
> 
> On Tue, May 17, 2011 at 9:15 AM, Shekh-Yusef, Rifaat (Rifaat)
> <[email-masked]> wrote:
> Hi,
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 18 May 2011 00:26:30 +0530

Rifaat,
 
I skimmed through your draft. I like the idea of controlling remote UA
action using new method (INVOKE). Few comments in the draft:
 
1) Sec 4.1: SUBSCRIBE with expire=0 is used to terminate INVOKE dialog
by INVOKE-Issuer. Whether it is ok to "INVOKE with expire=0" terminate
INVOKE dialog as it avoids the dependency on SUBSCRIBE message to
terminate.
 
2) I foresee the complexity in creating explicit subscription because
two dialog creation methods (INVOKE & SUBSCRIBE) are used to make the
single action. It will be good in case INVOKE acts similar to INVITE
(Dialog creation & Action). INVITE has the implicit action like "ring
the phone" or "auto-answer" whereas INVOKE has explicitly mention the
action to be done in INVOKE-recipient.
 
3) Do you foresee INVOKE dialog creation which change the action within
INVOKE dialog. For example: Following three actions using single INVOKE
dialog creation but updating the action based on the application
information..
 
     Action 1:  Create the call
     Action 2:  Hold the call
     Action 3:  Terminate the call
 
Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shekh-Yusef, Rifaat (Rifaat)
Sent: Tuesday, May 17, 2011 10:57 PM
To: Shekh-Yusef, Rifaat (Rifaat); [email-masked]
Subject: Re: [splices] SIP INVOKE method

I will work on a new version of the draft that removes the implicit
subscription.

Please, let me know if you have any other comments beside the implicit
subscription issue.

Regards,

Rifaat

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shekh-Yusef, Rifaat (Rifaat)
Sent: Tuesday, May 17, 2011 9:15 AM
To: [email-masked]
Subject: [splices] SIP INVOKE method

Hi,

We have worked on the following new draft that defines a new SIP method
to be used for invoking actions:

We would appreciate it if people review the document and provide us with
their feedback.

Regards,

Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 15:08:47 -0400

> 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

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 18 May 2011 07:29:30 -0400

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.

Regards,
 Rifaat

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Tuesday, May 17, 2011 3:09 PM
> To: [email-masked]

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 18 May 2011 07:37:18 -0400

Inline...

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: Tuesday, May 17, 2011 2:57 PM
> Subject: RE: [splices] SIP INVOKE method
> 
> Rifaat,
> 
> I skimmed through your draft. I like the idea of controlling remote UA action
> using new method (INVOKE). Few comments in the draft:
> 
> 1) Sec 4.1: SUBSCRIBE with expire=0 is used to terminate INVOKE dialog by
> INVOKE-Issuer. Whether it is ok to "INVOKE with expire=0" terminate INVOKE
> dialog as it avoids the dependency on SUBSCRIBE message to terminate.
> 
The new plan is to remove the implicit subscription.

> 2) I foresee the complexity in creating explicit subscription because two
> dialog creation methods (INVOKE & SUBSCRIBE) are used to make the single
> action. It will be good in case INVOKE acts similar to INVITE (Dialog creation
> & Action). INVITE has the implicit action like "ring the phone" or "auto-
> answer" whereas INVOKE has explicitly mention the action to be done in INVOKE-
> recipient.
> 
I am not sure that I understand your comment, but with the new plan the INVOKE will NOT create a dialog.

> 3) Do you foresee INVOKE dialog creation which change the action within INVOKE
> dialog. For example: Following three actions using single INVOKE dialog
> creation but updating the action based on the application information..
> 
In this case, I expect the INVOKE-Issuer to first create a subscription and then to send the INVOKE requests in the context of that dialog.

> Thanks
> Partha
> 
> ________________________________________
> Shekh-Yusef, Rifaat (Rifaat)
> Shekh-Yusef, Rifaat (Rifaat)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 18 May 2011 17:56:45 +0530

Rifaat,

SUBSCRIBE creates the dialog and within the created subscribe based dialog, INVOKE method (transaction) is sent from subscriber to perform the specific action based on the mentioned URN. Please correct me in case I misunderstand your proposal.

Please read inline

Thanks
Partha

-----Original Message-----
From: Shekh-Yusef, Rifaat (Rifaat) [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2011 5:07 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [splices] SIP INVOKE method

Inline...

> INVOKE dialog as it avoids the dependency on SUBSCRIBE message to terminate.
> 

<Partha> How is it possible for INVOKE-Issuer to abort or stop the action in case required? </Partha> 

> the phone" or "auto- answer" whereas INVOKE has explicitly mention the 
> action to be done in INVOKE- recipient.
> 

> 3) Do you foresee INVOKE dialog creation which change the action 
> within INVOKE dialog. For example: Following three actions using 
> single INVOKE dialog creation but updating the action based on the application information..
> 

<Partha>
In case INVOKE is mid-dialog transaction within SUBSCRIBE dialog, then whether multiple simultaneous INVOKE operation is allowed or not. Example
              1) INVOKE hold action
              2) Even before INVOKE hold completion NOTIFY receives, INVOKE terminate call action

</Partha>

> Subject: Re: [splices] SIP INVOKE method Thank you all for your quick 
> review and feedback so far.
> As discussed in the last SPLICES WG meeting in Prague, the REFER 
> method is overloaded and has limitations that prevents it from being 
> the ideal method for action invocation.

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 18 May 2011 08:54:34 -0400

Inline...

> Sent: Wednesday, May 18, 2011 8:27 AM
> SUBSCRIBE creates the dialog and within the created subscribe based dialog,
> INVOKE method (transaction) is sent from subscriber to perform the specific
> action based on the mentioned URN. Please correct me in case I misunderstand
> your proposal.
> 
Yes, that is correct.

> <Partha> How is it possible for INVOKE-Issuer to abort or stop the action in
One possible way is to define a parameter to the URN and then resend the INVOKE request.
For example, urn:invoke:whatever;abort

> In this case, I expect the INVOKE-Issuer to first create a subscription and
> then to send the INVOKE requests in the context of that dialog.
> 
> <Partha>
> In case INVOKE is mid-dialog transaction within SUBSCRIBE dialog, then whether
> multiple simultaneous INVOKE operation is allowed or not. Example
>               1) INVOKE hold action
Yes, that should be possible.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2011 08:58:18 -0400

> 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 p…

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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 18 May 2011 18:36:39 +0530

Rifaat,

Thanks for the clarification. Please include the text in the next revision to show how multiple simultaneous INVOKE operation happens within the dialog & abort opertion parameter in action URN.

Thanks
Partha 

-----Original Message-----
From: Shekh-Yusef, Rifaat (Rifaat) [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2011 6:25 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [splices] SIP INVOKE method

Inline...

> SUBSCRIBE creates the dialog and within the created subscribe based 
> dialog, INVOKE method (transaction) is sent from subscriber to perform 
> the specific action based on the mentioned URN. Please correct me in 
> case I misunderstand your proposal.
> 
Yes, that is correct.

> > I skimmed through your draft. I like the idea of controlling remote 
> > UA action using new method (INVOKE). Few comments in the draft:
> >
> > 1) Sec 4.1: SUBSCRIBE with expire=0 is used to terminate INVOKE 
> > dialog by INVOKE-Issuer. Whether it is ok to "INVOKE with expire=0" 
> > terminate INVOKE dialog as it avoids the dependency on SUBSCRIBE message to terminate.
> >

> 
> > 2) I foresee the complexity in creating explicit subscription 
> > because two dialog creation methods (INVOKE & SUBSCRIBE) are used to 
> > make the single action. It will be good in case INVOKE acts similar 
> > to INVITE (Dialog creation & Action). INVITE has the implicit action 
> > like "ring the phone" or "auto- answer" whereas INVOKE has 
> > explicitly mention the action to be done in INVOKE- recipient.
> >
> In this case, I expect the INVOKE-Issuer to first create a 
> subscription and then to send the INVOKE requests in the context of that dialog.
> 
> <Partha>
> In case INVOKE is mid-dialog transaction within SUBSCRIBE dialog, then 
> whether multiple simultaneous INVOKE operation is allowed or not. Example
>               1) INVOKE hold action

> > Subject: Re: [splices] SIP INVOKE method Thank you all for your 
> > quick review and feedback so far.

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 18 May 2011 09:25:35 -0400

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

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, May 18, 2011 8:58 AM
> > 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.
>

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 18 May 2011 09:31:58 -0400

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) <
[email-masked]> wrote:

> 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
>
> Behalf
> > Of

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 18 May 2011 11:02:01 -0400

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:[email-masked]]
Sent: Wednesday, May 18, 2011 9:32 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [splices] SIP INVOKE method

Rifaat,

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) <[email-masked]<mailto:[email-masked]>> wrote:
Paul,

Regards,
 Rifaat

> From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of
> >> Paul Kyzivat
> >> To: [email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>
_______________________________________________
splices mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/splices

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 18 May 2011 11:43:15 -0400

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? Does this
debate need to include sipcore?

Peter

On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) <
[email-masked]> wrote:

> *From:* Peter Musgrave [mailto:[email-masked]]
> *Sent:* Wednesday, May 18, 2011 9:32 AM
>
> *To:* Shekh-Yusef, Rifaat (Rifaat)
> *Cc:* Paul Kyzivat; [email-masked]
>
> *Subject:* Re: [splices] SIP INVOKE method
>
>
>
> Rifaat,
>
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 18 May 2011 19:26:44 +0300

I tend to agree that
putting the action in the body seems to make more sense;
even if I have to admit I haven't had time to think more about the issue.

/Sal

On 5/18/11 6:43 PM, 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.
>
> 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? 
> Does this debate need to include sipcore?
>
> Peter
>
>
>
> On Wed, May 18, 2011 at 11:02 AM, Shekh-Yusef, Rifaat (Rifaat) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Peter,
>
>     *From:*Peter Musgrave [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Paul Kyzivat; [email-masked] <mailto:[email-masked]>
>
>     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)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Paul,
>
>     I am not talking about any intermediary, but about application
>     servers on the call path in an enterprise.
>     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
>
>
>     > Cc: [email-masked] <mailto:[email-masked]>
>     > >> From: [email-masked]
>     <mailto:[email-masked]> [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf
>     > Of
>     > >> Paul Kyzivat
>     > >> To: [email-masked] <mailto:[email-masked]>
>     > >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Salvatore Loreto
www.sloreto.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2011 13:29:24 -0400

On 5/18/2011 11:43 AM, Peter Musgrave wrote:
> 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.
>
> 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.
>
> 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

>     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
>

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 18 May 2011 13:37:34 -0400

Do you think it has relevance to CLUE? [For which we *also* have you
as representative ;-) ]

> mapping of call streams to devices, initiating, terminating and otherwise
> managing calls, ...
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2011 19:34:31 +0200

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: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Wednesday, May 18, 2011 8:29 PM
To: Peter Musgrave
Cc: [email-masked]
Subject: Re: [splices] SIP INVOKE method

You have me. :-)

        Thanks,
        Paul

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 18 May 2011 15:42:07 -0400

Can you, or someone else, propose some text around this?

Regards,
 Rifaat

> Christer Holmberg
> Sent: Wednesday, May 18, 2011 1:35 PM
> To: Paul Kyzivat; Peter Musgrave
> Cc: [email-masked]
> 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: [email-masked]
Date: Thu, 19 May 2011 10:02:42 +0800

> putting the action in the body seems to make more sense;

Agree with this. 
"Session" and "application based on session" should be treated as two 
level. Then, making application level indication as body could be more 
acceptable for me.

Thanks,

Gao

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Thu, 19 May 2011 10:50:51 +0200

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: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Shekh-Yusef,
> Rifaat (Rifaat)
> Gesendet: Mittwoch, 18. Mai 2011 21:42
> An: Christer Holmberg; Paul Kyzivat; Peter Musgrave
> Cc: [email-masked]
> Betreff: Re: [splices] SIP INVOKE method
>
> [mailto:[email-masked]] On Behalf Of
> > Christer Holmberg
> > The draft says that each "action" must be represented by a
> URN that is defined
> > by IANA.
> >
> > From: [email-masked] [[email-masked]]
> On Behalf Of Paul
> > Kyzivat [[email-masked]]
> > >     Yes, I expect others to try to define new category of
> actions, but
> > >     these must be registered with IANA.
> > >
> > >     Some application servers might be interested in a
> specific action to
> > >     push application to the phone.
> > >      > > 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
> > >      > What possible reason would an intermediary have
> for snooping into
> > >     these
> > >      > actions?
> > >      >
> > >      > >> I can be convinced otherwise (by a good
> justification), but
> > >     I'm inclined

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 19 May 2011 09:11:25 -0400

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 19, 2011 4:51 AM
> To: Shekh-Yusef, Rifaat (Rifaat); [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [splices] SIP INVOKE method
> 
> Dear Rifaat,
> For me it looks that INVOKE is a new Method that is aimed only to be used for
> a "Conferencing (like) service" purposes.
> 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.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 19 May 2011 15:52:34 +0200

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

> [mailto:[email-masked]] On Behalf Of Shekh-Yusef,
> Rifaat (Rifaat)
> Sent: 19 May 2011 14:11
> To: [email-masked]; [email-masked];
> 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.
> 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
>
>
>
> > I'm a little puzzled about the whole discussion about a new
> Method INVOKE
> > without having any defined requirements.
> > Are there any more used cases, like other service
> invocations like a call
> > forwarding, Call Transfer ect.?
> >
> <mailto:[email-masked]>
> > > > >
> > > > >      > demand for very strong security
> considerations. Putting the
> > > > >     action in a
> > > > >      > >>> Yes, and I have the following open
> question about these
> > > > >     parameters: