Subject: RE: [SIP] SIP Application Server

From: "Farahmand, Fardad" <[email-masked]>
Date: Thu, 1 Jun 2000 11:20:40 -0400

Neil,

In the ISC model, the role of the SoftSwitch is to present a single
protocol/interface by which an AppServer can participate in servicing the
call and controlling various legs of a call.  While the communication
between the AppServer and the SoftSwitch is proposed to be SIP, the actual
endpoints can use various protocols including PSTN and IP based (and
possibly none of them are SIP endpoints). This separates the task of the
service logic from details of network and protocols, presenting a single SIP
interface between the two.

Considering just the interface between the AppServer and the SoftSwitch, the
AppServer can act as a redirect server for applications such as LNP and 800
translation.  It can act as a proxy server for applications such as calling
card. And it can participate as a UAS in applications such as voicemail.  As
Jonathan mentioned,  it is the complexity and functionality of the actual
application which determines the role of the AppServer in its communication
with the SoftSwitch.

Fardad Farahmand
[email-masked]

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 6:23 AM
> To: Jonathan Rosenberg
> Cc: Scott Hoffpauir; [email-masked]
> Subject: Re: [SIP] SIP Application Server
> 
> 
> Jonathan Rosenberg wrote:
> 
> > Neil Deason wrote:
> > >
> > > Jonathan I agree that a service logic enhanced Proxy 
> Server is an application server.
> > >
> > > However, I am not yet convinced this sits in complete 
> harmony with the ISC App WG's
> > > intention to separate the call signalling 
> (Proxy/Softswitch) and service control (App
> > > Server) and use standard RFC2543 SIP as the interface 
> between them. In the case of
> > > the service logic enhanced proxy isn't the interface 
> between vanilla proxy and the
> > > service control defined by CPL/SIP-CGI/Servlet API etc 
> not RFC2543 SIP.
> >
> > No; the "vanilla proxy" speaks SIP to the application 
> server, which is
> > just a smarter proxy (or redirect server or whatever). This 
> app server,
> > internally, may use any number of APIs, including the ones 
> you mention.
> 
> Yes of course a separate SIP network element can talk SIP to 
> a smart proxy/application
> server. But the point I was trying to make is that the 
> application server encapsulates a
> vanilla proxy server, i.e. the proxy functionality as 
> described by rfc2543, plus service
> logic accessed through CPL/SIP-CGI/Servlet API/whatever. My 
> difficulty is in seeing how
> this fits with the ISC application working group premise of 
> separating call signalling from
> service control via a SIP messaging interface. This seems 
> like an unnecessary IN model of
> separation. In the App Server the proxy part does signalling 
> but it is clearly not
> separated from controlling service logic by a SIP messaging interface.
> 
> Neil.
> --
> Ubiquity Software Corporation, UK           http://www.ubiquity.net
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Culpepper, Bert" <[email-masked]>
Date: Sat, 3 Jun 2000 10:23:05 -0500

I'll confirm the suspicion that (some) people do want to deploy "older"
services in a Softswitch/SIP network.  As I've seen and heard many times,
the IP network provides a very attractive (cost-wise) alternative to the
circuit-switched/IN network for carrying telecommunications traffic.  I like
the ISC's goal hosting applications on a separate server from the
Softswitch.  And using SIP as the protocol between these two devices makes
creating and deploying new services easy compared to doing the same thing in
the PSTN.

However, the standards work needed to extend SIP to support deploying
existing PSTN-like services in an IP network (and to "seamlessly" integrate
the PSTN & IP networks) still has a way to go.  Specifically, carrying DTMF
out-of-band and within SIP.  I'm aware of two specific drafts proposing
methods but have not seen nor found any discussion or consensus within the
SIP WG.  Hopefully, interest in this issue will occur at some point.

Regards,
Bert

Bert Culpepper
InterVoice-Brite, Inc.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, June 02, 2000 9:35 AM
> To: Neil Deason
> Cc: [email-masked]
> > > I think you are over-analyzing the meaning of separation of
> > > call-signaling from service control. In reality, all services are
> > > delivered eventually through signaling, and are based on information
> > > provided by signaling. Thus, service logic is quite connected to call
> > > signaling, and embedding a vanilla proxy in an app server is quite a
> > > good way to access it. I would argue this is quite contrary to the IN
> > > model, in which there is an attempt to use a separate protocol for
> > > service control to a separate box. Note however that these protocols
> > > carry much the same information as the signaling protocols themselves.
> > 
> > Agreed. It was not my analysis that SIP should be used to try and
> > separate out service control
> > from call control. However, as was pointed out earlier in this
> > thread this could be achieved if
> > SIP is used to separate a non-SIP signalling protocol from service
> > logic in a 'Softswitch'
> > network. But then it appears that you would have a separate protocol
> > (SIP) for service control to
> > a separate box (App Server). Such separation doesn't really apply in
> > the same way to the SIP part
> > of the network and it sounds a lot like the Softswitch network is a
> > SIP network at the core.
> > There you find SIP conversant App Servers and around them are SIP
> > Proxy Servers, SIP Redirect
> > Servers and SIP User Agents. Some of these UAs may in fact represent
> > interfaces to PSTN or even
> > H.323 gateways. Though how do protocols that don't use SIP for
> > signalling deliver all the rich
> > new services that SIP enables when, for example, a text/html payload
> > gets discarded at the
> > SIP/foo gateway. The point of SIP is surely not to create LNP, 800
> > translation services in an App
> > Server for protocols such as SS7, H.323 etc Yes, you could recreate
> > the IN this way but why not
> > start out intending to build something better. You achieve this by
> > building Application Servers
> > that empower the simple creation of innovative services not
> > Application Servers that merely
> > recreate old services.
> 
> I couldn't agree more with this sentiment.
> 
> That said, I have a sneaking suspicion that people will still want to
> build these older services. Fortunately, most are supported by SIP,
> and
> can easily be built ontop of an applications server as well. These
> services (things like LNP and freephone) will work for H.323 devices,
> PSTN phones or ISDN phones accessing the SIP network through a gateway
> or softswitch. Even better, SIPs capabilities for negotiating
> extensions, content, methods, and so on, will often allow an app
> server
> to know if the accessing device can support a more innovative service.
> In the example you give, where the app server returns HTML to a
> softswitch, the app server can know apriori that HTML is or isn't
> supported (Accept: text/html in the INVITE). It could then do
> something
> different with the request for non-html access devices, like forward
> it
> to a media server running TTS or something, and read out the web page.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
>

---

From: "Farahmand, Fardad" <[email-masked]>
Date: Mon, 5 Jun 2000 10:35:54 -0400

I agree. There is no question that it will be the potential and ease of
creating and deploying new services that will be needed to initiate the mass
migration to the next generation network.  I find it hard to believe that
there would be folks that don't think this way.

However, I do believe that for a long time to come, the new network must
support integration with existing device, service functionality and network
infrastructure. You can think of this as the bridge that will bring about
the migration. As Jonathan mentioned, the strategy in application
development can be to provide as many features as a particular device is
capable of handling.  The SoftSwitch with its SIP interface can provide
network transparency where it is needed.  

Fardad Farahmand
[email-masked]

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Friday, June 02, 2000 8:43 PM
> To: Jonathan Rosenberg; Neil Deason
> Subject: RE: [SIP] SIP Application Server
> 
> 
> I fully agree with Jonathan. The whole point is not just to
> replicate what can be already done with AIN/PSTN, but for new
> services that produce new revenue.
> 
> Henry
> 
> Henry Sinnreich
> MCI WorldCom
> 400 International Parkway
> Richardson, Texas 75081
> USA
> 
> >From: [email-masked]
> >[mailto:[email-masked]]On Behalf Of
> >Jonathan Rosenberg
> >Sent: Friday, June 02, 2000 8:35 AM
> >To: Neil Deason
> >> Agreed. It was not my analysis that SIP should be
> >used to try and separate out service control
> >> from call control. However, as was pointed out
> >earlier in this thread this could be achieved if
> >> SIP is used to separate a non-SIP signalling
> >protocol from service logic in a 'Softswitch'
> >> network. But then it appears that you would have a
> >separate protocol (SIP) for service control to
> >> a separate box (App Server). Such separation doesn't
> >really apply in the same way to the SIP part
> >> of the network and it sounds a lot like the
> >Softswitch network is a SIP network at the core.
> >> There you find SIP conversant App Servers and around
> >them are SIP Proxy Servers, SIP Redirect
> >> Servers and SIP User Agents. Some of these UAs may
> >in fact represent interfaces to PSTN or even
> >> H.323 gateways. Though how do protocols that don't
> >use SIP for signalling deliver all the rich
> >> new services that SIP enables when, for example, a
> >text/html payload gets discarded at the
> >> SIP/foo gateway. The point of SIP is surely not to
> >create LNP, 800 translation services in an App
> >> Server for protocols such as SS7, H.323 etc Yes, you
> >could recreate the IN this way but why not
> >> start out intending to build something better. You
> >achieve this by building Application Servers
> >> that empower the simple creation of innovative
> >services not Application Servers that merely
> >> recreate old services.
> >
> >build these older services. Fortunately, most are
> >supported by SIP, and
> >extensions, content, methods, and so on, will often
> >allow an app server
> >supported (Accept: text/html in the INVITE). It could
> >then do something
> >different with the request for non-html access
> >devices, like forward it

---

From: "Gardell, Steve" <[email-masked]>
Date: Wed, 7 Jun 2000 08:13:58 -0400

An alternative model is that all proxy/redirect
servers in a network are "application" servers in 
the sense that they have an application programming
interface. Some of these, say stage 1, application 
servers are specialized for providing "no application 
needed" services and for routing to the application
servers that house applications. The stage 1 & stage 2 
"applications" might then access a common 
(possibly dynamic) data store via mechanisms outside 
the scope of IETF protocol discussions.

This works if the stage 1 & 2 servers are operated
by the same service provider (and provided by the
same vendor?). Probably simpler and more efficient 
than involving another protocol in those common
cases, but is it a generally enough solution?

Steven Gardell
GTE Laboratories
Voice: 781-466-2681, Fax: 781-466-3375

> Sent: Tuesday, June 06, 2000 1:21 AM
> To: Postmann Erwin
> Subject: Re: AW: [SIP] SIP Application Server
> 
> 
> 
> 
> Postmann Erwin wrote:
> > 
> > I have followed the discussion on the SIP application 
> server with big
> > interest. My understanding of the application server is 
> that it is a more
> > complex SIP proxy, redirect server or user agent which 
> provides applications
> > and services to the users.
> > Is my understanding right?
> 
> Yes.
> 
> > 
> > I have the following questions for my clarification:
> > 
> > How can I ensure that the application server is always in 
> the route of my
> > SIP requests?,
> > Have to registered at the application server or is it 
> enough to use the
> > route header in my requests (e.g. INVITE)?
> 
> Excellent question.
> 
> There is no easy answer. The problem is that "service triggers" can be
> fairly complex. It is not as simple as checking the request URI of a
> request, and sending it to an application server if that user has some
> services enabled. Some services are provisioned for any user (such as
> administrator services). Some services are triggered based on the From
> or To field. Some services are triggered based on domain names in the
> request URI rather than on the complete URI. Even more complicated is
> the fact that service triggers can be extremely dynamic; a particular
> service may require installation of triggers for a wide range of
> different requests.
> 
> So, how does one do this? One way is to simply route 
> everything to your
> applications server, and let it decide what to do. Another way is to
> assume that this information exists in some database, and use a query
> protocol to fetch it, or use a replication protocol to distribute it.
> Taking a step back, you can argue that this is just a more 
> complex form
> of routing (remember I made the statement that the beauty of using SIP
> for service invocation is that feature selection looks like a routing
> problem). So, what we are talking about is distribution of 
> very complex
> routing tables between proxies. So, how does one do route distribution
> in SIP? Many ways, but a colleague suggested to me once that 
> the closest
> thing may well be TRIP. One can envision extending TRIP to 
> cover a wider
> range of information for describing the routes. Now, TRIP isn't ideal,
> since its really engineered for inter-domain operation, and supporting
> distribution of multidimensional routing criteria will 
> destroy any hope
> of aggregation, which TRIP spends a lot of time on. But, we have
> realized the value of TRIP for intra-domain exchange of 
> routes between a
> gateway and a TRIP speaker
> (http://search.ietf.org/internet-drafts/draft-rs-trip-gw-00.tx
t), and I
think much of the arguments about why it makes sense there, may also
apply here. I'm not proposing this, but I think its worth further
consideration. 

-Jonathan R.