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

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Fri, 26 Apr 2002 09:11:59 -0600

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

_______________________________________________
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: Fri, 26 Apr 2002 16:42:22 -0400

The requirements Jonathan's proposal address were not meant to address what
functionality an application within a device might provide in terms of its
user interface/user features.  But rather a SIP-based protocol mechanism for
a network application, someplace along the SIP signaling route/path, to be
able to ask for and a mechanism to transmit user indications generated using
whatever user interface a device may possess.

IMHO, the scenario below is an application feature, outside the scope of the
problem to be solved.  However, other folks have suggested the scope be
extended to allow an application to present its user interface to a user
agent/device.  And then report user indications via the specific interface's
widgets (or whathaveyou).  And Jonathan's framework handles this very
nicely.  But the only thing that's SIP is the header to indicate what "page"
to retrieve.  Certainly elegant and simple from a SIP point of view.

What the writer below seems to be asking for (presuming use of SIP here) is
for the Speed Dial application to establish a session with a voice mail
server, and provide the voice mail application with the input it needs to
perform the desired function.  In SIP, this seems better supported using a
specific URI associated with the desired speed dial button.  Where the URI
(and any needed parameters) indicate the service to be provided on the voice
mail server.  No DTMF, keypresses, or whatever are needed.  The SIP protocol
can support this application today.  Now, if you want to access some
DTMF-based voice mail system, then that is another story... (as I'm sure
you're aware :)

Well, some thoughts here, and maybe unrelated to the subject.

Regards,
Bert

Zmolek, Andrew (Andrew) wrote:
>
> 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:
> 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.
>