Subject: RE: [Sipping] Please Read Committee T1 Draft on DTMF Notification

From: "Joe Zebarth" <[email-masked]>
Date: Wed, 5 Nov 2003 20:46:28 -0500

Eric

Thank you for taking the time to review this document which was developed to
support the IANA registration of this event package.  

This event package was intended to support the use scenario as identified
within the document, viz. "This event package MAY be used to allow an
application server (subscriber) to request DTMF monitoring and notification
of detection from a receiving agent (notifier) in order to enable a
caller-initiated re-origination request while a call is in progress."  It is
important to understand that this usage scenario assumes that the DTMF
signal comes from the portion of the PSTN that uses TDM technology and that
the application server supports SIP and also forms part of the PSTN.

This is a reponse to your email, please see the comments in line.

Kindest regards,

Joe Zebarth
T1S1.7 Vice Chair

Dept. 1A12
ATI Strategic Standards
Nortel Networks (Canada)
Phone: +1 613 765 8481
ESN:    6+395 8481
Fax:     +1 613 763 2697
ESN:    6+393 2697
http://www.nortelnetworks.com

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Wednesday, October 29, 2003 10:03 PM
To: Dean Willis; [email-masked]
Cc: Zebarth, Joe [CAR:1A12:EXCH]
Subject: RE: [Sipping] Please Read Committee T1 Draft on DTMF
Notification

Things I like in dtmfad:
 
1. Explicit maxrate (but see below)
2. "Handshook" throttling (although isn't that normal SIP: no overlapping
transactions?)
3. Very simple and compact
4. Described forking and state agent behavior (I forgot!)

Things I don't like:
1. The model is worse than MGCP.  An event for every key press?  If you are
interested in such low-level control, use H.248.
 
	Comment: JAZ
	This document is not discussing control.  Rather it is addressing
the subject of capturing the DTMF digits that originated in the portion of
the PSTN that uses TDM technology and which subsequently enter the portion
of the PSTN that uses IP technology.  The application server already
supports SIP.  The implementation of the event package is a modest extension
to support this capability.
 
2. The model only works for a B2BUA or machine end point.  The far end is
the only entity that can request digit monitoring.  OK for a "softswitch",
but not necessarily desirable in an Applications and Services
Infrastructure.

	Comment: JAZ
	I believe that your observation is correct that the far end is the
only entity that can request digit monitoring in this usage scenario.  The
usage scenario calls for the far end to request digit monitoring. 
 
3. Duration: On the one hand, it is handy to be able to define what "long"
is.  However, this is a disaster.  What if I set "duration=50" and I hold
the octothorpe key down for 6 seconds?  I will get 120 NOTIFY messages in
that time.  That isn't helpful for traffic shaping.  What does the
application do with all of those messages?  The model is taken directly from
RFC2833 (keep emitting tone and mark the end-of-tone) -- why not just use
RFC2833 and be done with it?  Eating a low-rate RTP stream has GOT to be
easier than implementing a RFC3261 stack!
 
	Comment: JAZ
	The usage scenario assumes that SIP is implemented.  Thus, the
proposed implementation is as you suggest "simple and compact" to add this
capability.
	 
	The following guidance is contained in the document to prevent
operators from setting the optional duration parameter to some number like
50 ms. (If this optional parameter is not present, then event notification
occurs only when the end of the DTMF tone is detected.), viz.
	 
		'Note: for long key presses, combined with short values of
"duration", a single DTMF digit can result in many NOTIFY requests.  With
calling card re-origination requests, in particular, the Application Server
(AS) cannot provide a prompt for a new destination number or begin
collecting digits if the caller is still pressing a DTMF key, so the AS must
wait for completion of the tone.  Therefore, it is likely that sending
NOTIFY requests at the termination of each detected DTMF digit is preferable
to sending many NOTIFY requests for each digit.  As a result, it is
RECOMMENDED that the AS not include the "duration" parameter.'
	 
	Additional guidance is also given in this regard, viz.
	 
		'maxrate
		"maxrate" is an optional parameter defining a maximum number
of NOTIFY transactions per minute initiated to report DTMF events.  The
notifier MUST NOT exceed this limit in any one minute period, but MAY send
notifications in more rapid bursts over shorter periods.  If "maxrate" is
omitted, the notifier MUST limit reporting to forty (40) NOTIFY transactions
per minute.  "maxrate" SHOULD NOT exceed 60. 
		 
		If the reporting rate limit causes a queue of unreported
events to build up, the notifier MAY discard some or all of the excess
events.  If the notifier can choose which events to discard, the notifier
SHOULD discard notifications of uncompleted DTMF events resulting from the
presence of the "duration" parameter before discarding notifications of
completed DTMF events.'
	 
	Should the optional duration parameter be set, the text allows the
notifier to delete/discard notifications of uncompleted DTMF events.
 
4. Hex codes don't really fit into the SIP gestalt.  Why not encode the
information in a straightforward manner?  One cannot argue for compactness
-- if one is going to live with 600+ bytes of SIP headers (see the example
in the document), one can have a 35-byte text message that means something
instead of a 12-byte "binary" message that is indecipherable.
 
	Comment:JAZ
	As the event package is intended to carry dtmf digits and as they
are transparent to SIP processing, we believe that the defined event package
is consistent with normal IETF style.
  
Things I am open to:
1. Volume: Does anyone need this?  What for?  How would you know?  What
would you do with it?  Not for falsing detection: that is what the detection
device should be doing.  If there is a good use case, I could see
implementing it.  Then again, what do you do for RFC2833 digit detection (no
volume)?
 
	Comment JAZ
	The DTMF tone originates in the TDM portion of the PSTN and thus
depending on the PSTN transmission plan the DTMF tone levels may vary.
 
2. Maxrate: I'm leaning towards not liking it, but I'm open to it.
First, the SUBSCRIBER here only specifies its own ability to process NOTIFY
requests.  Using this as a network-saving device isn't going to work: how
does the subscriber have any idea what to set this to? 
Second, the default maxrate is one message every 16ms, or faster than G.711.
What could this be possibly useful for?
Third (and the big one), the whole point of transporting digits in the
signaling path is because the digits *are* signaling.  Said differently, the
application needs reliable delivery of signaling (digits).  If the use case
for this package allows unreliable delivery, then I would be very interested
in understanding why one is not using RFC2833, which has EVERYTHING
discussed in this draft, available today?
 
	Comment JAZ
	The usage scenario only calls for the far end to request digit
monitoring.  The subscriber is typically using a PTSN phone to originate
calls and subsequent in band dtmf tones.  Maxrate provides additional
security against people who do insist upon holding down a DTMF digit when
the carrier has set the duration parameter to a short duration.

	As you indicated earlier, this is a "very simple and compact" way of
implementing this feature.

	In summary, based on your comments, I do not see any technical
issues with the proposed event package.

	I would look forward to your support in having this work progress so
that the event package can be registered with IANA in a timely fashion.

	Again I would like to thank you for taking the time to comment on
this document.

	Kindest regards, 
	Joe Zebarth

	T1S1.7 Vice Chair

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tue, October 28, 2003 2:27 AM
> To: [email-masked]
> Cc: Joe Zebarth
> Subject: [Sipping] Please Read Committee T1 Draft on DTMF Notification
> 
> 
> While we were arguing about how to handle keypresses, 
> somebody went out
> and wrote a draft for an event package for DTMF events.
> 
> Please review the draft:
> 
> http://www.softarmor.com/wgdb/docs/draft-zebarth-sipping-dtmfad-00.txt
> 
> As I understand it, the mechanism that this draft is meant to 
> support is
> defined in Committee T1 Technical Report T1.TR.82-2003. 
> Unfortunately, I
> wasn't able to find said document on the T1 site, but that 
> could just be
> me -- perhaps the author can give us a link?
> 
> Questions to consider: Does this approach complement or conflict with
> the KPML work? Is there danger of fragmenting, or is this work clearly
> seperate? Would the world (or at least the Internet) be a better place
> with, or without, this event package?
> 
> Please copy the author, as well as the list, on any 
> responses. I expect
> that discussion on this topic will come up during the Minneapolis
> meeting.
> 
> Thanks,
> 
> --
> Dean Willis
> SIPPING co-chair
> 
> _______________________________________________
> 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: "Eric Burger" <[email-masked]>
Date: Mon, 10 Nov 2003 18:27:57 -0500

Comments in-line.

Executive summary: the proposal does not work in general.  Moreover, it will not work for the limited scope scenario described.  Finally, there is another solution available that will meet (and exceed) all of the requirements for your situation.

It is up to the chairs and AD's, but I would offer that you would not be able to publish this draft, as it overlaps with the KPML work (a work group item) and is potentially harmful to the Internet.  That would make an IANA registration in the IETF tree impossible.

> -----Original Message----- From: Joe Zebarth [mailto:[email-masked]]
> 
> Eric 
> Thank you for taking the time to review this document which was
> developed to support the IANA registration of this event package.  
> This event package was intended to support the use scenario as
> identified within the document, viz. "This event package MAY be used
> to allow an application server (subscriber) to request DTMF
> monitoring and notification of detection from a receiving agent
> (notifier) in order to enable a caller-initiated re-origination
> request while a call is in progress."  It is important to understand
> that this usage scenario assumes that the DTMF signal comes from the
> portion of the PSTN that uses TDM technology and that the application
> server supports SIP and also forms part of the PSTN.

I do not see how the DTMF being generated in the PSTN, generated in an IP Phone, generated by a gateway, etc. is at all relevant.  Is there a difference?

> 2. "Handshook" throttling (although isn't that normal SIP: no overlapping transactions?) 
> 1. The model is worse than MGCP.  An event for every key press?  If
> you are interested in such low-level control, use H.248.
>  
> Comment: JAZ 
> This document is not discussing control.  Rather it is addressing the
> subject of capturing the DTMF digits that originated in the portion
> of the PSTN that uses TDM technology and which subsequently enter the
> portion of the PSTN that uses IP technology.  The application server
> already supports SIP.  The implementation of the event package is a
> modest extension to support this capability.

Unfortunately, the model of issuing one *or more* notifications per digit, with the express intent of capturing timing, signal strength, etc. is very much a device control model.  The SIP (applications and services) model is the client (the application server, in this case) makes a request of the server (the gateway).  That request uses application-layer semantics, like "give me digits that match this map" or "give me digits", not device-layer semantics, like "give me the tones and associated signal parameters."

>  
> 2. The model only works for a B2BUA or machine end point.  The far
> end is the only entity that can request digit monitoring.  OK for a
> "softswitch", but not necessarily desirable in an Applications and
> Services Infrastructure.
> Comment: JAZ 
> only entity that can request digit monitoring in this usage scenario. 
> The usage scenario calls for the far end to request digit monitoring. 

This says it will not work for pre-paid, which is your target application.

>  
> 3. Duration: On the one hand, it is handy to be able to define what
> "long" is.  However, this is a disaster.  What if I set "duration=50"
> and I hold the octothorpe key down for 6 seconds?  I will get 120
> NOTIFY messages in that time.  That isn't helpful for traffic
> shaping.  What does the application do with all of those messages? 
> The model is taken directly from RFC2833 (keep emitting tone and mark
> the end-of-tone) -- why not just use RFC2833 and be done with it? 
> Eating a low-rate RTP stream has GOT to be easier than implementing a
> RFC3261 stack!
>  
> Comment: JAZ 
> proposed implementation is as you suggest "simple and compact" to add
> this capability.

60 bytes (including IP headers) per message for RFC2833 vs. 800 bytes per message for SIP does not make a compelling "simple and compact" argument.

> operators from setting the optional duration parameter to some number
> like 50 ms. (If this optional parameter is not present, then event
> notification occurs only when the end of the DTMF tone is detected.),
> viz.
>  
> "duration", a single DTMF digit can result in many NOTIFY requests. 
> With calling card re-origination requests, in particular, the
> Application Server (AS) cannot provide a prompt for a new destination
> number or begin collecting digits if the caller is still pressing a
> DTMF key, so the AS must wait for completion of the tone.  Therefore,
> it is likely that sending NOTIFY requests at the termination of each
> detected DTMF digit is preferable to sending many NOTIFY requests for
> each digit.  As a result, it is RECOMMENDED that the AS not include
> the "duration" parameter.'

Here is where you have tripped the device control vs. applications and services wire.  If you want a protocol that works like:

C: connect the call to the application server
S: OK

C: listen for # (alternately, "listen for digits")
S: OK

... time passes ...

S: # found
C: OK

C: Stop prompt
S: OK

C: Play new prompt
S: OK

C: Collect digits
S: OK

S: here are the digits
C: OK

Then I STRONGLY suggest H.248 or J.162.  They have exactly the above control model.

If you want:

C: listen for #
S: OK

... time passes... 

S: # found
C: OK

C: stop prompt
S: OK

C: play new prompt
S: OK

C: Collect digits
S: OK

S: here are the digits
C: OK

Then if you have to use SIP for digit detection, use KPML for the digit detection, and H.248 or J.162 for the prompting.  Alternately, to keep it all SIP, use the IVR namespace of MSCML. 

The best model in the applications and services environment is the following dialog:

C: listen for #. When you get a #, stop the current prompt, prompt for the new number, and tell me what you got
S: OK

... time passes ...

S: here is the new number
C: OK

This is SIP and VoiceXML.

> "maxrate" is an optional parameter defining a maximum number of
> NOTIFY transactions per minute initiated to report DTMF events.  The
> notifier MUST NOT exceed this limit in any one minute period, but MAY
> send notifications in more rapid bursts over shorter periods.  If
> "maxrate" is omitted, the notifier MUST limit reporting to forty (40)
> NOTIFY transactions per minute.  "maxrate" SHOULD NOT exceed 60. 

Why offer this if the application server shouldn't use it?  Again, the default maxrate issues notifications FASTER than the packet time of the codec.  That is a less than optimal use of bandwidth.

>  
> If the reporting rate limit causes a queue of unreported events to
> build up, the notifier MAY discard some or all of the excess events. 
> If the notifier can choose which events to discard, the notifier
> SHOULD discard notifications of uncompleted DTMF events resulting
> from the presence of the "duration" parameter before discarding
> notifications of completed DTMF events.'
>  
> 4. Hex codes don't really fit into the SIP gestalt.  Why not encode
> the information in a straightforward manner?  One cannot argue for
> compactness -- if one is going to live with 600+ bytes of SIP headers
> (see the example in the document), one can have a 35-byte text
> message that means something instead of a 12-byte "binary" message
> that is indecipherable.
>  
> Comment:JAZ 
> As the event package is intended to carry dtmf digits and as they are
> transparent to SIP processing, we believe that the defined event
> package is consistent with normal IETF style.

I fail to see how there can be ANY argument for a pseudo-binary payload.

>   
> Things I am open to: 
> 1. Volume: Does anyone need this?  What for?  How would you know? 
> What would you do with it?  Not for falsing detection: that is what
> the detection device should be doing.  If there is a good use case, I
> could see implementing it.  Then again, what do you do for RFC2833
> digit detection (no volume)?
>  
> Comment JAZ 

Let me ask again:  What on earth would you USE this FOR?

> First, the SUBSCRIBER here only specifies its own ability to process
> NOTIFY requests.  Using this as a network-saving device isn't going
> to work: how does the subscriber have any idea what to set this to? 
> Second, the default maxrate is one message every 16ms, or faster than
> G.711.  What could this be possibly useful for? 
> Third (and the big one), the whole point of transporting digits in
> the signaling path is because the digits *are* signaling.  Said
> differently, the application needs reliable delivery of signaling
> (digits).  If the use case for this package allows unreliable
> delivery, then I would be very interested in understanding why one is
> not using RFC2833, which has EVERYTHING discussed in this draft,
> available today?
>  
> Comment JAZ 
> monitoring.  The subscriber is typically using a PTSN phone to
> originate calls and subsequent in band dtmf tones.  Maxrate provides
> additional security against people who do insist upon holding down a
> DTMF digit when the carrier has set the duration parameter to a short
> duration.

Permit me a quick review on client-server terminology.  In the proposed protocol, the server is the PSTN gateway.  The client is the Application Server (far end).  Thus when I said that in your proposal the client does not need reliable delivery, I am referring to the far end.  This has absolutely nothing to do with the PSTN nature of the gateway.

Moreover, emitting a device-level notification ("is the key still pressed") instead of an application-level notification ("the key is pressed") highlights the evil of putting device control semantics on an application protocol.  In this case, it results in sending lots of notifications.  Again, if you care about low-level signal information, use RFC2833.

> implementing this feature. 

Compact:  No, order of magnitude greater than RFC2833.  No, on the order of KPML.

Simple: Simple minded, yes; simple to implement, possibly; simple to operate, NO.

> In summary, based on your comments, I do not see any technical issues
> with the proposed event package. 

Please re-read the first response, embellished with these responses.  There are many technical issues.  The maxrate / multiple notifications for a single key press is harmful to the Internet.  That is a major technical issue with the proposal. 

> that the event package can be registered with IANA in a timely

I am sorry I didn't get to this response sooner.

> Again I would like to thank you for taking the time to comment on

You are welcome.  Although it may sound like I thought the proposal was less than ideal, there were a few aspects (noted above) that are valuable.  Moreover, if there are cogent use cases for things like duration or volume, we should put that into KPML.

Please keep the dialog open and update us if there are more, real, requirements.