Subject: [Sip] Application Server Rationale?

From: gautham <[email-masked]>
Date: Fri, 6 Jul 2001 19:47:05 +0530

Hi,

    I needed clarification on a few aspects of the SIP Server and Application Server interface. 
    Please give necessary and applicable pointers if this is a repeat question
    on this list. Thanks in advance and in anticipation of a response.

    Some of the functional blocks that I would attribute to a SIP Server would typically
    be: Basic Call Processing, Routing, Subscriber Service Data Management (may
    be an HLR/VLR function or access to the same), Accounting, and other support
    functions. 

    Further, the intention would then be to have another platform (the AS) that can house
     all services - be it CLASS-4-like services (like toll-free or LNP) or
     typical CLASS-5 services (subscriber initiated services, IP Centrex) and
    others of the likes of Pre-paid, Meet-me Conference, Click-to-talk, etc. 

    This is very similar to the Softswitch requirements of the ISC-Softswitch Architecture.

    Few questions on the above:
1> Can I build an AS that is normally not in the path of the call flow and that is brought
   into the call flow only when a certain *trigger* and its associated criteria
   is detected? Analogous to the IN wherein a trigger (DP) may be armed with a
   certain criteria and when the DP and the criteria match, the service key
   (which may be the Request-URI here) is delivered to the SCP (the AS here),
   probably through an INVITE.

2> If the above is possible, then is it possible to use SIP (over the AS-SIP Server interface)
 in a manner in which the AS can instruct the SIP Server to arm (or monitor)
more events for only this call?  If so, how is this reported (the mechanism) -
in-call arming and in-call reporting of events?

3> How are typically Call Party Handling operations carried out over this
interface? Is a fine-grained control possible, as through INAP? I have gone
through the proposed architecture for Application Server components (draft
-rosenberg-sip-app-components-01.txt)  and still would want some info on this
aspect.

4> SIP baseline package propounds how a number of services such as Call Forwarding, 
Call Transfer, Call Hold etc. are to be handled. But suppose I want to provide
an AS that can house all CLASS-5 features, what would it really take? This AS
would then turn out to be a Call Stateful Proxy, with every call going through
it. Is this what is then intended? But this would limit the scalability of the
platform and not render the same to third-party involvement!?

    Coming to what the Network Architects really thought how things would work:

5> What is the SIP interface between the SIP Proxy and the AS really used for?
 Is it for call supervision or for transferring the handling of call
processing from the SIP Proxy to the AS? Again the issue of "the condition"
under which this happens comes to the fore!

6> Services like 3PCC are the easy part for the AS to address. Other services
 that are explicitly targeted by the INVITE from the UA are also probably
fine, but what about call handling services? CPL would not help here as it is
for the terminating side of the call. What about the originating side services? 

7> Some conditions at the SIP Proxy, such as routing failure, may be taken care of at the Proxy
 itself through local/centralized policies. How would these then interact with
a third-pary application on an AS - that tie with similar triggers? If some
services are handled by the SIP Proxy and others by the AS, isnt there a
perceived danger of complex Feature Interactions happening down-the-line?

    The above is definitely not something that would not have been addressed in some forum.
 I would appreciate if the above can either be discussed here or pointers to a
prior discussion on the same can be shared. Thanks!

Regards,
Gautham A.N.

Please go through the same
and lets discuss this before we send it on the list ... lets take this on
priority! Please review critically - and suggest changes to the following
text!

I needed clarification
on a few aspects of the SIP Server and Application Server interface. Please give
necessary and applicable pointers if this is a repeat question on this list.
Thanks in advance and in anticipation of a response.

Some of the functional
blocks that I would attribute to a SIP Server would typically be: Basic Call
Processing, Routing, Subscriber Service Data Management (may be an HLR/VLR
function or access to the same), Accounting, and other support functions.

Further, the intention
would then be to have another platform (the AS) that can house all services - be
it CLASS-4-like services (like toll-free or LNP) or typical CLASS-5 services
(subscriber initiated services, IP Centrex) and others of the likes of Pre-paid,
Meet-me Conference, Click-to-talk, etc.

This is very similar to
the Softswitch requirements of the ISC-Softswitch Architecture.

Few questions on the
above:

1> Can I build an AS that is normally
not in the path of the call flow and that is brought into the call flow only
when a certain *trigger* and its associated criteria is detected? Analogous to
the IN wherein a trigger (DP) may be armed with a certain criteria and when the
DP and the criteria match, the service key (which may be the Request-URI here)
is delivered to the SCP (the AS here), probably through an INVITE.

2> If the above is possible, then is it
possible to use SIP (over the AS-SIP Server interface) in a manner in which the
AS can instruct the SIP Server to arm (or monitor) more events for only this
call? If so, how is this reported (the mechanism) - in-call arming and in-call
reporting of events?

3> How are typically Call Party Handling
operations carried out over this interface? Is a fine-grained control possible,
as through INAP? I have gone through the proposed architecture for Application
Server components - and still would want some info on this aspect.

4> SIP baseline package
propounds how a number of services such as Call Forwarding, Call Transfer,
Call Hold etc. are to be handled. But suppose I want to provide an AS that can
house all CLASS-5 features, what would it really take? This AS would then turn
out to be a Call Stateful Proxy, with every call going through it. Is this what
is then intended? But this would limit the scalability of the platform and not
render the same to third-party involvement!?

Coming to what the
Network Architects really thought how things would work:

5> What is the SIP interface between the
SIP Proxy and the AS really used for? Is it for call supervision or for
transferring the handling of call processing from the SIP Proxy to the AS? Again
the issue of "the condition" under which this happens comes to the
fore!

6> Services like 3PCC are the easy part
for the AS to address. Other services that are explicitly targeted by the INVITE
from the UA are also probably fine, but what about call handling services?
CPL would not help here as it is for the terminating side of the call. What
about the originating side services?

7> Some conditions at the SIP Proxy,
such as routing failure, may be taken care of at the Proxy itself through
local/centralized policies. How would these then interact with a third-pary
application on an AS - that tie with similar triggers? If some services are
handled by the SIP Proxy and others by the AS, isnt there a perceived danger of
complex Feature Interactions happening down-the-line?

The above is definitely
not something that would not have been addressed in some forum. I would
appreciate if the above can either be discussed here or pointers to a prior
discussion on the same can be shared. Thanks!

Regards,