Subject: Re: [SIP] SIP Application Server

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 Jun 2000 00:28:48 -0400

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.

-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

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

---

From: Neil Deason <[email-masked]>
Date: Thu, 01 Jun 2000 11:23:13 +0100

> 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 02 Jun 2000 01:15:56 -0400

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

-Jonathan R.
[email-masked]                     FAX:   (973) 952-5050

---

From: Neil Deason <[email-masked]>
Date: Fri, 02 Jun 2000 09:19:41 +0100

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 02 Jun 2000 09:34:51 -0400

> that empower the simple creation of innovative services not Application Servers that merely

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.

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 02 Jun 2000 19:42:58 -0500

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

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of
>Jonathan Rosenberg
>Sent: Friday, June 02, 2000 8:35 AM
>To: Neil Deason
>Cc: [email-masked]
>Subject: Re: [SIP] SIP Application Server
>
>
>
>
>Neil Deason wrote:
>>
>> 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.
>> 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
>> 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.
>