Subject: [Sipping] new I-D on markup languages for DTMF and user input

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Apr 2002 11:33:08 -0400

Folks,

I've just submitted an I-D that discusses a SIP framework for the usage
of markup languages (HTML, VoiceXML, WML) for stimulus signaling for
driving sip applications. The draft also proposes a DTMF markup
language, DML, that operates within the framework. 

Until it appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-markup-00.txt

Comments and questions welcome as always.

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

_______________________________________________
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: [email-masked]
Date: Thu, 25 Apr 2002 18:07:25 EDT

> Comments and questions welcome as always.

So here are some thoughts on the subject:

1. 2nd para says: "stimulus signaling in the PSTN has traditionally been done 
through DTMF input and with speech recognition." In fact, it has been done 
through "digit" input, whether DTMF or dial pulse. On/off hook signaling is 
also used, for example, hookswitch flashes. But what is defined in this draft 
better ignore dial pulse and hookswitch flashes.

Since the point of having DML is to eliminate the need to actually generate 
DTMF tones in a phone and send them to the network, it appears that this plan 
requires only that the phone have an appropriate keypad, maybe 12 buttons 
like a DTMF keypad, but maybe more like the keypad on a computer keyboard or 
some other arrangement. Note that requirement R8 in Section 5 says that "the 
mechanisms must support user indications via keys or buttons and at the very 
least must define support for user interaction via a standard, generic 
computer keyboard." One could even envision a nostalgia-evoking black SIP 
phone with a rotary dial ! In any case, it would no longer be based on actual 
use of DTMF, so the markup language should not be called "DTMF". How about 
Digit-entry Markup Language?

3. To make DML useful in some situations to solve the excessive delay of 
other techniques, it could also provide capabilities to apply and remove dial 
tones at specific places in the digit map, but that is obviously going beyond 
the intent.

For example, in the example for 91xxx... in 3.2, actual use requires that the 
first dial tone be removed as soon as the 9 starts, a second dial tone be 
applied after the 9 and removed as soon as the 1 starts. In practice, the 
dial tone from before the 9 could just be left until the 1 and the user won't 
notice, but there are applications which require a different dial tone for 
these two parts. MGC apparently has trouble doing this.

3.2 In the examples it is unknown why "T" is appended to some of the entries 
(copied from RFC 2705). These are not included in H.248, but the application 
of timers is covered by the procedures. In any case, no timeout would be 
applied after "00" in this dial plan. (Incidentally, I know of no place where 
this dial plan would be valid. Access to a long distance operator from inside 
a PBX would typically require dialing 9 and 00.)

In the example for 9011x.T, as in RFC 2705, there is no provision to know 
that dialing is complete when it gets to 15 digits. The user could dial 
forever, and the UA would be required to store all the digits. If multiple 
potentially matching strings are processed as defined in H.248, then there 
should be multiple conditions as follows to limit digit collection to 15 
after the 9011:

9011xxxxxxxxxxxxxxx (15 x's)
9011x .

According to the procedures, this would result in application of a short 
timeout after each digit after 9011x since, at this point, the dialed string 
may match either condition. In fact, in traditional telephony 
implementations, this short time-out is not applied until some minimum number 
of digits have been received to prevent incorrectly timing out. It is only 
applied at the specific ambiguous points in the digit string. MGC/H.248 do 
not appear to include a way to do this without generation of huge digit maps. 
While a Gateway could easily store such large maps, it seem infeasible to 
download them to UAs for each call setup (just in case the user dials an 
international call).

4.1 With a UA supporting DML, there is no longer a need for the entry of the 
"pound" to actually be "long". Local detection of a key press separate from 
the actual voice channel eliminates the need for the key depression to be 
"long". It was long in the traditional model only to allow more precise 
detection of the tone pair in the presence of speech and to allow a single 
device to look for it on many simultaneous calls.

4.1.3. The third sentence should read "However, once the call is established, 
the indication of the desire to place a second call (possibly by the entry of 
the pound key on the DTMF keypad) is detected at the client with DML." 

The first full sentence under Figure 3 would be clearer if it read: "The 
script that is returned (8) causes the VoiceXML server to generate audible 
prompts to ask the user to enter ..." Again, the references in this paragraph 
to "listen for a long pound" and "enters a long pound" should be changed.

It isn't clear how a UA can handle both cases that require DML and those that 
don't. In the examples given, it may be assumed that, when normal calls are 
placed, the UA actually sends DTMF tones corresponding to the pressing of 
buttons (as implied in Section 4.1.3). This would be used to support 
traditional services that did not use DML. In other cases, the UA must buffer 
the keypad presses until it gets the appropriate DML script to tell it what 
to do. The whole point of DML is that the UA doesn't understand the service 
being provided, so it would need to be told when to apply each procedure.

Mike Pierce
Artel

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 26 Apr 2002 09:59:35 -0700

Hi Andrew,

The requirements listed in draft-rosenberg-sipping-markup-00 are actually
referring the requirements drafted in
draft-culpepper-sipping-app-interact-reqs-00. 

We (Bert Culpepper and myself) are currently working on putting out another
version of the requirements draft to address some of Jonathan's comments.
Please feel free to add more comments.

In Jonathan's Markup draft did present a mode=immediate in DML that allowed
you to send subsequent indication without stop-and-wait'ing for the response
to the first. Additionally, one of the requirements in the abovementioned
requirements draft attempted to address the fact that stop-and-wait is not
acceptable. 

Is this adequate to fulfill your concerns? Otherwise, what functional
requirement did you have in mind?

Regards,

Robert.

> -----Original Message-----
> From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
> Sent: Friday, April 26, 2002 4:12 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [Sipping] new I-D on markup languages for DTMF and user
> input
> 
> 
> This draft is very timely. I'd like to forward on a comment 
> on the need for a scripting requirement that I received after 
> circulating this internally - see below
> 
> --Andy
> 
> ----------------------------
> 
>  - how would this accommodate "type-ahead"?  For example, 
> when I interact with my voice mail system from my cell phone, 
> I have one speed dial button programmed with the following sequence:
>       3134145000<pause><pause>45000#3456789#2#0#
> What does this do?  it dials my Audix, pauses for the 
> greeting to connect, and dials my extension and my password, 
> then selects "play messages" and then starts playing the 
> first message - all in one button push for me.  
> 
> I don't see how Rosenberg's scheme accommodates something 
> like this.   If each interaction must wait for a HTML 
> response with a page to load, then the next step cannot be 
> completed until that page has downloaded and been rendered.  
> Each user entry (e.g. extension, then password, then play 
> messages) must be entered separately.  And I don't see a way 
> to preprogram it.   Users would view this as a loss of functionality.
> 
> Rosenberg's requirements in section 5 don't include a 
> requirement for user "scripting" or "preprogramming of 
> responses" like I have described.  I think this is an omission.
> 
> -----------------------------
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Wednesday, April 24, 2002 9:33 AM
> > To: [email-masked]
> > Subject: [Sipping] new I-D on markup languages for DTMF and 
> user input
> > 
> > 
> > Folks,
> >