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

From: "Jain, Rajnish (Rajnish)" <[email-masked]>
Date: Fri, 6 Dec 2002 16:19:44 -0500

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

---

From: "Jain, Rajnish (Rajnish)" <[email-masked]>
Date: Tue, 17 Dec 2002 16:01:33 -0500

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,
> > 
> > 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
> >                                    |
> > 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.
> > 
> 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."  :-)
> 
> Yes, so long as the PSTN switch is SIP-aware, able to parse 
> and execute KPML, and report using SIP (or, yuck, http).
> 
> > 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. 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>