Subject: [Sipping] draft-burger-sipping-kpml-00.txt

From: "Steve Fisher" <[email-masked]>
Date: Mon, 4 Nov 2002 16:44:42 -0500

Eric B.,

I'm excited to see the work of the app interaction design team. I have a
couple of questions on the KPML draft:

1) I don't really understand the value of the <pattern> tag. Does it
just exist to enable/disable barge in? Do you envision that one KPML
document will have multiple <pattern> tags, presumably some that support
barge in and some that don't? If so, perhaps you could have an example
that shows multiple <pattern> tags. If not, then why have the pattern
tag? 

Alternatively, couldn't the "barge" parameter be a paramater in the
<regex> tag, which I think would allow us to eliminate the <pattern> tag
altogether.

2) I'm unfortunately not familiar with Megaco digit maps. Is it the case
that a variety of keypresses could match the same <regex> tag? If so,
then is there a mechanism to send the actually keypresses to the
application server? I would think this would be important.

3) In Section 3, the document states:

   Because it is not possible to know if the signaled digits may be for 
   the far end, the device transmits the digits to the far end in real 
   time, using either RFC 2833 or by generating the appropriate tones. 
    
         NOTE: If KPML did not have this behavior, then a device 
         executing KPML could easily break called applications.  
         For example, take a personal assistant that uses "*9" 
         for attention.  If the user presses the "*" key, KPML 
         will hold the digit, looking for the "9".  What if the 
         user just enters a "*" key, possibly because they 
         accessed an IVR system that looks for "*"?  In this 
         case, the "*" would get held by the device, because it 
         is looking for the "*9" pattern.  The user would 
         probably press the "*" key again, hoping that the called 
         IVR system just didn't hear the key press.  At that 
         point, the device would send both "*" entries, as "**" 
         does not match "*9".  However, that would not have the 
         effect the user intended when they pressed "*".  

Your statement is true for the example you give, but there are cases
where the application can determine that it has the focus. For example,
consider AT&T's existing "Transfer Connect" service, which allows one
user (or IVR system) to transfer its call leg to another device (such as
a call center agent's phone). For this service, the user (or IVR system)
would enter something like "*T9732366799", where "*T" indicates that
these digits are intended for the Transfer Connect app, with the
remaining digits indicating the phone number to tranfer to. In the
existing AT&T service, the "*T" is transmitted to the far end, but the
remaining digits are not (many of you have probably experienced this
service when an IVR system transfers you to a call center). While
clearly SIP provides better mechanisms for an IVR system to transfer a
call leg, you could imagine other such systems where the first string of
digits identify the application, and it would then be desirable for the
next set of digits to be suppressed from the media stream (e.g., you
could imagine a consumer version of this "Transfer Connect" service,
allowing people, for example, to transfer a call leg from a home phone
to a cell phone via DTMF signalling).

Some time ago we talked about adding this capability to DML (now KPML),
and I'm disappointed that it was not included.

Thanks!
Steve

_______________________________________________
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