Subject: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2003 11:58:56 -0400

Folks,

The application interaction design team is near completion of our set 
of documents:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interaction-framework-01.txt
http://www.ietf.org/internet-drafts/draft-jennings-sip-app-info-01.txt
http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-02.txt
http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact-reqs-03.txt

There are really few open issues that we are aware of. The main point 
of contention, and I think the issue most folks want to see a decision 
on, is how to actually convey the DTMF to the application when KPML is 
used. Even within the design team we never really had strong consensus 
here. However, in the interests of progress, we chose the path we felt 
was the one of "least evil". That path was to use a SIP MESSAGE 
request from the client to the application, with content that contains 
the digits. Not ideal, no doubt. I suspect its also not clear from the 
documents that this was our decision. The KPML draft has some artifact 
text that mentions NOTIFY, and it also still talks about HTTP. The 
team did decide not to go with those.

Here were the choices, and the reasoning we went through:

1. Use HTTP POST, as is done in VoiceXML, HTML, WML

This approach works well when the post returns another script to 
execute, as is the case for the above markups. However, because KPML 
has no presentation, only input, there is really little value in doing 
that. KPML is useful for two things. The first are "one shots", where 
the KPML waits for a single sequence, and when it finds it, reports it 
to the application. From there, the application interacts with the 
user using media, and the KPML script is done. Common case: long pound 
in pre-paid. Another modality is what I call "monitor", where the KPML 
stays resident for the ENTIRE call, and simply reports sequences as it 
gets them. Once it reports one, it continues waiting for more.

Neither of these modes quite fit the bill for HTTP. It could be done, 
by having the HTTP POST return the same script that is currently 
running. Not perfect, though. Furthermore, folks were concerned that 
HTTP was too much effort to put on a device just to report DTMF.

2. Use SIP INFO

No doubt this represents the bulk of the implementations today, all 
non-interoperable unfortunately. The problem with INFO is that the 
message from the client to the application needs to be OUTSIDE the 
dialog. Otherwise, every proxy on the path sees it. There are lots of 
other problems with sending INFO within the dialog of the call setup. 
So, once you decide that the messaging from the client to the app is 
outside the dialog, you can't use INFO. INFO is constrained to be 
within the scope of a dialog.

3. Use NOTIFY, have App-Info create an implicit subscription

The client would send a NOTIFY to the application when the digit 
sequence was matched. There would be no SUBSCRIBE. Rather, the 
App-Info header, which was used to pass the script to the client, 
would effectively create an implicit subscription.

Implicit subscriptions have all kinds of troubles, which have been 
discussed on the list. We then need to manage a dialog between the 
client and application just for reporting DTMF.

4. Use an explicit SUBSCRIBE from the application to the client

This has lots of problems. First, it needs to be done outside of the 
original call setup dialog. That means it needs GRUUs for the 
application to target the SUBSCRIBE to the specific UA instance that 
made the call. It also introduces a lot of extra overhead, and would 
repeat information in the App-Info header (i.e., an expression of 
interest)

5. New Method

We could invent a new method, like REPORT-EVENT or something, sent 
from the client to the application. However, that seemed too 
specialized. Also not clear what is really gained from a new method 
above MESSAGE, see below.

6. Messaging Sessions

Use an INVITE from the client to the application, for the purpose of 
setting up a messaging session, ala MSRP. Once the session is setup, 
convey the digits using content in MSRP messages.

This seemed like a lot of overhead and work for what is probably going 
to be one or two messages.

7. SIP MESSAGE

Send a SIP MESSAGE request from the client to the application, 
containing the digit sequence to report.

This was a bit of a bending of the semantic of MESSAGE, which is 
really meant for conveying information for display to a user. However, 
the issue is mostly philosophical in nature. We didnt see any 
particular technical issue that would prevent this from working, 
unlike all of the above ones which had technical issues.

So, as the path of least ugliness and minimal resistance, we went for 
MESSAGE. No doubt folks will have comments. The design team is at the 
point now where broader group input is needed to determine if there is 
consensus around this, or any other, direction. We felt it was 
important to capture our thinking on the options above, to give people 
a context for our decision and to serve as a grounding for further 
discussion.

So, please fire away.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: "Steve Fisher" <[email-masked]>
Date: Wed, 16 Jul 2003 20:29:22 -0400

Great work on the app interaction drafts! I have a few
comments/questions:

1) The framework document refers to both "one shot" and "monitor"
models, and while KPML supports both, support for the "monitor" model is
somewhat awkward (requires having the device quarantine digits and then
issue a new KPML document via a re-INVITE). Is there a reason the
initial KPML document couldn't just specify which model was desired for
that particular interaction, and, if "monitor" was desired, simply keep
monitoring for the specified digits? If we've adandoned HTTP reporting,
I don't see what the downside to this would be.

2) I think that some example message flows would be helpful to tie all
these pieces together, and I would be happy to help draft some if you'd
like.

3) An Jonathan said in the note below, the KPML draft still describes
HTTP reporting, and also mentions NOTIFY. Just to clarify -- are these
mistakes, and the team is now only proposing to use MESSAGE?

4) I also would prefer a new SIP method, instead of overloading MESSAGE.

5) I'm confused how the device determines the Request-URI for the
MESSAGE. The KPML document says:

   When the
   user enters keypress(es) that match a <regex> tag, the user device
   will issue a SIP MESSAGE to the Request-URI specified by the href
   attribute. 
 
and

   The specification of any scheme-specific part, that is, anything
   following the colon in "sip:", is an error.  The interpreter MUST
   reject the request.

If the href attribute can't specify any scheme-specific part, how does
the device determine the Request-URI from the href attribute?

Thanks, and great work!
Steve
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Rosenberg
Sent: Tuesday, July 08, 2003 11:59 AM
To: sipping
Subject: [Sipping] How to report DTMF - conclusion of the app
interaction design team: SIP MESSAGE

Folks,

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interact
ion-framework-01.txt
http://www.ietf.org/internet-drafts/draft-jennings-sip-app-info-01.txt
http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-02.txt
http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact
-reqs-03.txt

2. Use SIP INFO

5. New Method

6. Messaging Sessions

7. SIP MESSAGE

So, please fire away.

Thanks,
Jonathan R.

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jul 2003 08:58:48 -0400

Jonathan Rosenberg wrote:
> This was a bit of a bending of the semantic of MESSAGE, which is really 
> meant for conveying information for display to a user. However, the 
> issue is mostly philosophical in nature. We didnt see any particular 
> technical issue that would prevent this from working, unlike all of the 
> above ones which had technical issues.

Adam gave some good examples of bad things that might happen if the UAS 
was confused and attempted to render this to a user. But there are 
mechanisms already in place to deal with this.

For one thing, the application already has an opportunity to pick the 
address to which the MESSAGEs are sent. So it should be able to ensure 
that the recipient knows these messages shouldn't be displayed directly 
to an end-user.

Beyond that, there is the Content-Disposition header, which seems 
intended for purposes like this. In the normal use of MESSAGE for IM, 
the obvious content type is "render". Here we don't want that, so we 
should pick some other content type.

Sip takes Content-Disposition from RFC 2183, and extends the valid set 
of values. Sip specific values are: session, alert, icon, render, while 
2183 values are inline and attachment. It isn't entirely clear how any 
of these apply to MESSAGE. The following is a shot at defining them:

- session: as defined in 3261, this is N/A for MESSAGE.
            But by extension it might actually be appropriate here.
- alert:   N/A?
- icon:    N/A?
- render:  clearly appropriate - display content to recipient user
- inline:  In the case of email, this means the body should be
            displayed with the containing document. When this is used
            with MESSAGE it *could* be viewed as being processed
            internally by the application.
            So this is a possibility.
- attachment: In case of email this means to not display with the
            enclosing message, and often is used for transferring
            files. This probably has good meaning for file transfer in
            IM.

The prudent course might be to define a new disposition specifically for 
this purpose - perhaps "application", aligning it well with the use of 
App-Info to initiate the process.

Bottom line - I think MESSAGE is quite suitable for the DTMF reports.

	Paul

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 22 Jul 2003 21:14:32 +0200

On Thursday, July 17, 2003, at 02:58 PM, Paul Kyzivat wrote:

>> really meant for conveying information for display to a user. 
>> However, the issue is mostly philosophical in nature. We didnt see 
>> any particular technical issue that would prevent this from working, 
> Adam gave some good examples of bad things that might happen if the 
> UAS was confused and attempted to render this to a user. But there are 
> that the recipient knows these messages shouldn't be displayed 
> directly to an end-user.
>

Paul,

small comment here.  KPML *is* rendered to the user.  The distinction 
that you are seeking between "just through this up on the 
display/speaker" vs. "interpret this markup and show the result to the 
user"  does not exist and in fact is the antithesis of the motivation 
for the term render.  You "render" HTML and XML+XSL and VoiceXML to a 
user.  KPML should be no different.

thanks,
-rohan

> of values. Sip specific values are: session, alert, icon, render, 
> while 2183 values are inline and attachment. It isn't entirely clear 
> how any of these apply to MESSAGE. The following is a shot at defining 
> them:
>
> The prudent course might be to define a new disposition specifically 
> for this purpose - perhaps "application", aligning it well with the 
> use of App-Info to initiate the process.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jul 2003 08:42:01 -0400

Rohan - see below.

	Paul

> user.  KPML should be no different.

I think we are talking about different things. AFAIK this discussion is 
about how the results of processing the KPML are reported back. I agree 
the KPML is rendered, but the results aren't (at least necessarily) 
rendered to the requesting application's "user".

I don't really see a big problem with using MESSAGE here even without 
content-disposition, but some people do, so I am proposing a way out of 
the perceived problem.

	Paul