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

["Steve Fisher" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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,

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

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

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
[e-mail] FAX: [phone]
http://www.jdrosen.net PHONE: [phone]
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 [e-mail] for questions on current sip Use
[e-mail] for new developments of core SIP


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