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

From: "Eric Burger" <[email-masked]>
Date: Tue, 17 Dec 2002 17:18:22 -0500

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

---

From: "Steve Fisher" <[email-masked]>
Date: Wed, 18 Dec 2002 07:50:14 -0500

Eric,

I've been thinking about your statement below...

> > arguments either way welcomed.

I assume that in the "SIP for stimulus reporting" model that the design
team has in mind, the KPML would be sent "inline" when the dialog is
established (as opposed to a URL to the KPML), and that the "reports"
would be sent as SIP INFO messages back up through the signaling path.
Is that correct? 

As an alternative, have you consider a mechanism that uses
SUBSCRIBE/NOTIFY, which appears (at least to me) to have been designed
more with this type of use in mind.

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.

> > > Subject: RE: [Sipping] Stimulus Signaling/Markup between complex 
> > > SIP UAs and apps?
> > > 
> > > 
> > > Eric,
> > > 
> > > 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.
> > > 
> > > .. 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
> > > 
> > > 1. The pre-paid caller is connected to a PSTN switch that has a 
> > > SIP-T interface to the pre-paid application.
> > 
> > > 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.
> > 
_______________________________________________
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