Subject: [splices] SIP INVOKE method v1

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Fri, 10 Jun 2011 15:08:22 -0400

Hi,

We have just submitted a new version of the SIP INVOKE method draft that does not include implicit subscription.
https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/

We would appreciate it if you review the document and provide us with your feedback.

Thanks,
Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jun 2011 15:45:37 -0400

This is getting better with age!

Splitting off the subscription is good.

An area that still needs work is in the semantics of the urns.
Some of them are more clear than others. Some are "limited" in ways that 
might not matter to some but that could prove a problem in the end.
Specifically:

     o  Answer call       - urn:invoke:call:answer
     o  Terminate call    - urn:invoke:call:terminate
     o  Decline call      - urn:invoke:call:decline
     o  Ignore call       - urn:invoke:call:ignore

The above need some elaboration, but I think its just work - probably 
anybody who does it will end up with an equivalent result.

     o  Send call to VM   - urn:invoke:call:sendvm

VM is a "feature", and we haven't standardized features much, except for 
bliss. How does one know if the recipient understands VM and what to do 
to send a call there? What if there are multiple VM options (e.g. what 
to say, etc.) And what if the call isn't a voice call. (Maybe VM now 
means voice/video mail. But the "call" could be IM.)

     o  Hold call         - urn:invoke:call:hold
     o  Unhold call       - urn:invoke:call:unhold
     o  Mute call         - urn:invoke:call:mute
     o  Unmute call       - urn:invoke:call:unmute

Similarly these are all "features" that we all have some expectations 
about, but that are not rigorously defined. (But perhaps Mute/Unmute 
could be formalized by using the 'transducer' option. (Transducer=none?)

My concern with all these "features" is that we are being put into a box 
where we must either:
- define them with sufficient rigor
- fall back on "do what I mean", which has proved to be a bad idea,
   because not everybody has the same notion of what they mean.

     o  Conference        - urn:invoke:conference:add
                          - urn:invoke:conference:remove

This one may be clearer due to the existence of xcon specs.

Regarding action parameters:

     o  media=audio|video|audvid

I'm troubled by audvid. I would rather see "audio,video". Specifically, 
what is the namespace here, and what does specifying it mean? I think 
the namespace could be: one or more values allowable as the <media> 
parameter in the m-line in SDP.

Defining exactly what it means when present is a little harder. When 
answering a call that has an offer, I guess it could mean: refuse any 
m-lines with media type that doesn't match one of these, and accept as 
many of the remaining as you can.

For answering an offerless invite, I guess it could mean: offer whatever 
media you are capable of offering that match one of these, but don't 
offer anything that doesn't match.

Is there likely to be a need to get more specific? E.g. about what 
codecs to use? (Hopefully not - that could get very messy.)

     o  transducer=speaker|headset

My deskphone has three possibilities: speaker|headset|handset.
And I'm far from certain this is exhaustive. (The clue wg is defining a 
much more complex environment.) This at least needs to be extensible. We 
may need some sort of extended model of a UA that includes this sort of 
stuff.

     o  target=<AOR>
     o  direction=recvonly|sendonly|sendrecv
     o  abort

None of this is intended as objection to the work so far. Its just a 
start at identifying what else there is to do. The whole notion of 
naming features to invoke causes me the most concern.

	Thanks,
	Paul

On 6/10/2011 3:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 13 Jun 2011 16:04:03 +0200

Hi All,

Whilst I still question whether the mechanism described in this draft actually falls within the SPLICES WG charter as it defines new mechanism I have a few comments.

I tend to agree with Paul's comments below but would go further to say that even some of the supposedly simply actions such as "decline" & "ignore" are also features which will be difficult to agree the semantics for. All of the actions will need to be specified rigorously a quick look at ECMA-269 which specifies these kind of services for CSTA will give you an idea of what would need to be done. I don't believe that even in the CSTA world which defines a very large number of services the services "ignore" or "decline" were specified.

With regard to the discussion on headers vs body the draft states.

"There has been some discussion on the list on the question of header field vs message body.  This is not the real issue, as either could conceivably be used.  Instead, the main issue is what is being invoked:  is it a named feature/action/event, or is it a script".

I must have missed the discussion about scripting but I don't think this is the issue. The issue is I believe extensibility which any mechanism for invoking services will need and this is the reason why an XML body would be better than using SIP headers.  

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 10 June 2011 20:46
> To: [email-masked]
> Subject: Re: [splices] SIP INVOKE method v1
> 
> > We have just submitted a new version of the SIP INVOKE method draft
> that
> > does not include implicit subscription.
> >

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 14 Jun 2011 12:30:15 -0400

Hi Paul,

Thanks for the detailed review and feedback.
I agree with you that this is the next thing that we need to describe in details.
I will be working on providing more details to explain our thinking around the various actions and parameters.

Regards,
 Rifaat

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Friday, June 10, 2011 3:46 PM
> To: [email-masked]

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 14 Jun 2011 12:32:13 -0400

Andy,

> The issue is I believe extensibility which any mechanism for
> invoking services will need and this is the reason why an XML body would be
> better than using SIP headers.

What makes you think that the current proposal is not extensible?

Regards,
 Rifaat

> Hutton, Andrew
> Sent: Monday, June 13, 2011 10:04 AM
> To: Paul Kyzivat; [email-masked]
> Whilst I still question whether the mechanism described in this draft actually
> falls within the SPLICES WG charter as it defines new mechanism I have a few
> comments.
> 
> I tend to agree with Paul's comments below but would go further to say that
> even some of the supposedly simply actions such as "decline" & "ignore" are
> also features which will be difficult to agree the semantics for. All of the
> actions will need to be specified rigorously a quick look at ECMA-269 which
> specifies these kind of services for CSTA will give you an idea of what would
> need to be done. I don't believe that even in the CSTA world which defines a
> very large number of services the services "ignore" or "decline" were
> specified.
> 
> "There has been some discussion on the list on the question of header field vs
> message body.  This is not the real issue, as either could conceivably be
> used.  Instead, the main issue is what is being invoked:  is it a named
> feature/action/event, or is it a script".
> 
> I must have missed the discussion about scripting but I don't think this is
> the issue. The issue is I believe extensibility which any mechanism for
> invoking services will need and this is the reason why an XML body would be
> better than using SIP headers.
> 
> Regards
> Andy
> 
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Jun 2011 19:18:28 +0200

Hi Rifaat,

I am not saying that the current proposal is not extensible but I believe that an XML body would be a much better solution to the extensibility problem that using a SIP header.

The list of potential actions and associated parameters is huge and for this kind of problem I believe that an XML body would be a much better solution. I guess I much prefer XML to BNF.

There is also an architectural issue as the actions don't relate directly to the management of the SIP session and therefore most likely need to passed to the application layer in the SIP UA to handle. It is much cleaner architecturally if the body can simply be removed and passed to the responsible component in the UA rather than the SIP component having to extract the information from SIP headers.

Regards
Andy

> From: Shekh-Yusef, Rifaat (Rifaat) [mailto:[email-masked]]
> Sent: 14 June 2011 17:32
> To: Hutton, Andrew; Paul Kyzivat; [email-masked]
> Subject: RE: [splices] SIP INVOKE method v1
> 
> Andy,
> 
> Behalf Of
> > > VM is a "feature", and we haven't standardized features much,
> except
> > > for
> > > My concern with all these "features" is that we are being put into
> a
> > > box
> > > where we must either:
> > > much more complex environment.) This at least needs to be
> extensible.
> > > We
> > > > We would appreciate it if you review the document and provide us
> with
> > > > your feedback.
> > > >
> > > > Thanks,
> > > >
> > > > Rifaat
> > > >
> > > >
> > > >

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 14 Jun 2011 13:32:59 -0400

> From: Hutton, Andrew [[email-masked]]
> 
> The list of potential actions and associated parameters is huge and
> for this kind of problem I believe that an XML body would be a much
> better solution. I guess I much prefer XML to BNF.

I'd feel much more comfortable if we settled on either:

1) a small number of actions

2) to use an appropriate subset of an existing CTI standard

In the latter case, could someone provide a pointer to the standard?

Essentially, INVOKE is to provide an interface to a command set, and
we need to have some idea what the outer limits of the command set
will be.  Only then can we choose a good way to represent the commands
within a SIP request.

Dale

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 14 Jun 2011 13:42:08 -0400

Andy,

> The list of potential actions and associated parameters is huge and for this
> kind of problem I believe that an XML body would be a much better solution. I
> guess I much prefer XML to BNF.
> 
This actually calls for a header rather than an XML body, because the idea is to control what get standardized and what not and clearly define the actions that get standardized. With an XML body you actually create a tunnel over SIP and you lose control over what get defined.

Regards,
 Rifaat

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Tuesday, June 14, 2011 1:18 PM
> To: Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat; [email-masked]
> I am not saying that the current proposal is not extensible but I believe that
> an XML body would be a much better solution to the extensibility problem that
> using a SIP header.
> 
> The list of potential actions and associated parameters is huge and for this
> kind of problem I believe that an XML body would be a much better solution. I
> guess I much prefer XML to BNF.
> 
> There is also an architectural issue as the actions don't relate directly to
> the management of the SIP session and therefore most likely need to passed to
> the application layer in the SIP UA to handle. It is much cleaner
> architecturally if the body can simply be removed and passed to the
> responsible component in the UA rather than the SIP component having to
> extract the information from SIP headers.
> 
> Regards
> Andy
> 
> 
> 
>

---

From: Alan Johnston <[email-masked]>
Date: Tue, 14 Jun 2011 12:45:41 -0500

Andy,

I agree with Dale that the set of actions should be small, otherwise,
we are doing something else.  Also, the set of parameters needs to be
small.  In fact, I think most actions won't have any parameters at
all.  This is why we are using URNs, just names, for the actions.

To do otherwise is to introduce complex actions or scripts, and I
don't want this mechanism to be used for that.  There are other
mechanisms (e.g. CPL) that allows a script to be uploaded or
downloaded to control a UA or proxy operation, but that is very
different from what we are talking about here.

I agree that we could discuss BNF vs XML, but if we agree that we
really are dealing with URNs, then a header makes more sense than a
body.

- Alan -

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Jun 2011 20:13:12 +0200

Hi Dale,

I think the problem is that we don't have any specified requirements so we don't know what the boundaries are. 

What has been specified so far already looks like it is trying to do CTI type things and for that we know the list of possible services is endless. The most relevant standards would probably be ECMA-269 and ECMA-323 (http://www.ecma-international.org/publications/standards/Ecma-323.htm) if you want to see the XML for this.

I don't see how it is really possibly to limit this to a small set of actions as once the mechanism is implemented there will always be requirements to add more actions.

Regards
Andy

> From: Worley, Dale R (Dale) [mailto:[email-masked]]
> Sent: 14 June 2011 18:33
> To: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat;
> [email-masked]

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Jun 2011 20:25:41 +0200

Hi Alan,

Might be nice to keep it to a small set but I an not convinced it is possible and most actions will need parameters when you consider different media types, audio devices etc. and even simple actions like call terminate will almost certainly need a reason code.

Regards
Andy

> From: Alan Johnston [mailto:[email-masked]]
> Sent: 14 June 2011 18:46
> To: Worley, Dale R (Dale)
> Cc: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat;
> [email-masked]

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 14 Jun 2011 14:35:48 -0400

________________________________________
From: Hutton, Andrew [[email-masked]]

I don't see how it is really possibly to limit this to a small set of actions as once the mechanism is implemented there will always be requirements to add more actions.
________________________________________

Thanks for those references!

Yes, there is a real scope-creep problem.  Looking at ECMA-323, I see 45 "Call control services and events", and that is not the majority of the defined operations.

One possibility would be to define INVOKE as a carrier for ECMA-323 operations.  But even then, a lot of care needs to be taken to see how to embed the dataflow model of ECMA-323 into the SIP request/response structure.  If we define our own CTI set, we have to create our own dataflow model.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jun 2011 15:56:03 -0400

I'm with Dale that we need to scope the command set,
or equivalently, scope the environment that is being manipulated and the 
degrees of freedom that it has.

If it isn't "small" then it at least needs to be characterized. And the 
larger it is the bigger a deal the work is. So its important to figure 
it out. The mechanism to convey the commands is secondary to that.

For instance (as I have mentioned before in passing), if the scope 
includes "call control" in the sip sense, including o/a, then it becomes 
a very big deal unless we can reuse sip for it. We really don't want to 
define something new and different from sip that is functionally 
equivalent to sip.

My expectation is that we are talking about something at a higher level 
of abstraction than SIP. But being at a higher level doesn't mean 
"vague". And while it almost certainly needs to be extensible for things 
we don't consider at first, IMO that doesn't mean we should define a 
mechanism with no intrinsic functionality, just an extension mechanism. 
That is a guarantee we will get it wrong.

We can look to CSTA or one or more definitions of CTI. I did investigate 
CSTA once, and didn't love it. But if it comes close to the needs here 
we might consider adopting it. I don't know much about CTI, but my 
impression is that it is a buzz word with many only loosely related 
instantiations, and is predicated on different architectural models than 
will work for us. (But I'll be pleased to be educated by somebody who 
really knows.)

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 14 Jun 2011 18:31:07 -0400

I agree too.

I also thought CSTA was a bit too "kitchen sink" when I looked at it years ago. But perhaps we can use it to guide a very modest subset? It has at least looked at a very similar problem space so there should be lessens learned there...

Peter

Sent from my iPad

On 2011-06-14, at 3:56 PM, Paul Kyzivat <[email-masked]> wrote:

> or equivalently, scope the environment that is being manipulated and the degrees of freedom that it has.
> 
> If it isn't "small" then it at least needs to be characterized. And the larger it is the bigger a deal the work is. So its important to figure it out. The mechanism to convey the commands is secondary to that.
> 
> For instance (as I have mentioned before in passing), if the scope includes "call control" in the sip sense, including o/a, then it becomes a very big deal unless we can reuse sip for it. We really don't want to define something new and different from sip that is functionally equivalent to sip.
> 
> My expectation is that we are talking about something at a higher level of abstraction than SIP. But being at a higher level doesn't mean "vague". And while it almost certainly needs to be extensible for things we don't consider at first, IMO that doesn't mean we should define a mechanism with no intrinsic functionality, just an extension mechanism. That is a guarantee we will get it wrong.
> 
> We can look to CSTA or one or more definitions of CTI. I did investigate CSTA once, and didn't love it. But if it comes close to the needs here we might consider adopting it. I don't know much about CTI, but my impression is that it is a buzz word with many only loosely related instantiations, and is predicated on different architectural models than will work for us. (But I'll be pleased to be educated by somebody who really knows.)
> 
>    Thanks,
>    Paul
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 15 Jun 2011 11:01:38 +0200

Hi Rifaat,

I don't understand the argument as the header/body issue makes no difference to what gets standardized and architecturally it is much cleaner to tunnel the non SIP related application stuff in a body that to use a SIP header for the same purpose.

Having said that I still don't think that either mechanism would fall within the SPLICES charter.

Regards
Andy

> Sent: 14 June 2011 18:42
> for this
> This actually calls for a header rather than an XML body, because the
> idea is to control what get standardized and what not and clearly
> define the actions that get standardized. With an XML body you actually
> create a tunnel over SIP and you lose control over what get defined.
> 
> Regards,
>  Rifaat
> 
> 
> for this
> > > > invoking services will need and this is the reason why an XML
> body
> > > would be
> > > > Whilst I still question whether the mechanism described in this
> draft
> > > actually
> > > > I tend to agree with Paul's comments below but would go further
> to
> > > say that
> > > > also features which will be difficult to agree the semantics for.
> All
> > > of the
> > > > actions will need to be specified rigorously a quick look at
> ECMA-269
> > > which
> > > > specifies these kind of services for CSTA will give you an idea
> of
> > > what would
> > > > need to be done. I don't believe that even in the CSTA world
> which
> > > defines a
> > > > "There has been some discussion on the list on the question of
> header
> > > field vs
> > > > I must have missed the discussion about scripting but I don't
> think
> > > this is
> > > > the issue. The issue is I believe extensibility which any
> mechanism
> > > for
> > > > invoking services will need and this is the reason why an XML
> body
> > > would be
> > > > > Some of them are more clear than others. Some are "limited" in
> ways
> > > > > that
> > > > > bliss. How does one know if the recipient understands VM and
> what
> > > to do
> > > > > to send a call there? What if there are multiple VM options
> (e.g.
> > > what
> > > > > to say, etc.) And what if the call isn't a voice call. (Maybe
> VM
> > > now
> > > > > answering a call that has an offer, I guess it could mean:
> refuse
> > > any
> > > > > m-lines with media type that doesn't match one of these, and
> accept
> > > as
> > > > > None of this is intended as objection to the work so far. Its
> just
> > > a

---

From: <[email-masked]>
Date: Thu, 16 Jun 2011 10:50:50 +0200

Hi,
now I'm puzzled about the scope?

Is the scope of INVOKE to realise the Computer Supported Telecommunications Applications (CSTA)?

Best Regards
Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Worley, Dale R (Dale)
> Gesendet: Dienstag, 14. Juni 2011 20:36
> An: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul
> Kyzivat; [email-masked]
> Betreff: Re: [splices] SIP INVOKE method v1
>
> I think the problem is that we don't have any specified
> requirements so we don't know what the boundaries are.
>
> What has been specified so far already looks like it is
> trying to do CTI type things and for that we know the list of
> possible services is endless. The most relevant standards
> would probably be ECMA-269 and ECMA-323
> (http://www.ecma-international.org/publications/standards/Ecma
> -323.htm) if you want to see the XML for this.
>
> I don't see how it is really possibly to limit this to a
> small set of actions as once the mechanism is implemented
> there will always be requirements to add more actions.
> Yes, there is a real scope-creep problem.  Looking at
> ECMA-323, I see 45 "Call control services and events", and
> that is not the majority of the defined operations.
>
> One possibility would be to define INVOKE as a carrier for
> ECMA-323 operations.  But even then, a lot of care needs to
> be taken to see how to embed the dataflow model of ECMA-323
> into the SIP request/response structure.  If we define our
> own CTI set, we have to create our own dataflow model.
>
> Dale

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sat, 18 Jun 2011 09:23:52 -0400

Hi Roland,

I browsed through the CSTA documents. This seems to go way beyond what we had in mind for the actions with the INVOKE method.
I will shortly send a separate email to start a discussion around the scope of the actions with the INVOKE method.

Regards,
 Rifaat

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 16, 2011 4:51 AM
> To: Worley, Dale R (Dale); [email-masked]; Shekh-Yusef,
> Rifaat (Rifaat); [email-masked]; [email-masked]
> Subject: AW: [splices] SIP INVOKE method v1
> 
> Hi,