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

From: "Joe Zebarth" <[email-masked]>
Date: Wed, 5 Nov 2003 21:27:37 -0500

Eric

Again I would like to thank you for taking the time to provide additional
comment.

While the KPML is an interesting approach and provides extended
capablilities it inherently is not a "simple and compact" solution for the
identified use scenario, as I understand it.  

	For the usage scenario discussed in the ID defining the event
package, the KPML solution is more processing intensive at the "Notifier"
while the proposed event package is more processing intensive at the
"Application Server".  Obviously each solution has its particular strengths.
However, as these strengths are use scenario dependent, it is felt that they
should be considered complementary, not competative, solutions.

T1S1 is populated with people who have dealt with protocol for many years.
It was based on their experience that this event package was developed for
this usage scenario.

I have provided in line comments below.

As per my previous message, again I do not see any technical issues with
this new event package based on your comments.  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.

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: Thursday, October 30, 2003 10:34 PM
To: Zebarth, Joe [CAR:1A12:EXCH]
Cc: [email-masked]
Subject: RE: [Sipping] RE: Please Read Committee T1 Draft on DTMF
Notification

Thanks for the posting.

Reviewing the document, I think the T1 community may be better served by
KPML.  

	Comment: JAZ

	See comments above. Each method has its strengths and should be
considered complementary, not competative solutions.

It handles the long # issue, 

	Comment: JAZ
	A methodology is provided to deal with the long # issue in the
defined event package.  Thus it is not a technical issue.

as well as directly handles the #9# example given.  

	Comment: JAZ

	The #9# is a timing issue, not a technical issue.

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

	Comment: JAZ

	In the usage scenario there need be no NOTIFY flooding occurences.  
	If the devices comply with the IETF version of SIP, the devices will
handle SUBSCRIBE correctly.  This event package was produced to foster
ongoing compliance with SIP by IP technology.  It is for this reason that
IANA registration of this event package is being sought.  
	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.

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