Subject: Digit suppression (was [Sipping] Comments on updated KPML draft)

From: "Eric Burger" <[email-masked]>
Date: Fri, 14 Mar 2003 10:08:49 -0500

On the one hand, it is trivially easy to add a "suppress=yes" parameter to the digit map tag.  However, I am still VERY concerned about the local/remote digit processing.  For review, here is the example from the draft:

<quote>
NOTE: If KPML did not have this behavior, then a user 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 user device, because it is looking for the "*9" pattern. The user would probably press the "*" key again, hoping that the called IVR system just did not hear the key press. At that point, the user device would send both "*" entries, as "**" does not match "*9". However, that would not have the effect the user intended when they pressed "*". 
</quote>

Does this issue ever go away?

> Original Message From: Bert Culpepper [mailto:[email-masked]]
[snip]
>  > The text at the end of this section discusses the 
> inability for a user
>  > device to know that signaled digits are for KPML processing or the
>  > recipients of a media stream.  Therefore DTMF must be sent 
> in the media
>  > stream in addition to be reported using KPML.  It seems to 
> me that if a
>  > user device receives a KPML document for processing, it'll 
> know based on
>  > the digit map what is meant for processing vs. sending in the media
>  > stream.  I realize processing key presses for digit map 
> matching will
>  > delay the transmission when matches don't occur, however I 
> expect this
>  > delay to be very small, resulting in no degradation of the user 
> experience.
> 
> Reflecting on my weekend comments, the cases where it would be
> OK to delay sending indications in the media stream are 
> limited to very
> short digit maps (a single digit practically speaking).  But for those
> cases, long digits such as the "long pound", and when focus can be
> determined by the user device, it'll be desirable to NOT to have the
> indications duplicated in the media stream.
> 
_______________________________________________
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: Tom Taylor <[email-masked]>
Date: Fri, 14 Mar 2003 12:11:45 -0500

This one is easy to answer.  Pattern match when you have alternatives like "*" and 
"*9" has to use timers to make the distinction.

---

From: Bert Culpepper <[email-masked]>
Date: Fri, 14 Mar 2003 20:01:33 -0500

Right, when the pattern exceeds a single digit we have timing issues, 
and the issue as Eric describes in the I-D is present.

Suppression can only be used in limited cases IMHO.  Steve F's proposal 
(in his message) seems reasonable.  Suppression only occurs after focus 
is determined.

I'm not sure if it's practical to try and handle suppression at any 
point in the digit map (i.e., not sending the "long pound" in the media 
stream).  This would require focus determination to be attempted prior 
to sending the indication in the media stream.  This is probably too 
much to expect a user device to support.  However, I'm neutral on this 
aspect.

Regards,
Bert

Tom Taylor wrote:

> This one is easy to answer.  Pattern match when you have alternatives 
> like "*" and "*9" has to use timers to make the distinction.
> 
> Eric Burger wrote:
> 
>> On the one hand, it is trivially easy to add a "suppress=yes" 
>> parameter to the digit map tag.  However, I am still VERY concerned 
>> about the local/remote digit processing.  For review, here is the 
>> example from the draft:
>>
>> <quote>
>> NOTE: If KPML did not have this behavior, then a user 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 
>> user device, because it is looking for the "*9" pattern. The user 
>> would probably press the "*" key again, hoping that the called IVR 
>> system just did not hear the key press. At that point, the user device 
>> would send both "*" entries, as "**" does not match "*9". However, 
>> that would not have the effect the user intended when they pressed 
>> "*". </quote>
>>
>>> > The text at the end of this section discusses the inability for a user
>>> > recipients of a media stream.  Therefore DTMF must be sent in the 
>>> media
>>> > stream in addition to be reported using KPML.  It seems to me that 
>>> if a
>>> > user device receives a KPML document for processing, it'll know 
>>> based on
>>> > stream.  I realize processing key presses for digit map matching will
>>> > delay the transmission when matches don't occur, however I expect this
>>> OK to delay sending indications in the media stream are limited to very

---

From: "Steve Fisher" <[email-masked]>
Date: Fri, 14 Mar 2003 11:02:38 -0500

Eric,

I know we've been having this discussion forever, but it still seems to
me that AT&T's Transfer Connect service serves as a good model for how
this can work (we've been working on similar services for end users that
leverage SIP's ability to make "media transfer" far more efficient than
was possible in the PSTN, and so this is more than an academic exercise
for us). 

In Transfer Connect there is an "agent" listening for tones. Until it
hears "*8", it passes them through. Once it hears "*8", though, it
assumes that the transfer connect application has the focus, and
suppresses the next 10 digits. I'm sure most of us in the US have heard
the effect of this service when we call a toll-free number, get an IVR
system, and are then transferred to a live agent -- we hear the "*8",
but do not hear the next 10 tones (I suspect we can all agree that even
those 2 tones are annoying -- 12 would be intolerable!).

Thus, in this model there is one set of tones that is used to determine
the focus, and then another set that provides the actual data for that
application. It seems to me that this model could apply to KPML, using
something like the following:

Add an additional attribute to the <regex> tag named, say, "suppress",
as in the following example:

<regex value="E8"
	suppress="10" 
	href="sip:" /> 

This would be equivalent to the following tag:

<regex value="E8XXXXXXXXXX" href="sip:" />
	
except that the UA may, at its discretion (I do think support for
"suppress" should be optional), suppress the 10 digits following the
"*8" from the audio path. In this case the application server is
providing a hint to the UA that if it sees a "*8" then this application
wants the focus, and that the next 10 digits should only be sent to this
application (via SIP NOTIFY), and not to any other application,
including an application that may be on the other end of the media
stream.

Of course, another application may also have "*8" as part of its <regex>
tag, and in this case the UA should probably ignore the "suppress"
attribute. Alternatively, the UA could NOTIFY both applications, but
still suppress the tones.

Is this reasonable?

Thanks!
Steve Fisher
Division Manager
AT&T Labs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Burger
Sent: Friday, March 14, 2003 10:09 AM
To: Bert Culpepper
Cc: SIPPING List
Subject: Digit suppression (was [Sipping] Comments on updated KPML
draft)

On the one hand, it is trivially easy to add a "suppress=yes" parameter
to the digit map tag.  However, I am still VERY concerned about the
local/remote digit processing.  For review, here is the example from the
draft:

<quote>
NOTE: If KPML did not have this behavior, then a user 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 user device,
because it is looking for the "*9" pattern. The user would probably
press the "*" key again, hoping that the called IVR system just did not
hear the key press. At that point, the user device would send both "*"
entries, as "**" does not match "*9". However, that would not have the
effect the user intended when they pressed "*". 
</quote>

[snip]
> Reflecting on my weekend comments, the cases where it would be OK to 
> delay sending indications in the media stream are limited to very
_______________________________________________
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: "Steve Fisher" <[email-masked]>
Date: Fri, 14 Mar 2003 11:04:06 -0500

Eric,

<regex value="E8"
	suppress="10" 
	href="sip:" /> 

	
except that the UA may, at its discretion (I do think support for
"suppress" should be optional), suppress the 10 digits following the
"*8" from the audio path. In this case the application server is
providing a hint to the UA that if it sees a "*8" then this application
wants the focus, and that the next 10 digits should only be sent to this
application (via SIP NOTIFY), and not to any other application,
including an application that may be on the other end of the media
stream. Note that in this model there is no "holding" of digits that
produced the bad behavior you cite in your example. The UA knows, for
each digit, whether to suppress it or not.

Is this reasonable?

Thanks!
Steve Fisher
Division Manager
AT&T Labs

-----Original Message-----

<quote>

[snip]
>  > The text at the end of this section discusses the inability for a 
> user  > device to know that signaled digits are for KPML processing or

> the  > recipients of a media stream.  Therefore DTMF must be sent
> in the media

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Mar 2003 04:59:31 -0500

I think I would be comfortable with a suppression mechanism if we place 
some constraints on it:

1.  it only suppressed when there were no ambguities in the digit map. 
That is, if after pressing a digit sequence, only one pattern across all 
KPMLs matched, and that pattern expressed a suppression, you would 
suppress from the media stream.

2. the text is clear that this can interfere with the operation of other 
applications listening on the media stream. You should only do 
suppression when you are using "focus detection" digit maps of 
sufficient length to be certain of this (i.e., not * or #).

Now, you can still run into trouble when the media stream terminates on 
a gateway or application server that is looking for dtmf patterns but 
not using KPML. But with the above caveats perhaps we can make that case 
an infrequent one.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com