Subject: Re: [Sipping] I-D Action:draft-audet-sipping-feature-ref-00.txt

From: Adam Roach <[email-masked]>
Date: Mon, 10 Mar 2008 10:21:11 -0400

The document is well-written, but I think it's jumping into the middle 
of the solution without really defining the problem and its requirements.

In particular, I think the document is incomplete without a discussion 
of the use SIP as a substrate versus the use of MBUS (RFC 3259) as a 
substrate. It would appear that the current document is making the broad 
assumption that MBUS is unsuitable for the purpose for which it was 
defined. If this is true, we need to have an explicit discussion around 
what the requirements are for remote feature control, and which one or 
ones MBUS does not satisfy.

It's not clear to me whether there really is an agreed-upon requirement 
that drives us to use SIP here instead of the protocol that we already 
defined for this purpose, or if we're just so used to wielding the SIP 
hammer that no one questions when we start beating screws with it.

/a

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Mar 2008 09:23:47 -0500

Yes, it is making the observation that MBUS is unsuitable.
Correct. 

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Monday, March 10, 2008 07:21
> To: Audet, Francois (SC100:3055); Alan Johnston; Rohan Mahy; 
> Cullen Jennings
> Cc: sipping
> Subject: Re: [Sipping] I-D 
> Action:draft-audet-sipping-feature-ref-00.txt
> 
> The document is well-written, but I think it's jumping into 
> the middle of the solution without really defining the 
> problem and its requirements.
> 
> In particular, I think the document is incomplete without a 
> discussion of the use SIP as a substrate versus the use of 
> MBUS (RFC 3259) as a substrate. It would appear that the 
> current document is making the broad assumption that MBUS is 
> unsuitable for the purpose for which it was defined. If this 
> is true, we need to have an explicit discussion around what 
> the requirements are for remote feature control, and which 
> one or ones MBUS does not satisfy.
> 
> It's not clear to me whether there really is an agreed-upon 
> requirement that drives us to use SIP here instead of the 
> protocol that we already defined for this purpose, or if 
> we're just so used to wielding the SIP hammer that no one 
> questions when we start beating screws with it.
> 
> /a
> 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Mar 2008 10:26:30 -0400

> Yes, it is making the observation that MBUS is unsuitable.

And that's fine, but it needs to be both explicit and motivated, instead 
of merely implied.

Or did I miss that section?

/a

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Mar 2008 09:31:08 -0500

No it's not in there.

No matter how often I read and re-read MBUS, I can't figure out
anything that even comes close to be relevant to the topic...

> Sent: Monday, March 10, 2008 07:27
> To: Audet, Francois (SC100:3055)
> Cc: Alan Johnston; Rohan Mahy; Cullen Jennings; sipping
> And that's fine, but it needs to be both explicit and 
> motivated, instead of merely implied.
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Mar 2008 10:37:05 -0400

MBUS is the transport that you would use. You would take your proposed 
(strawman) service primitives and put them on top of it. Joerg has been 
very willing to discuss this in the past. If you grabbed him during one 
of the breaks this week (or dropped him an email), I'm sure he'd be 
happy to help you out.

/a

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Mar 2008 09:45:11 -0500

Here is a typical scenario.

A bunch of dispersed Agents in a virtual call center, scattered accross the world. 
Perhaps even in different domains.

They have a SIP UA. Some Call Center Application is dispatching calls to them.

Sometimes it forces answer on specific Agents based on whatever criteria (which
will be accepted by the SIP UA if it can, e.g., if there is a headset or speaker). 
Sometimes it transfers calls to another Agent with another skill-set 
(based on completion of some task in the back-end).

This is not about remote control of a speaker. It's also not a transport issue.

> Sent: Monday, March 10, 2008 07:37
> (strawman) service primitives and put them on top of it. 
> Joerg has been very willing to discuss this in the past. If 
> you grabbed him during one of the breaks this week (or 
> dropped him an email), I'm sure he'd be happy to help you out.
> 
> /a
> 
> >> And that's fine, but it needs to be both explicit and motivated, 
> >> instead of merely implied.
> >>

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 Mar 2008 19:36:10 -0400

On Mar 10, 2008, at 10:21 AM, Adam Roach wrote:

> ...
> requirement

I'm a long-time proponent of "SIP for light bulbs".  Setting up a  
session to control a lightbulb (with an appropriate session protocol  
that is not SIP) makes sense to me. Subscribing to a lightbulb's state  
to find out if it is on or off, maybe. But sending the lightbulb a  
REFER to turn it on seems a little bogus.

And as I read the draft, there's not really any difference between a  
REFER that specifies the "answer the call ringing on you now" service  
and a REFER that specifies the "turn on your little red light" service.

That makes me really think Adam is right, and we're whacking something  
with the SIP hammer that needs some other sort of tool applied.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Mar 2008 18:58:12 -0500

Here is a typical use case for this.

A bunch of dispersed Agents with different skill-sets, accross the
Internet (perhaps with even different domains).

The Contact Center application is not a device control application. It's
a contact center application. It operates at the call control level.

It dispatches calls to agents. It does NOT terminate media.
Based on internal logic it may want agents to "force answer" (and not necessary
at the time is incoming, which can already be done with the Auto-Answer flag.
It can happen after a certain number of second if the application determines 
that the call has been queued too long (for example).

The Call Center may want the Agent to transfer the call to another skill set
(based on other criteria, such as the credit card number having been communicated.

Some of these functions can be done with a big honking know-it-all B2BUA sitting
in the middle. But not the "force answer".

However, in other types of applications (not Contact Center), forcing a big honking
B2BUA is not practical. In fact, for a very large class of features, all that the
application does is "monitor" sessions, and only gets involved in call control 
infrequently (this is typical on PBX-attached applications).

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 11 Mar 2008 12:06:46 +0100

Hi,
 
The draft claims that certain things can't be done with REFER, and at the meeting Francois also said that REFER can only be used to "trigger establishment of a call".
 
Bit, if I remember previous discsussions on the list correctly, you can include a method parameter in the Refer-To SIP-URI to trigger non-INVITE requests, e.g. BYE to trigger a disconnect, UPDATE to trigger a hold (in addition you will have to include some SDP attributes, e.g. using sipfrag), and maybe even REFER to trigger a transfer.
 
Regards,
 
Christer

 

________________________________

Lähettäjä: [email-masked] puolesta: Francois Audet
Lähetetty: ma 10.3.2008 15:31
Vastaanottaja: Adam Roach
Kopio: Cullen Jennings; Rohan Mahy; sipping
Aihe: Re: [Sipping] I-D Action:draft-audet-sipping-feature-ref-00.txt

No it's not in there.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 11 Mar 2008 10:10:25 -0500

No, I didn't say this: I said you couldn't use it today for Answereing a call
and for other features listed in the draft.

REFER is already capable of doing many useful things.

You CAN use REFER to:

- REFER to a SIP or Tel URI without refering to an existing dialog 
  (which will by default mean INVITE should be sent). This is a "Make Call" feature.

- REFER to a SIP or Tel URI with a method=blabla without
  referring to an existing dialog. For example, SUBSCRIBE, REFER, REGISTER, whatever.

- You can use REFER to a sip or Tel URI refering to an exising dialog (meaning by
  default INVITE). This can be use for many things including transfer, conferencing,
  music on hold, etc).

- You can use REFER to a SIP or Tel URI with a method=blabla referring to an
  existing dialog. For example BYE, CANCEL, etc. This could be use for "terminate"
  call for example. This was discussed in draft-mahy-sip-remote-cc-05.

- You can use REFER to push a Web Page by using a http URI (see Application 
  Interaction framework). This is highly synergistic with this spec actually and doing
  something different thant REFER would be detrimental to the community.

- You can use REFER to send somebody to email with mailto URI.

- In fact, the spec allows you to use any damned type of URI you want. h323:, whatever.
  So, I ask the question, why not urn:???????

However, REFER does NOT allow to:

- Send REFER to point to a response instead of method. Our previous 
  draft-mahy-remote-cc-05 wanted to add this.

- Send REFER to point to things that don't have a corresponding method or response
  to render it.

Now, on your suggestion below:

- What you are suggesting below is exactly what draft-mahy-remote-cc-05 did. And it
  was rejected. In fact there are some significant disadvantages with this method. It
  requires the Application to know way too much about the remote controlled device for
  it to be practical, and for the remote control to overly trust the application, and
  might therefore be coaxed into performing unatural acts (like, error responses it
  doesn't even understand for example). It also required an unsustainable amount of 
  state synchronization.

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Tuesday, March 11, 2008 04:07
> Subject: draft-audet-sipping-feature-ref-00: What a REFER can 
> and can not do
> 
> Hi,
>  
> The draft claims that certain things can't be done with 
> REFER, and at the meeting Francois also said that REFER can 
> only be used to "trigger establishment of a call".
>  
> Bit, if I remember previous discsussions on the list 
> correctly, you can include a method parameter in the Refer-To 
> SIP-URI to trigger non-INVITE requests, e.g. BYE to trigger a 
> disconnect, UPDATE to trigger a hold (in addition you will 
> have to include some SDP attributes, e.g. using sipfrag), and 
> maybe even REFER to trigger a transfer.
>  
> Regards,
>  
> Christer
>  
>  
>  
>  
>  
>  
> 
> No matter how often I read and re-read MBUS, I can't figure 
> out anything that even comes close to be relevant to the topic...
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 11 Mar 2008 17:13:42 +0100

Hi,

>No, I didn't say this: I said you couldn't use it today for Answereing a call and for other features listed in the draft.

I thought you said a little more than that, but I appologize if I missunderstood.

However, the draft does say:

"o  REFER does not allow for a UA to reques another UA to invoke
      features, e.g.,
      *  REFER does not allow for a UA to request another UA to place a
         call on hold, or to mute it
      *  REFER does not allow for a UA to request another UA to
         transfer, conference, or park a call"

>default INVITE). This can be use for many things including transfer, conferencing,

Correct. And therfor I don't think the text in draft is correct.

>call for example. This was discussed in draft-mahy-sip-remote-cc-05.

Yes. And, I think this is the case which was discussed on the list not-too-long-ago also.

>So, I ask the question, why not urn:???????

I didn't object to that, I simply asked why it doesn't belong to the do-what-I-mean category. 

>was rejected.

Rejected in what sense? If it is allowed, how can someone prevent one from using it?

>In fact there are some significant disadvantages with this method. 

My intention was only to indicate that it CAN be done with existing mechanism. Maybe you should then describe the disadvantages of using existing mechanisms.

>It requires the Application to know way too much about the remote controlled device for

I am not sure what extra information the Application would need to have (it still needs to have the call id information, doesn't it?), but maybe you can add some text about that.

You should also consider the case when the receiver doesn't understand the URN.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 11 Mar 2008 12:22:30 -0500

> You should also consider the case when the receiver doesn't 

That's a good question. I checked 3515 on this, and couldn't find any guidance on
what you do when you don't understand the URI. It appears to be a hole in 3515.

Presumably some sort of 4XX.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 11 Mar 2008 12:26:07 -0500

> Correct. And therfor I don't think the text in draft is correct.

So, if I inserted the word "certain" between "invoke" and "features",
it would be ok, right?

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 12 Mar 2008 18:49:05 +0100

Francois,

You have listed a number of things below which REFER cannot do.

You can only use a tel URI in a Refer-To if you do NOT include a method parameter.

Unfortunately RFC 3966 does not allow parameters or headers to be used with a tel URI thus limiting its usefulness.

If someone can pint out where it says that it IS possible to use these parameters and headers with a tel URI then I will be eternally grateful.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Audet
Sent: 11 March 2008 15:10
To: Christer Holmberg
Cc: sipping
Subject: Re: [Sipping] draft-audet-sipping-feature-ref-00: What a REFER canand can not do

You CAN use REFER to: