Subject: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping] RE: I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt)

From: "Eric Burger" <[email-masked]>
Date: Mon, 6 May 2002 11:24:29 -0400

Mumblings I've been hearing include the thought of using the SUBSCRIBE
method to request a device to do something, like play a prompt, prompt and
collect digits, and so on.

This is bad, verging on EVIL.  Let us look at the definition of SUBSCRIBE,
from Section 4.1 of draft-ietf-sip-events-04:

     The SUBSCRIBE method is used to request current state and state
     updates from a remote node [Notifier].

SUBSCRIBE is supposed to be a non-invasive method.  With one exception,
SUBSCRIBE is not supposed to modify the state of the Notifier.  Starting a
prompt play, displaying a screen, or a prompt & collect operation most
definitely changes the state of the Notifier.

The one exception is (obviously) the Notifier responds to the SUBSCRIBE
request.  If there is a non-zero Expires, the Notifier needs to remember to
update the Subscriber.  Other than that, SUBSCRIBE should (MUST?) not have
side effects on the Notifier.

With respect to the comment below, a session is infinitely more appropriate
for the interaction model.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Fairlie-Cuninghame, Robert
Sent: Friday, April 26, 2002 4:59 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: [Sipping] RE: I-D
ACTION:draft-culpepper-sipping-app-interact-reqs-00.tx t

[snip]
I don't see any reason that it wouldn't be possible to place the markup in a
subscription .... or rather, I think perhaps a session is more appropriate
than a subscription for this model.
[snip]

_______________________________________________
Sipping mailing list  https://www1.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: "Bert Culpepper" <[email-masked]>
Date: Wed, 8 May 2002 13:37:04 -0400

I have to disagree with the comments below.  As was proposed, subscriptions
for changes in key states seems an entirely appropriate application of SIP
Events.

Presently, other mechanisms are being considered.  However, a SIP Events
solution can meet the requirements IMO.  Whether this is the best approach
will be determined soon I believe.

If a SIP Events solution does happen, the logic below does not apply.  First
of all, subscriptions for UI data do not change the state of the Notifier
other than establishing a subscription.  They simply ask the SIP UA to
prompt & collect, etc.  I suppose asking a device to update its display may
be thought of changing some state in the Notifier.  But this seems harmless
to me as far as affecting state of any SIP dialog.  Now, an application upon
receipt of some UI data may affect a SIP dialog.  But this is not something
performed by the mechanism we're looking for, it is done by the agent using
the mechanism.  And I think it's not the job of the protocol to prevent
misuse in this case, I think the market will control this kind of thing.  In
fact, the mechanism's primary goal IMO is for applications to be able to
provide services for a SIP dialog (session).

If the act of having to process a SUBSCRIBE and establish a subscription
somehow unacceptably modifies the state of the Notifier, then there is a
fundamental problem with that mechanism itself IMO.  (I don't think that is
the case though.)  And I don't agree that asking an UA to display and report
some indications has any direct effect on any associated dialog established
using INVITE.

BTW, SUBSCRIBE is a dialog establishing method.  And AFAIK, the only method
other than INVITE that can currently establish a SIP dialog (session).

Regards,
Bert

> From: Eric Burger

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 16 May 2002 07:16:27 -0400

This message outlines the results of misusing SUBSCRIBE to change the state
of an endpoint to do work.  This goes way beyond what the current definition
of SUBSCRIBE is and goes way beyond the intentions for SUBSCRIBE.

The key premise is offered in the message sent by Bert.  How is
"subscriptions for UI data do not change the state of the Notifier other
than establishing a subscription" compatible with "They simply ask the SIP
UA to prompt & collect, etc.  I suppose asking a device to update its
display may be thought of changing some state in the Notifier.  But this
seems harmless to me as far as affecting state of any SIP dialog."?

Here is the logical conclusion (and harm) of that line of thinking.  Let us
say I have a media gateway connected to the PSTN.  I want to place a call to
the PSTN, terminating on my SIP Phone.  To place the call, I send a
SUBSCRIBE message to the gateway, registering for the "Call 8885551212"
event.  That causes the gateway to place the call, initiate a SIP session
with my SIP Phone, and send me a NOTIFY that it is done.  "Hey, that's OK"
you say: so what if a SUBSCRIBE has side effects... after all, this clearly
doesn't affect my session; for that matter, there never was a session to
affect in the first place!

Also, how do you reconcile the proposal with draft-ietf-sip-events-05.txt?
Consider:

1. "The SUBSCRIBE method is used to request current state and state updates
from a remote node."
What is the current state of "play a prompt and collect digits"?  Where do
you see the phrase "request current state, do work ON MY BEHALF to change
state, and report the state update"?  When does the subscription expire?  If
you have "Expires: 0", then the UA must IMEDIATELY reply with the NOTIFY.
See #2 next.

2. "In no case should a SUBSCRIBE transaction extend for any longer than the
time necessary for automated processing. In particular, notifiers MUST NOT
wait for a user response before returning a final response to a SUBSCRIBE
request."
While this refers to the 200 OK, it also means that there is no time
available between the 200 OK and the first NOTIFY message.

3. Consider the call flow proposed below.  It looks like the following

      UAC               UAS (e.g., MS)
       |                 |
       |    SUBSCRIBE    |
       |---------------->|
       |command in event |
       |filter body      |
       |                 |
       |     200 OK      |
       |<----------------|
       |                 |
       |     NOTIFY      |
       |<----------------|
       |   what is the   |
       | notification of?|
       |                 |
       |     200 OK      |
       |---------------->|
       |                 |
       |                 |
       =user interaction =
       |                 |
       |     NOTIFY      |
       |<----------------|
       |digits collected?|
       |                 |
       |     200 OK      |
       |---------------->|
       |                 |

That is an awful lot of messages.  Were you thinking of doing a 202?  Ouch!

4. How does the UAC know the subscription has ended with the NOTIFY?  One
could consider using thinking of sending "Subscription-State: terminated".
However, that tells the UAC to try again.  I do not think that would be the
desired behavior.

Some more issues:

Quoting below, "SUBSCRIBE is a dialog establishing method.  And AFAIK, the
only method
other than INVITE that can currently establish a SIP dialog (session)."  I
ABSOLUTELY AGREE.  So, one has a session between the endpoint and someplace
else.  Then, one creates a session by sending a SUBSCRIBE.

5. How does one direct the SUBSCRIBE to the appropriate session at a UAS?
That is, the UAC is in some dialog already with the UAS (the normal INVITE).
How do you direct this "action at a distance" SUBSCRIBE with the first
dialog?

6. The kinds of interactions described below, to me, imply a dialog longer
than one interaction.  For example, if you used this mechanism to collect a
billing number with confirmation, you would (1) prompt-and-collect ("enter
the billing number"), (2) prompt-and-collect ("you entered mumble, press 1
if this is correct"), and (3) prompt ("thank you").  However, using
SUBSCRIBE requires establishing a new dialog for each interaction.  That
again does not sound like an appropriate use of the message.

-----Original Message-----
From: Bert Culpepper [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 1:37 PM
To: [email-masked]; 'Fairlie-Cuninghame, Robert'
Cc: [email-masked]
Subject: RE: Side Effects of SUBSCRIBE are Harmful (was RE: [Sipping]
RE: I-D ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt)

Regards,
Bert

---

From: "Bert Culpepper" <[email-masked]>
Date: Thu, 16 May 2002 14:11:14 -0400

I'm not sure where this thread is going or why it got here...certainly one
can define SIP Events packages that are inappropriate, out-of-scope, and
even harmful.  I don't think anyone has done that to date though.

For the problem at hand, a SIP Events solution has been proposed and an even
"richer" approach has been documented.  The SIP Events approach is simply a
"primitive" that applications can use to derive "user input".  It's an
"indirect" solution to address user application interaction.  But one that
seemed to be the "right" direction in many folks minds from my visibility.
It does have the benefit, IMHO, that is uses the same protocol as the
session control protocol.  In addition, it more tightly couples an
"interaction session" with a SIP session, without trying to invent too much
new semantics.  (Not that defining semantics for a new mechanism is bad or
hard to do.)

I got off the subject...If your point is that using SUBSCRIBE to ask a
device to render some content to a user, then I would have to agree that's
inappropriate.  Now if some Events Package contains some supplemental
information that a device can do with it what it pleases, then I don't see
the harm.  However, any specific proposal probably won't "fly" for several
reasons.  *Requiring* a UA to do anything other than report changes in state
is a misapplication of SIP Events IMO.

Regards,
Bert

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 16:21:46 -0400

I think there is general agreement that putting markup in SUBSCRIBEs in
order to elicit input is over the edge, so let us move on. I want to get
to the heart of the matter, which Bert discusses below.

Bert Culpepper wrote:
> "richer" approach has been documented. 

I assume you are talking about draft-rosenberg-sipping-markup. 

> The SIP Events approach is
> simply a

I would very much like to see broader discussion of this general issue,
which is the framework for solving app interaction requirements. We have
two concrete proposals on the table now, which are:

draft-rosenberg-sipping-markup
draft-culpepper-sip-key-events

and some suggestions by Robert for another approach based on sessions,
which I think needs some more fleshing out, so I'll focus for now on the
above two.

Bert, I think, is indirectly arguing above for his sip-key-events draft,
based on the following points that he alludes to above (Bert please
correct me if I mis-represent your views):

* using a sip events mechanism is perceived as "right" by a lot of
people

* people like to have one protocol, not multiple (the markup draft uses
http)

* the key-events draft doesn't try to solve a broader problem (my
interpretation of his statement "In addition, it more tightly couples an
"interaction session" with a SIP session, without trying to invent too
much new semantics. "

The first one is not a technical argument, and there has been
insufficient list discussion to draw consensus on anything, although
rough consensus at the iterm was that the markup approach was a good way
forward. The second point to me is totally bogus. The
draft-ietf-sip-guidelines has long ago argued that we don't pick
protocols based on the goal of minimziation, its about the right tool
for the right job. I don't think anyone can legitimately argue that a
baseline HTTP implementation is hard, costly, or rare in any devices
these days. The third point is one of perspective. I think that the job
of the sipping group is to think about the broader context of problems.
In my view, considering user input as restricted to DTMF, keys, and
buttons as found on hard phones is limiting. I want to have a unified
framework that handles all forms of input, including ones with displays
(which inlcude many SIP phones). Thus, I think it is a mistake to pursue
a direction which cannot support devices with displays, PCs, or other
forms of user input (such as speech recognition). 

Robert has argued that the markup framework is not adequate to solve the
user input requirements of devices that have knobs, sliders, buttons,
and other things. I can't imagine that this is so; markup can be
anything. Indeed, one can argue that we already have markups defined for
devices with jog dials and soft buttons - its called WAP. 

So, I encourage folks to have a look at these drafts and provide some
input. The conclusion of the interim (as documented in the notes) is
that there was agreement that the markup approach was a good one to move
forward with, but I'd like to see some list discussion.

-Jonthan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Bert Culpepper" <[email-masked]>
Date: Thu, 16 May 2002 22:04:46 -0400

comments (some confirmation) below...

Jonathan Rosenberg wrote:
> > For the problem at hand, a SIP Events solution has been
> proposed and an
> > even

Yes, I am.

> > "indirect" solution to address user application
> interaction.  But one
> > that
> > much
> > new semantics.  (Not that defining semantics for a new
> mechanism is bad
> > or
> > hard to do.)
>

That's my thinking, based on my perceived "scope" of an acceptable solution
within the WG.  (however, my perception is changing.)

> "interaction session" with a SIP session, without trying to invent too

Yes, I have been trying to balance the goals of "solving general problems"
with "primitives".

> baseline HTTP implementation is hard, costly, or rare in any devices

I'll agree here.  And I will say that I often times consider practical
aspects of solutions.  I'd rather implement a service using a single
application layer protocol for the interface vs. multiple application layer
protocols.  But this is not a technical argument, and HTTP/HTML is/should be
supported by any device that "attaches" to the Internet.

> forms of user input (such as speech recognition).

Now here I'll say speech recognition is out-of-scope (of what I thought the
problem is).  Speech recognition requires access to the audio media.
However, if we're also trying to support an interface between an AS and a
separate "media server" then the markup framework can cover this.  But a
separate WG is forming in this area I believe.

> forward with, but I'd like to see some list discussion.

I think the main difference between the two proposals is in their scope.
The markup framework is certainly applicable to many more aspects of user
interaction than a SIP Events solution that only conveys physical actions.
I would like to see clear direction on the way forward.

Thanks,
Bert

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 May 2002 11:29:54 -0400

Bert Culpepper wrote:

> separate WG is forming in this area I believe.

No, I am talking about something different.

There are many endpoints (hardphones, gateways) that can run a VoiceXML
interpreter locally, without ever sending media to a media server. So,
consider a call made from a black phone, through a PSTN gateway, for the
purposes of a pre-paid calling card. The gateway sends a SIP INVITE to
an app server. The app server wishes to collect the pin and destination
number. So, it returns a 183 with an App-Info header containing an HTTP
URL for a VoiceXML script. The gateway fetches the script, and executes
it locally, using the voice on the circuit side to drive it. There is no
voip here; purely local interpretation of the VoiceXML with the user
over the circuit. Once the information is collected, the data is posted
to the app server, which completes the call. 

Local interpretation of VoiceXML using DTMF only is really easy on a
phone with a display; there is no need to speak anything. The prompts
can be rendered on the screen, and the keypad input fed directly into
the script. I believe there are SIP phones that do this today.

> I would like to see clear direction on the way forward.

I would really like to see someone BESIDES me, you and Robert post on
this thread....

-Jonathan R.

---

From: "Neil Deason" <[email-masked]>
Date: Fri, 17 May 2002 20:02:26 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
>
> Bert Culpepper wrote:
> >
> > Now here I'll say speech recognition is out-of-scope (of
> what I thought
> > the
> > However, if we're also trying to support an interface
> between an AS and
> > a

Hello!

Afraid I don't get to follow discussions as closely as I may
like these days but maybe I could take this opp to shamelessly
plug:

http://search.ietf.org/internet-drafts/draft-deason-sipping-soap-session
s-00.txt

In the bigger picture of application components here is a
mechanism that offers a more natural fit between the messages
used to exchange information (key events being a really primitive
example) and SIP/sessions. It provides a transport for these
mechanism which is inherently bi-directional, unlike HTTP, for
more complex p2p applications. It also reuses SIP network
infrastructure but doesn't have the limitations of
SIP in this space. The vocabulary for encoding the messages
is already defined. As is a flexible mechanism for agreeing
a common baseline message format.

Of course like with the case for things like a SOAP presence
authorization component for SIMPLE I may be ahead of my time
here ;)

Cheers,
Neil.
--
Neil Deason                             303 Twin Dolphin Drive
Ubiquity Software Corporation           Suite 600
http://www.ubiquity.net                 Redwood City
[email-masked]                    CA 94065
                                        USA

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 17 May 2002 15:45:48 -0400

Yes, CATS is where we're looking into ASR/TTS/SV.  Check out
http://flyingfox.snowshore.com/mrcp_archive/msg00071.html for the latest
charter.

-----Original Message-----
From: Bert Culpepper [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 10:05 PM
Subject: RE: markup v. sip-events, was: (Re: Side Effects of SUBSCRIBE
are Harmful (was RE: [Sipping] RE: I-D
ACTION:draft-culpepper-sipping-app-interact-reqs-00.txt))
[snip]