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

From: "Eric Burger" <[email-masked]>
Date: Wed, 29 Oct 2003 22:02:37 -0500

The KPML update is in the archives; I just haven't seen the announcement:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-01.txt

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.

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.

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!

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.

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)?

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?

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

_______________________________________________
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: "Joe Zebarth" <[email-masked]>
Date: Tue, 28 Oct 2003 09:05:21 -0500

Colleagues

The T1 prepublished document can be found at:

http://www.t1.org/filemgr/filesearch.taf?_function=detail&T1_Files_uid1=3S17
0632

Note that the zip file is 251 k and the uncompressed is 1.4 M

Kindest regards,

Joe Zebarth
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: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, October 28, 2003 2:27 AM
To: [email-masked]
Cc: Zebarth, Joe [CAR:1A12:EXCH]
Subject: 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:

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?

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

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 30 Oct 2003 22:34:28 -0500

Thanks for the posting.

Reviewing the document, I think the T1 community may be better served by KPML.  It handles the long # issue, as well as directly handles the #9# example given.  Moreover, it is a general solution, while the T1 suggestion does not really work even for the pre-paid scenario (the NOTIFY flooding and ignoring expires on SUBSCRIBE).

-----Original Message-----
From: Joe Zebarth [mailto:[email-masked]]
Sent: Tue, October 28, 2003 9:05 AM
To: [email-masked]
Cc: Dean Willis
Subject: [Sipping] RE: Please Read Committee T1 Draft on DTMF Notification

Colleagues 
The T1 prepublished document can be found at: 
http://www.t1.org/filemgr/filesearch.taf?_function=detail&T1_Files_uid1=3S170632 
Note that the zip file is 251 k and the uncompressed is 1.4 M 
Kindest regards, 
Joe Zebarth 
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