Do we need both(main-servlet AND -dar.properties) configurations for SIP servlets ?

[Vicky]

I have been going through the SIP servlet samples and don't understand
what is the use of main-servlet AND ApplicationRouter.
It seems that the -dar.properties file contains the application flow
of the SIP message in the SIP container, if that i the case then why
do we have to define the main-servlet..
I can map the SIP message to the SIPRouter(sip application) inside the
dar.properties, when should I configure main-servlet?

[Vladimir Ralev]

I dont remember all the details right now, but mostly it goes like this:
One application (one war or sar) can have many servlets. Each application has one main servlet.
The application router is responsible for selecting the application, but not the servlet. Once a request is routed to an application by the app router, the main servlet is called. Then in that servlet programatically you can forward it to other servlets.

[Vicky]

How does the initial request say REGISTER gets mapped to appropriate
main-servlet assuming there are N application with N main-servlets?
Thanks.

On Sep 4, 5:03 pm, "Vladimir Ralev" <vladimir.ra...@gmail.com> wrote:
> I dont remember all the details right now, but mostly it goes like this:
> One application (one war or sar) can have many servlets. Each application
> has one main servlet.
> The application router is responsible for selecting the application, but not
> the servlet. Once a request is routed to an application by the app router,
> the main servlet is called. Then in that servlet programatically you can
> forward it to other servlets.
>

[Vladimir Ralev]

The application router chooses which apps must receive the initial request and in what order by the rules defined in the dar files. Note the app router is not standartized beyond the SPI that the sip servlets container users to interact with it, each vendor can decide on their own what application router to bundle in their sip servlets container (the mobicents AR use dar files for configuration, but other ARs may not).

[Jean Deruelle]

1. your REGISTER will be routed to the first application selected by
the app router
2. container will check the deployment descriptor or your annotations
and will invoke your main servlet.
3 if your application sends a final response, the routing process will
stop. if no final response is sent 1. 2. are repeated over and over
again until a final response is sent

[Vicky Kak]

>>your REGISTER will be routed to the first application selected by
>>the app router

If I have n applications and thus n main-servlets, which one will be selected by ApplicationRouter when I hit the REGISTER from the sip useragent.
Thanks

Vicky

[Jean Deruelle]

the container will call the Application Router (check the spec about
that) to know to which application to direct the request to first,
when the container gets the application name from the appplication
router it will select the main servlet of that application and route
the REGISTER to it

[Vicky Kak]

okay I understand that there has to be one DefaultAppplicationRouter mapped to one of the dar.properties placed in the tomcat/conf/dars/.
I think we can have multiple applications and corresponding mutiple dars place in the the tomat/conf/dars , the default application router is configured either through the system property(javax.servlet.sip.ar.dar.configuration)  or in server.xml will be the first one which will be invoked by the container when SIP message comes at connector port of tomcat(5080)
Thanks

[Jean Deruelle]

Hi vicky,

what seems to confuse you is that you think there is multiple dar
files. But actually there is only one containing all the applications
and their order
like this dar file
http://www.mobicents.org/speeddial-locationservice-dar.properties
which is the dar for speed dial and location service
(http://www.mobicents.org/speeddial_locationservice.html) which is
composed of 2 different applications each one containing a main
servlet.

So in this case the call flow is
UA1 wants to call UA2 so it starts a call and it goes through
Mobicents Sip Servlets
The Container asks the Application Router for the appplication to
invoke for the INVITE request.
The Application Router will lookup the file and check what is the
first application for the INVITE, in our case it will return
org.mobicents.servlet.sip.example.SpeedDialSipServlet (this is a
little confusing here because the name of the application ends with
SipServlet, org.mobicents.servlet.sip.example.SpeedDialApplication
would have been more correct as an application name).
The container will check in the list of the its deployed applications
if one is called
org.mobicents.servlet.sip.example.SpeedDialSipServlet.
When it has found the application it will check what is its main
servlet (in this case it would be SpeedDialSipServlet which is why I
said earlier that the application name was confusing and should have
been called org.mobicents.servlet.sip.example.SpeedDialApplication)
So now that it knows the main servlet of the application, it will inoke it.
The application will do its business logic and proxy the INVITE in this case.
So since the application proxied the INVITE (if the application would
have acted an an UAS and sent a final response the routing process
would have been stopped) the Container will call again the Application
Router to check if there is another application to call.
In our case there is another
org.mobicents.servlet.sip.example.LocationServiceSipServlet (again the
application should have been called
org.mobicents.servlet.sip.example.LocationServiceApplication to avoid
the confusion with the main servlet) so the container will look it up
and check its main servlet and will invoke it. The application do
again its business logic and proxies the INVITE.
the Container will call again the Application Router to check if
there is another application to call. In this case there is none so
the INVITE is routed outside the container to the route defined in the
request or to the request uri and will go to UA2.

Note that this selection process occurs only for initial requests and
subsequent requests and responses follow the application path that has
been built by the initial request.

hope this clarifies things a bit.

Jean

[aayush bhatnagar]

Hmmm..this means that for an application consisting of multiple
servlets, a round trip through the application router cannot be
avoided. The AR will decide the next servlet invocation always.
From this, i have one query that comes to my mind..
Suppose i have three totally independent applications A,B and C whose
business logic is unrelated to each other. All three are listening to
the initial INVITE. However, they behave differently on receiving the
INVITE. Application A proxies the invite, application B creates a
dialog and application C unconditionally blocks all initial requests.
Given this, when an initial invite is received by the container, will
it invoke all three independent applications?

Regards
Aayush

[Vicky Kak]

Thanks Jean, yes it makes sense.
Now I understand there there is only one dar file and it should route the SIP messages to applications(to main-servlet).

[Jean Deruelle]

Remember that for application B you have no direct control on the
dialog in sip servlets this is handled by the container, so you will
have to be more specific on the type of applications it is.
Basically an application in response to an initial request can either
proxy or acts as UA either typical UAS or B2BUA.
so in response to your question I would say it depends in which order
they are invoked.
If application C is invoked first the other applications won't be
invoked since it sends a final response.

If application A is invoked first, application B or C will be invoked.
again if application C is invoked right after application A,
application B won't be invoked. if application B is invoked however
application C might be invoked it depends of the behavior of
application B.

if application B is invoked first, it depends of its behavior, other
applications may be invoked.

So the order in which the AR returns the applications is very
important. This is why the sip servlets specification introduces the
deployer role that is the person that will be responsible for choosing
the applicaitons that will be invoked and in which order.

Jean

[Vicky Kak]

>>a round trip through the application router cannot be
>>avoided.

Shouldn't the business logic of the doInvite() take care of this, the flow should be able to stop at any application according to me.
I have not yet tried it but looks logical.

Vicky

[Vicky Kak]

Hi Jean,

>>in this case it would be SpeedDialSipServlet which is why I
>>said earlier that the application name was confusing and should have
>>been called org.mobicents.servlet.sip.

>>example.SpeedDialApplication

Yes the application name be appropriate as the Servlet naming is confusing, this must be changed.


Vicky

[Jean Deruelle]

The applications don't have any access to the AR only the Container so
no it is not possible.
there is not much overhead in doing a round trip to the application
router if the application router is well designed.

[Jean Deruelle]

Added to my TODO List :-)

[aayush bhatnagar]

:)

Yes, if the AR is well designed, there might be no significant overhead in the round trip.

Actually, in my scenario above, Applications A, B and C were mutually exclusive, with no dependence or logical linkage between them as represented in the DAR file.

Let me map them to real-life applications:

App A proxies the invite: This is the Originating Id restriction (OIR) service. If the caller has subscribed to this service, then his Display name will be hidden and replaced as anonymous, and the INVITE will be proxied to the called party.

App B creates a dialog: This is the Voice mail retrieval service.  A dialog is created and the recorded voice mail is played back.

App C: is a call blocking service for only those subscribers who do not pay their bills on time (like me :) )

These are 3 independent services.

So here, if all three apps are co-located in the same SIP Servlet container, I would want one of these three to be invoked on receiving the initial INVITE. I would want to distinguish between them by using a PSI (Public Service Identity) for Voicemail, Subscriber URI and his account balance Database for call blocking and so on.


Warm Regards
Aayush

[Jean Deruelle]

In this case you should develop a custom Appplication Router to suit
your needs that will be connected to your PSI so that the application
router knows which app to invoke.

[aayush bhatnagar]

yes. I agree with you completely.

Maybe this can be one of the requirements for developing an IMS compliant AS on top of Sip Servlets, i dont remember the issue #.

Best Regards
Aayush

[Jean Deruelle]

Issue 323 is now pointing at this thread ;-)

Although this might not be needed by everyone to have a custome AR and
this might be also a vendor specific requirement to wok with their own
PSI.
But we can still develop AR alternatives to the default current one
or make the current one more flexible if needed.

[aayush bhatnagar]

hi Jean ! 

; ) 

IMS mandates some application servers to publish a well known PSI (23.003) to the network. 

Sometimes it can be useful for the IMS core for routing the call to the AS. 

It can be used as a SPT by the S-CSCF at the ISC interface, and can help in PSI subdomain routing procedures for the I-CSCF (Ma reference point). 

Wildcard PSIs (TS 23.003/TS 24.229/HSS specs) can be useful for implementing an IMS Chat server -->

sip: chat_room* @rancoretech.com where * = 1,2,3.......

I am using PSIs in my current project for identifying content based services.

Correct me if i might sound wrong..but I find the DAR file a special manifestation of initial filter criteria processing..it is also providing a set of conditions for servlet invocation.

:)

Warm Regards

Aayush

[Jean Deruelle]

We have 2 options here. Either extend or modify the DAR to provide
more flexibility or provide a specific IMS AR.

Correct me if I'm wrong but in this case the AR would just check the
userinfo portion of the SIP URI or in the telephone-subscriber portion
of the Tel URI to know to which sip servlets application to route the
request to, right ? if that is right, option 1 can be done easily.
I'm wondering if that may also mean that the Application Router needs
a way to be feed externally with the mappings between an application
and its PSI or the PSI would become the application name in this case
?
if it is the latter option 1 might be done quite easily.

On Mon, Sep 8, 2008 at 5:15 PM, aayush bhatnagar

[aayush bhatnagar]

Yes. You are absolutely right.
The PSI will become the application identifier..in particular the
userInfo part of the SIP URI. I am not too sure whether the tel url
can behave as a PSI or not. I will revisit the standards about it.
From my understanding, a request containing a tel url will never reach
an IMS AS. It will be intercepted by the S-CSCF...an ENUM query
performed..and converted to a SIP URI (if available)..or the request
will break out to the PSTN.
The application may be composed of various servlets, and a single MSS
may host several applications that reuse some of those servlets.
The PSI has the same relationship to the service, that an IMS public
user identity has to the customer (IMS Private user identity/
handset).
So, a single MSS may host many PSIs...where each PSI points to a
unique application.
:)
sounds fun.
.....Aayush

[aayush bhatnagar]

Option 1 seems to suffice..
i will enlist all possible call scenarios regarding PSIs..and then we
can see..if any special requirement pops up.

[Jean Deruelle]

ok great. Thanks. I made the Issue 109 point to this thread and to
Issue 323 too.

On Fri, Sep 12, 2008 at 4:21 PM, aayush bhatnagar

[aayush bhatnagar]

Hi Jean,

A compilation about PSIs and scenarios :)

A) Public Service Identity Generic requirements (GR): 

1) Upon creation, a PSI should be unique. A PSI may be created and configured by the operator (Representing a service that the carrier provides to his customers only). 

2)  Only the username part of a PSI is definable within a predefined hostname(s).

3)  Dynamic creation and retrieval of a  PSI should be possible by the UE from the AS (Ut reference point). Eg: A  group management service involving the creation of a closed user group / personal network through a GUI : myFamily@domain, myFriends@domain. Such a closed user group PSI can be used for the invocation of a group conferencing service, video sharing service, shared whiteboard service etc. Hence the maintenance of a closed user group acts as a service enabler for other services.

4) A PSI can be used as a trigger point for IMS service control by including it in the user's service profile. Such PSIs are called statically configured PSIs and are available in the domain of only that IMS operator and his customers (Related to point 1). 

5) It should be possible to create, manage and delete PSIs by the operator through a service management point provided by the HSS through O&M procedures. Such PSIs are called Distinct PSIs. Eg: When a new service is added to the user's service profile after service provisioning, or when a service is deactivated by the operator etc. 

6) It should be possible to create and delete Wildcarded PSIs (representing a range of PSIs) through a management point provided by the HSS. (O&M action). 

B) PSI routing scenarios in IMS:

1) For an originating call from A party, the S-CSCF would evaluate the orig-IFc of A-party, match the relevant service trigger point (SPT = Request URI = PSI ) and route the request to the SIP application server hosting the PSI. 

2) The I-CSCF may route an incoming request for the terminating call leg directly to the SIP-AS, without querying the HSS. The PSI is configured statically in the I-CSCF. The I-CSCF is able to resolve the SIP-AS hosting the PSI by performing a DNS lookup. This is  also referred to as PSI sub-domain routing at the I-CSCF. 

3) The I-CSCF queries the HSS against the PSI. The HSS returns the S-CSCF name/capabilities against the PSI supplied. The I-CSCF forwards the request to the S-CSCF which then performs normal IMS service routing procedures towards the SIP-AS. This scenario is provided for cases where the network is distributed, and there are multiple CSCFs in the network. Not all SIP application servers may be accessible by every S-CSCF. Hence the HSS query is performed at the I-CSCF to route the request to the correct S-CSCF for further routing. Such PSIs whose information is available at the HSS are called globally routable PSIs. 

A SIP AS hosting the PSI alongwith the PSI entry in the HSS is called a PSI user.

4) The S-CSCF may perform a DNS query and forward a request to the I-CSCF of the domain where the PSI is hosted.

5) The SIP-AS hosting the PSI can initiate a request ( originating UA behavior) towards the IMS core. Eg: Voicemail playback service, SIP wake up call service etc. In case of originating UA behavior, the SIP-AS will need to append an orig parameter in the topmost route header to aid the IMS core to distinguish this as an AS originated request. 

6) The AS may query the ENUM server (in case of tel numbers) and forward the request to the destination. Eg: If a reminder / calender service is requested by a customer who has only provided a telephone number. 

C) Special service scenarios: 

1) A short MESSAGE addressed to a PSI: myFa...@chatserver.rancore.com will result in the broadcast of the Instant Message to all the members of the closed user group. 

2) An INVITE addressed to a PSI: myFr...@videoshareserver.rancore.com will result the SIP-AS to host a video share session, by inviting the members of the closed user group to a multicast session. 

3) An INVITE addressed to a PSI myOf...@videoconfserver.rancore.com will result in the SIP-AS to invite all the members of the user group to a video conference hosted by the AS. 

Here 3 closed user groups are defined. 

Each Closed user group represented by a PSI can be associated with my IMS service profile. 

The assumption here is that the IMS user has 3 service profiles: Family, Friends and Office. A closed user group PSI is associated with each service profile.

The username part of the PSI can be used by the SIP servlet container to identify the application requested. 

The PSI sub-domain (chatserver.rancore.com etc) can be used by the IMS-core for DNS based routing, PSI sub-domain routing or normal iFc based routing as desired by the operator.

-----------------------------------------------------------------

Best Regards

Aayush

[Jean Deruelle]

I changed the dar files, sip.xml, web.xml  and source code files to use Application suffix instead of SipServlet for app name to remove the confusion. Available in trunk only for now.