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

["Steve Fisher" <[e-mail]>]

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