Subject: [SIP] SIP Application Server

From: Tricia Wang <[email-masked]>
Date: Fri, 26 May 2000 17:25:26 -0700

Hi, All

I am writing a design document for a SIP network

Is Application Server "a kind of" Proxy Server or Redirect Server or
Neither?
(Application Server will provide some services)

Thank you so much

Tricia

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

---

From: [email-masked]
Date: Sat, 27 May 2000 10:28:55 +0530

My understanding of an 'Application Server' is that it is a logical entity,
that provides services to network entities. What services depends on what
Applications are executing in this App. Server and what entity is being
interfaced with.

If you now talk about the SIP Domain, whether the Application Server is
colocated 'physically' with a Proxy server or some other SIP entity is an
implementation issue.

But my guess would be that a SIP Proxy is likely to interface with your
logical Application Server, since it would usually be providing the most
services. That does not however imply that the App. Server is necessarily
sitting on top of a proxy /redirect.

In short, as far as I know,  Application Server is a logical entity that
*can* be physically colocated with your SIP Proxy, if you so wish - or it
can be a separate Physical server with some means of communication with all
entities requesting services (the entities can be Proxies, terminal , or
any other such device)

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

Tricia Wang <[email-masked]> on 05/27/2000 05:55:26 AM

To:   [email-masked]
cc:

Subject:  [SIP] SIP Application Server

Hi, All

Thank you so much

Tricia

---

From: Samandi Sami <[email-masked]>
Date: Tue, 30 May 2000 20:47:31 +0200

I have no access to all the information of the softswitch app. WG, but if I
have understood the explanation of Scott and what Jonathan answered to my
first mail, it seems that both have the same point of view. An application
server is involved in a call as any Proxy/redirect server/UAS and the
invocation is made as any routing decision via an INVITE in the very
beginning of the call. That's it.

Please correct me if I am wrong
Thank you
Sami
	-----Original Message-----
	From:	Neil Deason [SMTP:[email-masked]]
	Sent:	mardi 30 mai 2000 18:39
	To:	Scott Hoffpauir
	Cc:	[email-masked]
	Subject:	Re: [SIP] SIP Application Server

	Thanks for providing the authoritive voice from the working group
Scott.

	Scott Hoffpauir wrote:

	> The softswitch consortium applications working group is working on
an
	> architecture supporting enhanced services in the softswitch
network
	> architecture. An application server is introduced into the
architecture to
	> host enhanced service logic and management functions. While a
softswitch
	> provides basic call control and signaling, manages resources, and
generates
	> call detail records, application servers are intended to host a
variety of
	> enhanced services. Examples of enhanced services include calling
card, 800
	> number translation, Centrex, voice mail, and find-me services. SIP
is used
	> as the interface between an application server and a softswitch.
It allows a
	> softswitch to direct calls to an application server for enhanced
services
	> processing and also allows an application server to redirect or
transfer
	> calls back through a softswitch.
	>
	> An applications server can be a proxy, redirect server or user
agent. It may
	> be stateful or stateless. It really depends on the applications
being
	> provided. I've seen applications servers which are simple redirect
servers
	> providing routing functions and more complex ones acting as
back-to-back
	> user agents, providing unified messaging. Using SIP allows a
softswitch (or
	> other end user device) to pass control to an application server,
without
	> having to worry about its architecture or functions.

	My apologies if I am confusing the terms here but am I wrong in
thinking that a
	SIP Proxy Server qualifies as a Softswitch? I have seen them
described as such
	within the Softswitch Consortium. If a SIP Proxy is a Softswitch,
isn't this
	approach in danger of reproducing the SSP/SCP model? Why would a
Proxy Server
	need to pass an INVITE on to an Application Server for the AS to
then
	proxy/redirect it? Couldn't SIP-CGI and CPL provide ways for a Proxy
to access
	any service logic required to decide whether to proxy/redirect it
directly. A
	Proxy Server augmented with service logic seems to be both a
Softswitch and an
	Application Server, which would make defining an interface based on
SIP between
	the two interesting.

	Regards,
	Neil.
	--
	Ubiquity Software Corporation, UK          http://www.ubiquity.net

	> Jonathan Rosenberg wrote:
	>
	> > Samandi Sami wrote:
	> > >
	> > > Hello,
	> > >
	> > > Is there any document (or work) out there describing the
distribution of
	> > > logic between a feature server (or application server) and the
	> underlying
	> > > network server asking for the services.
	>
	> The Softswitch consortium's Application Working Group are
interested in this
	> area
	> you might want to also look into their work ...
	>          http://www.softswitch.org/Working_Groups/application.html
	>
	> > It is true this is an implementation
	> > > issue but it is also true that this split of the roles between
a SIP
	> > > application server and a SIP proxy server is similar to the IN
	> architecture
	> > > where the SSP handles the call control and the SCP the service
control.
	> >
	> > The difference between and applications server and a proxy is
only in
	> > the complexity of the programs which guide their operation.
	> >
	> > Both speak SIP; both can proxy or redirect; there is no way to
	> > distinguish a proxy from an applications server from the
outside. This
	> > is quite different from the SSP/SCP model, which presumes
totally
	> > different interfaces and roles.
	>
	> I am not part of the Softswitch Application Working Group, and
certainly do
	> not
	> speak for them, but to me this doesn't appear to totally fit with
what I
	> understand to be their position. I know there are people on this
list close
	> to
	> this work, perhaps they would care to comment.
	>
	> The Softswitch Application Group are seeking to define the
interfaces
	> between an
	> Application Server and a Softswitch. As I understand it a SIP
Proxy Server
	> can be
	> one example of a Softswitch. They have described the Softswitch as
providing
	> basic
	> call control and signalling, managing resources, and generating
call detail
	> records. Whereas application servers host the service logic for a
variety of
	> enhanced services and media servers provide bearer oriented
functions, such
	> as
	> IVR, conferencing, and fax. They suggest SIP is used as the
interface
	> between an
	> Application Server and a Softswitch, while the Real Time Protocol
(RTP) is
	> used as
	> the interface between a media server and media gateway.
	>
	> Please note I am not seeking to promote the Softswitch view over
the one
	> described
	> by Jonathan, which I personally empathise with, just some
discussion of a
	> very
	> interesting area.
	>
	> Regards,
	> Neil
	> --
	> Ubiquity Software Corporation, UK          http://www.ubiquity.net
	>
	> > I think the SIP model is a very powerful
	> > model. It means that decisions about service invocation can
always be
	> > represented as routing decisions. If I want some service from
provider
	> > X, all that needs to happen is to have my call routed to the
server at
	> > domain X.
	> >
	> > One of the reasons the separation between call control and
service
	> > control was made in the IN, was the desire for the SCP not to
receive
	> > all signaling messages for the call. I will note that in SIP,
this
	> > function is already provided in the call signaling itself,
through the
	> > Record-Route mechanism. This means an application server can
drop out of
	> > the call after routing the initial request, as can a proxy.
	> >
	> >  Is
	> > > it then logical to think about an implementation like the
following :
	> > >
	> > > -       The network server is a call stateful proxy (holding
the state
	> of a
	> > > call between the INVITE and the BYE). This SIP proxy forward
requests to
	> the
	> > > application server. This proxy server goes stateful and proxy
requests
	> only
	> > > when needed (for instance when the end user has subscribed to
predefined
	> > > services).
	> >
	> > Why? As I argue above, this distinction of an SSP/SCP role makes
less
	> > sense in SIP.
	> >
	> > > -       The application server will behave per call basis
whether as a
	> > > redirect server (to provide routing services) or as a UAS when
media
	> > > services are needed (IVR, ...). I am not sure whether this
equipment
	> should
	> > > also proxy the request ?.
	> >
	> > If that is part of the service, sure.
	> >
	> > > -       The goal here is not to involve the application server
for the
	> whole
	> > > duration of the call but only when needed and this means
telling the
	> > > application server what's state of the call that triggered the
call of
	> the
	> > > service. For instance, A call B, but  B is busy,  the Proxy
server of B
	> > > receives a 486 and then sends an INVITE to the feature server
asking
	> what to
	> > > do. How to tell the application server that the user is busy
(the
	> equivalent
	> > > of the DP Terminal busy of the IN) ? Should this be done in a
	> proprietary
	> > > way ?
	> >
	> > I would not do it this way. I would send the initial INVITE to
the
	> > feature server, and when the 486 response comes, have it go from
there.