Subject: RE: [SIP] SIP Application Server

From: Samandi Sami <[email-masked]>
Date: Mon, 29 May 2000 19:31:14 +0200

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

Could someone comment on this please even if it seems straightforward and
maybe a quite high level views.

Thank you

Sami

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	samedi 27 mai 2000 06:59
	To:	Tricia Wang
	Cc:	[email-masked]
	Subject:	Re: [SIP] SIP Application Server

	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

	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

	_______________________________________________
	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: Mon, 29 May 2000 23:19:49 -0400

Samandi Sami wrote:
> 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 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
> when needed (for instance when the end user has subscribed to predefined

Why? As I argue above, this distinction of an SSP/SCP role makes less
sense in SIP.

> also proxy the request ?.

If that is part of the service, sure.

> of the DP Terminal busy of the IN) ? Should this be done in a proprietary

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. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Neil Deason <[email-masked]>
Date: Tue, 30 May 2000 10:25:17 +0100

Jonathan Rosenberg wrote:

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

---

From: "Scott Hoffpauir" <[email-masked]>
Date: Tue, 30 May 2000 09:34:24 -0400

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.

Scott Hoffpauir
BroadSoft, Inc.
200 Perry Parkway, Suite 1
Gaithersburg, MD 20878
301-977-4295

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Neil Deason
Sent: Tuesday, May 30, 2000 5:25 AM
To: [email-masked]
Subject: Re: [SIP] SIP Application Server

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

> 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

---

From: Neil Deason <[email-masked]>
Date: Tue, 30 May 2000 17:39:14 +0100

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

> 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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 May 2000 18:21:16 -0400

> Application Server, which would make defining an interface based on SIP between

This leads back to my original statement. The only difference between a
proxy (I won't get into the softswitch vs. proxy thing, which is purely
a definition issue) and an application server is the complexity of the
programs it executes. In the case you describe, of a proxy implementing
CGI or CPL or JAIN or parlay or whatever apps, it is then an app server.
One could even argue that the proxy function is a type of application
running on an app server. Fact is, it doesn't really matter. 

Samandi Sami later writes:
> 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.

Yes. 

-Jonathan R.

---

From: Neil Deason <[email-masked]>
Date: Wed, 31 May 2000 09:15:40 +0100

> > beginning of the call. That's it.

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.

Regards,
Neil.