Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs a nd apps?

From: "Jain, Rajnish (Rajnish)" <[email-masked]>
Date: Wed, 8 Jan 2003 06:34:03 -0500

Eric,
Can you expand on why sending KPML w/in SUBSCRIBE is a bad idea? In other
words, why inling KPML w/in INVITE is fine but not w/in SUBSCRIBE. 

A SUBSCRIBE message w/ inline KPML should be oblivious to UA session FSM.
It's an orthogonal activity from UA's perspective. Upon receipt of a KPML
request (w/in SUBSCRIBE) the UA will attach a DSP for DTMF collecion and
report digits to app (via NOTIFY). This shouldn't change the state of SIP
session w/in UA.  

Rajnish

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 3:00 PM
To: Steve Fisher
Cc: [email-masked]
Subject: RE: [Sipping] Stimulus Signaling/Markup between complex SIP UAs
and apps?

To answer the question directly: 

KPML only works with HTTP reporting.  It would be a different language for SIP reporting.  MSCML is an example of a language that uses SIP for reporting.

To answer the SIP stimulus reporting question:

Done INFO in the past, not planning on it again :-)

NOTIFY is my leading contender, but a new method may be needed because if you do a strict reading of NOTIFY, you might not want a NOTIFY without a SUBSCRIBE.

Using SUBSCRIBE as a method of pushing KPML is out and out evil (I mean wrong).  KPML changes the state of the UAS.  SUBSCRIBE is not supposed to have any side-effects.

> -----Original Message-----
> From: Steve Fisher [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2003 8:15 AM
> To: Eric Burger
> Cc: [email-masked]
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Eric,
> 
> I've been thinking about your statement below...
> 
> > > If we say SIP for stimulus reporting, then the diagram you drew, 
> > > with the implication that the signaling follows the 
> signaling path, 
> > > is what will occur.
> > > 
> > > Is this distinction important for you?  The design team 
> did not come
> 
> > > to full agreement on which way to go.  Compelling 
> arguments either 
> > > way welcomed.
> 
> Could you possibly elaborate on how "SIP for stimulus reporting" would
> work? Are you thinking of SUBSCRIBE/NOTIFY? Are you thinking of using
> INFO? It's fairly clear from the KPML draft how HTTP would 
> work, but SIP
> was less clear to me...
> 
> Thanks!
> Steve
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eric Burger
> Sent: Tuesday, December 17, 2002 5:18 PM
> To: Don Stanwyck
> Cc: [email-masked]; Jain, Rajnish (Rajnish)
> Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> complex SIP UAs
> and apps?
> 
> 
> Rajnish is 1000% correct in his interpretation.  Looking at 
> the message
> I can see how my statement isn't entirely clear.
> 
> I am on record in this and other fora that H.248 and J.162 are the
> appropriate protocols for device control.  See my posts to 
> the speechsc
> list.  I should have a paste buffer with my "Don't use SIP 
> for low-level
> peripheral device control" rant.
> 
> When I said "It [the thing referenced as "softswitch" in Rajnish's
> e-mail -- ewb] is not a media gateway controller" I meant it was not a
> media gateway controller, e.g., a device control thing, which uses
> device control protocols like H.248 and J.162.
> 
> Now it's my turn for interpreting Rajnish, instead of him interpreting
> me :-)  I assumed that the "PSTN X" thing was a MG-MGC combination,
> speaking SIP on the packet network side.  E.g., the MG-MGC 
> interface was
> a private matter, not of interest to the discussion.
> 
> Sorry for the confusion.
> 
> > -----Original Message-----
> > From: Jain, Rajnish (Rajnish) [mailto:[email-masked]]
> > Sent: Tuesday, December 17, 2002 4:02 PM
> > To: 'Don Stanwyck'; Eric Burger; Jain, Rajnish (Rajnish)
> > Cc: [email-masked]; Twomey, Michael S (Michael)
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > Don,
> > I don't think Eric implied controlling a MG from a Softswitch
> > via SIP in his
> > comment. That particular topic has come up in this forum many 
> > times and as I 
> > recall the conclusion has always been that SIP is not meant 
> > for that. SIP is 
> > a peer-to-peer to protocol not a master-slave protcol - 
> > agreed. However this
> > is completely orthogonal to using stimulus/markup signaling 
> > in SIP.  I don't
> > see how in-lining a KPML doc (e.g.) in a SIP message breaks 
> > SIP paradigm. 
> > 
> > Eric,
> > In general, I would like to propose an HTTP-free alternative
> > for delivery of 
> > stimulus signals, such as through in-lining of KPML. The 
> > benefits of such an
> > alternative in my mind are following:
> > 
> > - it would make it easier for SIP developers on embedded
> > platforms to embrace 
> >   markup/stimulus signaling that don't support HTTP currently
> > 
> > - it would facilitate close coordination between announcement
> > play and DTMF
> >   collection. Barge-in is a good example for that. The app 
> > can delegate the  
> >   job to stop announcement play at barge-in to the 
> > Softswitch. As an aside,
> >   the Softswitch in my previous figure is one w/ bizarre API 
> > as you say :-)
> > 
> > Rajnish
> > 
> > -----Original Message-----
> > From: Don Stanwyck [mailto:[email-masked]]
> > Sent: Tuesday, December 17, 2002 3:10 PM
> > To: 'Eric Burger'; 'Jain, Rajnish (Rajnish)'
> > Cc: [email-masked]; 'Twomey, Michael S (Michael)'
> > Subject: RE: [Sipping] Stimulus Signaling/Markup between
> > complex SIP UAs
> > and apps?
> > 
> > 
> > RFC 3261, Section 2 reads:
> > 
> > //START QUOTE
> > 
> > SIP supports five facets of establishing and terminating
> > multimedia communications:
> >   - User location: determination of the end system to be
> >     used for communication;
> >   - User availability: determination of the willingness
> >     of the called party to engage in communications;
> >   - User capabilities: determination of the media and media
> >     parameters to be used;
> >   - Session setup: "ringing", establishment of session
> >     parameters at both called and calling party;
> >   - Session management: including transfer and termination
> >     of sessions, modifying session parameters, and invoking
> >     services.
> > 
> > SIP is not a vertically integrated communications system.
> > SIP is rather
> > a component that can be used with other IETF protocols to build a
> > complete multimedia architecture.  Typically, these 
> architectures will
> > include protocols such as the Real-time Transport Protocol 
> (RTP) (RFC
> > 1889 [28]) for transporting real-time data and providing 
> QoS feedback,
> > the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for 
> > controlling
> > delivery of streaming media, the Media Gateway Control 
> > Protocol (MEGACO)
> > (RFC 3015 [30]) for controlling gateways to the Public Switched
> > Telephone Network (PSTN), and the Session Description Protocol (SDP)
> > (RFC 2327 [1]) for describing multimedia sessions.  Therefore, SIP
> > should be used in conjunction with other protocols in order 
> to provide
> > complete services to the users.  However, the basic 
> functionality and
> > operation of SIP does not depend on any of these protocols.
> > 
> > //END QUOTE
> > 
> > I can't find any support in this definition of SIP for
> > carrying stimulus
> > signaling or for controling media gateways (comment 1 in Eric's
> > comments).  SIP, as defined and approved by the IETF, is not 
> > expected to
> > do these kinds of things that other IETF protocols are designed to
> > handle.
> > 
> > Let's try to keep SIP doing the things it is designed to do 
> and does 
> > well, and not try to make it into a protocol for doing everything 
> > imaginable.  It is already in danger of becoming too difficult to 
> > implement as the number of options and new headers grows.
> > 
> > Don Stanwyck
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf Of Eric Burger
> > > Sent: Tuesday, December 17, 2002 12:12 PM
> > > To: Jain, Rajnish (Rajnish)
> > > Cc: [email-masked]; Twomey, Michael S (Michael)
> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between 
> > > complex SIP UAs and apps?
> > > 
> > > 
> > > For timelines, I would suggest asking the work group chairs.
> > > We're at their mercy :-)
> > > 
> > > Putting my ISC hat on, what is the Softswitch in your diagram?
> > >   1. It is not a media gateway controller, as it talks to
> > >      the gateway with SIP (right answer, by the way).
> > >   2. Is it a Stateless Proxy, a'la the Routing Function
> > >      in the ISC reference diagram?  If so, that works
> > >      exactly as you want it to.  See below for more.
> > >   3. Is it an application server, a'la dynamicsoft,
> > >      Ubiquity, LongBoard, etc.?  If so, that also works
> > >      exactly as you want it to.  See below for more.
> > >   4. Is it some kind of statefull proxy, with a bizarre,
> > >      proprietary API to the pre-paid application (e.g., 
> > >      Parlay, JAIN, EXS, ...)?  If so, you are on your
> > >      own.
> > > 
> > > If we say "HTTP only" for stimulus reporting, the PSTN
> > > gateway must be a HTTP client.  The good news is the gateway 
> > > can communicate directly with the pre-paid application.  That 
> > > also means the pre-paid application needs to have a HTTP 
> > > server.  Alternatively, if the "Softswitch" is really a 
> > > telephony application server (case #3 above), then it 
> > > probably already has HTTP server capability built-in.
> > > 
> > > If we say SIP for stimulus reporting, then the diagram you
> > > drew, with the implication that the signaling follows the 
> > > signaling path, is what will occur.
> > > 
> > > Is this distinction important for you?  The design team did
> > > not come to full agreement on which way to go.  Compelling 
> > > arguments either way welcomed.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jain, Rajnish (Rajnish) [mailto:[email-masked]]
> > > > Sent: Friday, December 06, 2002 4:20 PM
> > > > To: Eric Burger; Jain, Rajnish (Rajnish)
> > > > Cc: [email-masked]; Twomey, Michael S (Michael)
> > > > Subject: RE: [Sipping] Stimulus Signaling/Markup 
> between complex 
> > > > SIP UAs and apps?
> > > > 
> > > > 
> > > > Eric,
> > > > 
> > > > Thanks for your response. Would you be able to comment on the 
> > > > timeline of when does the design team hope to accomplish the
> > > > following:
> > > > 
> > > > - general acceptance of the stimulus signaling, KPML etc.
> > > > - standardization of app interaction fwk, KPML into an RFC
> > > > 
> > > > Regarding an example of a PSTN switch that can be 
> connected to a 
> > > > pre-paid app over SIP-T, I don't know how much I can 
> disclose in 
> > > > front of this forum, but that is something being looked at by a 
> > > > few telecom gear vendors in my understanding.
> > > > 
> > > > I wanted to bring your attention to SIP-T wrt to my
> > > previous question.
> > > > I believe your answer will remain the same but I just to
> > wanted to
> > > > re-iterate the question in different words this time,
> > just to make
> > > > sure we're communicating:
> > > > 
> > > > In the setup below:
> > > >                                Pre-paid app
> > > >                                    |
> > > > POTS ---- PSTN X <---SIP-T---> Softswitch ----
> > > >                                
> > > >     
> > > > .. you would think, application interaction framework concepts 
> > > > such as stimulus signaling, user-inetrfaces and KPML etc. are 
> > > > designed to work over the SIP-T i/f between packet-enabled PSTN 
> > > > switch and a Softswitch. Wouldn't you?
> > > > 
> > > > Thanks,
> > > > Rajnish
> > > > 
> > > > > -----Original Message----- From: Jain, Rajnish (Rajnish)
> > > [mailto:[email-masked]]
> > > > 
> > > > The Application Interaction Framework draft talks about stimulus
> > > > signaling as a way for SIP UAs to interact w/ SIP 
> > applications. The
> > > > draft suggests use of markup languages to allow
> > > applications to manage
> > > > local/remote user interfaces on SIP UAs.
> > > > 
> > > > While the draft exemplifies a UA's stimulus/markup 
> interaction w/ 
> > > > a pre-paid application server, it is not very clear to 
> us if the 
> > > > caller UA (instead of a subscriber end-point) can be a 
> complex UA 
> > > > such as the following:
> > > > 
> > > > - SIP (enabled) Gateway
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > - PSTN Switch w/ SIP-T interface
> > > 
> > > Why not?  It does SIP.  It may do tone detection.
> > > 
> > > > and does the draft recommend stimulus/markup signaling between 
> > > > such complex/concentrated UAs (or apps) and SIP applications ?
> > > 
> > > The draft is silent on it.  If you manufacture media rich
> > > gateways, you might say "of course".  If you manufacture 
> > > media servers, you might say "you could if you wanted, but 
> > > you would be better served if you didn't."  :-)
> > > 
> > > > In other words, does the stimulus signaling apply to following
> > > > scenarios ?:
> > > > 
> > > > 1. The pre-paid caller is connected to a PSTN switch that has a 
> > > > SIP-T interface to the pre-paid application.
> > > 
> > > Yes, so long as the PSTN switch is SIP-aware, able to parse
> > > and execute KPML, and report using SIP (or, yuck, http).
> > > 
> > > Do you know of such a switch?
> > >  
> > > > 2. The pre-paid caller is connected to a PBX (SIP 
> Gateway) over an
> 
> > > > ISDN i/f, which in turn is connected to the pre-paid app. over 
> > > > normal SIP.
> > > 
> > > Same issues as for the PSTN switch.
> > > 
> > > > If yes, would the terms client-local and client-remote still be
> > > > accurate, as the user here is a POTS/ISDN user? From the user's 
> > > > perspective, the UI would be client-remote. But from 
> > application's
> > > > perspective the UI would be client-local (as the UI will be
> > > on the PBX
> > > > or PSTN switch both of which look like a UA to app server).
> > > 
> > > It is still client-local, as the gateway/switch/PBX is a
> > > local proxy for the user.  If you used a media server in the 
> > > IP network behind the gateway/switch/PBX to execute the KPML, 
> > > then you would be cline-remote. 
> > > _______________________________________________
> > > 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
> > > 
> > 
> _______________________________________________
> 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
> 
> 
_______________________________________________
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
_______________________________________________
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: "Jain, Rajnish (Rajnish)" <[email-masked]>
Date: Mon, 20 Jan 2003 18:10:14 -0500

Steve, Eric,
I just wanted to add that,  I second Steve's proposal wrt using 
SIP NOTIFY (w/ KPML inline) instead of HTTP POST for DTMF digit 
reporting.

Rajnish

-----Original Message-----
From: Steve Fisher [mailto:[email-masked]]
Sent: Sunday, January 19, 2003 1:41 PM
To: 'Eric Burger'
Cc: [email-masked]
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