RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?

["Eric Burger" <[e-mail]>]

KPML and MSCML will be revved within 2 weeks.
 
In-line delivery of KPML is already covered in draft-jennings-sipping-app-info (the cid: scheme).
 
In-line delivery of MSCML is already covered in draft-vandyke-mscml.

	-----Original Message----- 
	From: Steve Fisher [mailto:[e-mail]] 
	Sent: Tue 1/21/2003 8:21 AM 
	To: Eric Burger 
	Cc: [e-mail] 
	Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs and apps?
	
	

	Eric,
	
	Thanks for the quick reply. Does the design team intend to create new
	versions of draft-burger-sipping-kpml-00 and
	draft-jennings-sip-app-info-00 to reflect "inline" KPML and the use of
	NOTIFY instead of HTTP?
	
	Also, do you plan on issuing a new version of the MSCML draft?
	
	Thanks!
	Steve
	
	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]] On Behalf
	Of Eric Burger
	Sent: Monday, January 20, 2003 10:10 PM
	To: Steve Fisher
	Cc: [e-mail]
	Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
	and apps?
	
	
	I fully agree on items 1 & 2 in your message, as it is the direction
	MSCML is going (NOTIFY for INFO).
	
	On item 3, I'm personally not that fond of the idea of an application
	doing per-digit collection.  This is more especially so if the
	application server is doing timing related activities.  Remember, SIP
	does not have timely delivery.  For that matter, in a wireless network,
	you are virtually guaranteed to have SLOW signaling (as you will be
	traversing at least two proxies, probably more in reality).
	
	I would offer three possible directions to go:
	
	A. Use H.248:
	If you really want to manage digit detectors and get per-digit
	notifications, treat the gateway as a device.  My guess is that you will
	find (1) you will use digit maps and (2) you can't do it, because two
	devices cannot control the same resources in H.248.
	
	B. Send RFC2833 events to the application:
	If the application wants digit events with timing, then it should get an
	RFC2833 stream.  That may be easier for a cheap device to do than for it
	to have a KPML interpreter.  This does constitute a "send everything"
	policy, however.  On the other hand, once one goes down the road of
	sending digit masks (or maps), you might as well go all the way (see C,
	below).
	
	C. Use markup:
	There is an area of "It is, or it isn't."  Either a device will be able
	to interpret KPML (which doesn't even really need DOM or SAX) or it
	won't.  At some point one has to say that the device is "too stupid."
	That is, it isn't worth trying to run stuff on it.
	
	> -----Original Message-----
	> From: Steve Fisher [mailto:[e-mail]]
	> Sent: Sunday, January 19, 2003 1:41 PM
	> To: Eric Burger
	> Cc: [e-mail]
	> Subject: RE: [Sipping] Stimulus Signaling/Markup between
	> complex SIP UAs
	> and apps?
	>
	>
	> Eric,
	>
	> I've been meeting with several colleagues over the past few weeks
	> discussing KPML and we had some comments and questions that we thought
	
	> we'd pass on:
	>
	> 1) We very much prefer the use of SIP NOTIFY, instead of
	> HTTP, to notify
	> application servers when a UA has detected the specified key presses.
	> Given that all entities, and the network infrastructure that connects
	> them, are already SIP-capable, it would be much simpler to have the
	> notification also be over SIP. Further, it seems to us that this would
	> be an appropriate use of the NOTIFY method, and thus would not be
	> abusing SIP simply for convenience.
	>
	> 2) It seems to us that the "subscription" could be established as part
	
	> of the session setup process (and not via a SUBSCRIBE, for the reasons
	
	> you indicated). This also seems to us to be a reasonable use of SIP,
	> since detecting key presses is one aspect of the session. We
	> envisioned that this would occur along the lines of what's described
	> in draft-jennings-sip-app-info-00, although the KPML would be
	> "inlined", rather than fetched via HTTP.
	>
	> 3) The other area of debate that we had concerned the
	> appropriate place
	> to put the logic for managing the "digit maps". In the KPML draft, you
	> wrote:
	>
	>       An interested application could request notifications of every
	key
	>       press.  However, many of the use cases for such signaling has
	> the
	>       application interested in only one or a few keystrokes.  Thus we
	>
	>       need a mechanism for specifying to the user device what stimulus
	the
	>       application would like notification of.
	>
	> Our concern is that the specific mechanism defined in KPML will impose
	
	> significant requirements on the KPML interpreters, which will
	> frequently be either inexpensive devices, or will be PSTN gateways
	> that are optimized for media processing at scale, and not for the type
	
	> of processing required by KPML. We were wondering if you are open to
	> an alternative approach, in which the application servers indicate to
	> the device which key presses they're interested in, but not the
	> ordering of
	> those digits, leaving it to the application servers to manage the
	> sequencing of the key presses (checking intervals, etc.). Thus, this
	> mechanism would not be as simple as "signal for all key presses", but
	> would not require that the devices maintain any state other than the
	> list of key presses and the name of the Application Server to NOTIFY
	> (i.e. no state machines, regular expression interpreters, etc.).
	>
	> What do you think?
	>
	> Steve Fisher
	> Division Manager
	> AT&T Labs
	>
	>
	> _______________________________________________
	> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	> This list is for NEW development of the application of SIP Use
	> [e-mail] for questions on current sip Use
	> [e-mail] 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 [e-mail] for questions on current sip Use
	[e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP