Subject: AW: [SIP] SIP Application Server

From: Postmann Erwin <[email-masked]>
Date: Tue, 6 Jun 2000 06:54:38 +0200

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?

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)?

If I want to use more then one application server (with different services)
in parallel how can I instruct the proxy/client to select the appropriate
one (e.g. based, called party, the time, day, location, etc.)? Has this
selection to be done at the client or could I have some intelligence stored
in the network?

Best regards

Erwin Postmann
SIEMENS AG Austria
Program and System Engineering
Mobile Networks Solutions - Product Marketing 

Autokaderstrasse 29
A-1210 Vienna

Tel:	+43.5.1707.21398
Fax:	+43.5.1707.51924
GSM:	+43.664.1010034
email:	[email-masked] 

-----Ursprüngliche Nachricht-----
Von: Neil Deason [mailto:[email-masked]]
Gesendet am: Freitag, 02. Juni 2000 10:20
An: Jonathan Rosenberg
Cc: [email-masked]
Betreff: Re: [SIP] SIP Application Server

Jonathan Rosenberg wrote:

> Neil Deason wrote:
> >
> > 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.
>
> 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.

Regards,
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Jun 2000 01:21:03 -0400

> Is my understanding right?

Yes.

> 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.txt), 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.

-- 
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: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Jun 2000 09:25:28 -0500

Jonathan Rosenberg wrote:
> 
> 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.

I have followed this thread with some interest as well.  However, IMHO,
we need to delineate an application server from a proxy server clearly.
There are functions an application server can do that a proxy MUST not.
One case I can think of is that of third party call control where some 
network entity, based on some application logic, asynchronously creates 
both legs of a call.  Clearly, a proxy MUST not do this since a proxy
MUST not create INVITE requests on its own. 

Regards,

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
IN Architecture and Internet Software Group
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184