I have one servlet deployed in my environment and when I send any new requests the DAR will route them right back to my servlet.
To get around this I have set the SipApplicationRoutingDirective to CONTINUE. Messages are properly routed but I get the following error in the logs:
WeightApplica E WeightApplicationSelector CWSCT0407E: No state for default application router.
So is the solution to provide different routing rules for the DAR? If so, how can it differentiate between a sip request generated from inside the servlet vs. outside the servlet?
Any help would be great, thanks.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
5 replies Latest Post - 2011-05-18T07:11:21Z by SystemAdmin
Pinned topic Sip servlet as UAC
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-05-18T07:11:21Z at 2011-05-18T07:11:21Z by SystemAdmin
Re: Sip servlet as UAC2011-05-15T13:16:56Z in response to SystemAdminHi,
According to the API of setRoutingDirective:
"If directive is NEW, origRequest parameter is ignored. If directive is CONTINUE or REVERSE, the parameter origRequest must be an initial request dispatched by the container to this application, i.e. origRequest.isInitial() must be true. This request must be a request created in a new SipSession or from an initial request, and must not have been sent. If any one of these preconditions are not met, the method throws an IllegalStateException."
You should set to Continue only if you have an incoming message to use as a parameter to the method(e.g. b2b case ). in your case it looks like you are acting as a pure UAC so you do not have any incoming message.
It looks like DAR is not the best choice for UAC applications that are also UAS applications.
You can do one of the following:
1. receive the request again and just proxy it (none record route proxy)
2. use matching rules, so when the request is received again it will not match the application and the container will send it out.
3. use CAR instead of DAR. it looks like this is the most appropriate solution according to JSR 289.
cheungda 2700045TJV20 Posts
Re: Sip servlet as UAC2011-05-17T08:25:48Z in response to cheungdaHi,
I agree that this JSR 289 behavior is confusing (and one can say that it does not sound right for UAC case) but SIP container must follow the JSR.
According to JSR289 section 15.2.2:
"...or if an application Z acts as a UAC and sends a INVITE request, the container invokes the Application Router. The Application Router starts the selection process from the beginning and selects A...."
"When an application acts as a UAC and sends a request, the request is not based on any previously received request. That is, the application intends the request to be regarded as a new request unrelated to any other request. Although the application intention is implicit in
this case, it is clear that a new application selection process should take place."
So when acting as a UAC the application router must start a new application selection process.
When using DAR you have little control on the process, this is why you should use CAR in this case, this will help you to avoid processing outgoing messages.
cheungda 2700045TJV20 Posts
Re: Sip servlet as UAC2011-05-18T07:11:21Z in response to cheungdaThis behavior is not clear from the JSR, the current Websphere SIP container behavior follows JSR289 application composition processing.
Adding a new none JSR289 behavior requires a new Websphere requirement and it will only be enabled if customers will enable this functionality since it can not be the default.