Subject: Re: [Sipping] SDP addressing in KPML

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 02:30:35 -0500

As it currently stands, the scope of the app interaction framework is 
to allow an element on the call path to monitor the keypad entries 
within that call. As a result, I would have to object to adding 
functionality into KPML for the purposes of allowing third party 
monitoring from devices based on session parameters.

Now, a real issue is how to handle the case where a single dialog has 
multiple media streams. The answer, I think, lies in the beginning 
sections of the app interaction framework, which try to clarify the 
difference between a user device and a user interface. In particular, 
once we have placed a user interface (in the form of a KPML script) 
onto the device, the device is now interacting directly with the user 
interface. THere are no media streams at all in that interface. Media 
streams only carry user input when the user interface is remote from 
the client, which is not the case here. As a result, any data entered 
by the user within the context of the dialog would be applicable to 
the KPML for that dialog. On a typical single line phone, all keypad 
entry applies to the current dialog. On a multi-line phone, presumably 
one has a way to select the line (i.e., dialog), and thus the line 
selection determines which dialog the keypresses are associated with.

Thus, I dont think we need to change anything in KPML, or add any 
SDP-level addressing. The framework probably needs to discuss this 
issue, however.

-Jonathan R.

Eric Burger wrote:

> The use case for the raw SDP addressing mode is for monitoring
> elements that are not aware of the mapping from SIP dialog to
> session parameters.
> 
> While this use is debatable (I'm willing to give it up), it is
> still useful, in conjunction with the SIP dialog addressing mode,
> to indicate which m-line needs monitoring.
> 
> Comments?
> 
> 
> _______________________________________________ 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: Thu, 13 Nov 2003 08:49:50 -0500

I agree with Jonathan, this is out of scope IMO.  In addition, this 
complicates what I've hoped would be a relatively simple mechanism for 
applications to receive user input associated with a SIP dialog. (At a 
minimum it complicates the specification defining the mechanism.)

Regards,
Bert

Jonathan Rosenberg wrote:

> As it currently stands, the scope of the app interaction framework is to 
> allow an element on the call path to monitor the keypad entries within 
> that call. As a result, I would have to object to adding functionality 
> into KPML for the purposes of allowing third party monitoring from 
> devices based on session parameters.
> 
> once we have placed a user interface (in the form of a KPML script) onto 
> the device, the device is now interacting directly with the user 
> streams only carry user input when the user interface is remote from the 
> client, which is not the case here. As a result, any data entered by the 
> user within the context of the dialog would be applicable to the KPML 
> for that dialog. On a typical single line phone, all keypad entry 
> applies to the current dialog. On a multi-line phone, presumably one has 
> a way to select the line (i.e., dialog), and thus the line selection 
> determines which dialog the keypresses are associated with.
>