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

[Jonathan Rosenberg <[e-mail]>]

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
[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