Q: When I use the Test Agent to send a message to my servlet, my servlet sends back a request, but it is sent 11 times to the Test Agent. Why?

A: This is because of the transaction layer in SIP that does repetitions for unreliable transport, such as UDP, until a response is received for a request.

Solution: To solve this issue, send a final response, that is a response having a code greater or equal to 200 to the message sender. As soon as it is received, the repetition will stop. For more information about SIP transactions, refer to RFC 3261.

Q: When a servlet is deployed as a proxy, the application is called to process the incoming message twice. 

A: The application expects an incoming MESSAGE message. By default, SDS will generate a mapping rule for the request method = MESSAGE. However, inside the application, you have created another MESSAGE message and sent it. The result is that the application is called again because the rule request.method = MESSAGE is still true, even though the message does not come from the outside world. 

To prevent this situation, whenever possible, make a more precise rule in the sip.xml. This can usually be done by adding the Request URI to the rules. In most cases, the message coming from the outside world will have the same URI, for example, sip:messaging@ericsson.com. The generated message will have the URI sip:alice@ericsson.com. In such a case, the sip.xml can be modified to also include the request.uri=sip:messaging@ericsson.com. 

Q: Is there a way to output log information to the console (e.g.: the SIP Container console log), from the SIP Servlet code? I've tried without success the standard System.out.println()

A: You can use the log() method in SipServlet.

Q: I have a B2BUA application and when I try to send a message I get the following error: Could not find servlet name: null in application: /application name

A: The handler is not set on the newly created session. The handler is the servlet responsible for handling subsequent messages related to the request about to be sent.

Solution:
Initialize the session handler using the servlet name (not the servlet class name) you put in the deployment descriptor (sip.xml). For example, if you have a com.ericssons.sds.MySerlvet, by default the servlet name is MyServlet (you may have used another one). The following snippet illustrates the correct way to code it:

  myNewRequest.getSession().setHandler("MyServlet");

Then you can proceed with request.send();

Q: When the servlet receives SIP:OPTIONS, it modifies the session attribute, but why is the corresponding SipSessionAttributeListener listener not invoked?
Q: When the servlet responds 200 OK to SIP:INVITE and the client does not send ACK, why is the corresponding SipErrorListener listener not invoked?

A: This is a limitation of the SDS SIP Container.