Subject: [Sipping] Comments on updated KPML draft

From: Bert Culpepper <[email-masked]>
Date: Sat, 08 Mar 2003 19:17:13 -0500

A few issues came to mind on my reading of the revised KPML I-D.

Section 2 - Overview

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.

If a goal of KPML is to satisfy the requirements defined in Application 
Interaction Requirements I-D, then an attribute is needed to indicate 
suppression of reporting indications by any other means.  A default (if 
not present) for this attribute could result in DTMF being sent as 
described.

Section 4 - SIP Reporting

It's stated that the NOTIFY is sent to the Contact contained in an 
INVITE.  How does this support SIP proxy-based applications? 
draft-jennings-sip-app-info-00 allows proxies to add, delete, and read 
App-Info header values.  Or is the use of the NOTIFY method to be 
limited to the endpoints of a SIP session, and any other entity must use 
HTTP?

Another issue is that it's stated that a KPML session ends when a NOTIFY 
is sent, and further KPML sessions must be established with a reINVITE. 
  Why not allow a KPML document in the body of the 200 OK response to 
the NOTIFY as specified similarly for HTTP reporting?  This saves three 
messages between the application and user device.

According to RFC 3265, NOTIFY requests MUST contain an Event header. 
What would the value of this header be for KPML bodies?

Regards,
Bert

_______________________________________________
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: Bert Culpepper <[email-masked]>
Date: Mon, 10 Mar 2003 08:50:10 -0500

A qualification below...

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

 >  Why not allow a KPML document in the body of the 200 OK response to the
 > NOTIFY as specified similarly for HTTP reporting?  This saves three