Mobicents

Connectors

Just as http connectors you can add sip connectors the same way, in adding Connector tag under the Service Tag in the container server.xml configuration file.
By example, to add a sip connector on ip address 127.0.0.1, port 5080 on udp transport use the following :

<Connector
port="5080"
ipAddress = "127.0.0.1"
protocol="org.mobicents.servlet.sip.startup.SipProtocolHandler"
signalingTransport="udp"
useStun="false"
stunServerAddress="stun01.sipphone.com"
stunServerPort="3478"
sipStackPropertiesFile="conf/mss-sip-stack.properties"/
staticServerAddress="122.122.122.122"/
staticServerPort="44"/
useStaticAddress="true"/ >

Here is a description of the sip Connector tag's attributes :

• port : the port number on which the container will be able to receive SIP messages. You can setup the container to listen on all available IP Addresses by setting the ip address to 0.0.0.0
• ipAddress : The ip address on which the container will be able to receive SIP messages.
• protocol : This attribute specifies that this is a Sip Connector and not an http one. There is no need to change this property.
• signalingTransport : the transport on which the container will be able to receive SIP messages
• usePrettyEncoding : (true by default) Allows Via, Route, and RecordRouteheader field information to be split into multiple lines, rather than each header field being separating with a comma. The attribute defaults to "true" to able to better interoperate with other SIP Servers such as Asterisk PBX.
• useStun : Set to true to enable STUN for this connector and make sure ipAddress is different from 127.0.0.1. (Default to false, you can also check the STUN section for more information)
• sipStackPropertiesFile : the underlying JAIN SIP Stack implementation can be further configured through a set of properties (see jain sip configuration properties and nist sip implementation configuration properties ), set this property to the location of the file that will contain key/value pairs corresponding to the stack configuration properties. If this property is omitted, the following default values will be assumed :
  • gov.nist.javax.sip.LOG_MESSAGE_CONTENT=true
  • gov.nist.javax.sip.TRACE_LEVEL=32
  • gov.nist.javax.sip.DEBUG_LOG=logs/mss-jsip-debuglog.txt
  • gov.nist.javax.sip.SERVER_LOG=logs/mss-jsip-messages.xml
  • javax.sip.STACK_NAME=Mobicents-SIP-Servlets
  • javax.sip.AUTOMATIC_DIALOG_SUPPORT=off
  • gov.nist.javax.sip.DELIVER_UNSOLICITED_NOTIFY=true
  • gov.nist.javax.sip.THREAD_POOL_SIZE=64
  • gov.nist.javax.sip.REENTRANT_LISTENER=true
• Optionnaly there is a sipPathName attribute allowing one to change the underlying JAIN SIP Stack implementation. If not specified it defaults to "gov.nist", which is the RI for JAIN SIP. Please note that switching the JAIN SIP Stack will not work because we rely on internal classes of the RI, but Mobicents proposed some additions to the JAIN SIP APIs so that the next rev of the spec allows it.
• staticServerAddress : this attribute specifies what address to put in Contact/Via headers of requests created by the server. It is useful in cluster configurations where you don't want requests to be bound to a specific node address and you want to requests to be bound to the load-balancer address.
• staticServerPort : the port of the load-balancer specified in staticServerAddress . It is useful in cluster configurations where you don't want requests to be bound to a specific node address and you want to requests to be bound to the load-balancer address.
• useStaticAddress : Specifies whether the settings in staticServerAddress and staticServerPort should are active. It is useful in cluster configurations where you don't want requests to be bound to a specific node address and you want to requests to be bound to the load-balancer address.

Application Router and Service Configuration

The application router is called by the container to select a SIP servlet application to service an initial request. It embodies the logic used to choose which applications to invoke. An application router is required for a container to function, but it is a separate logical entity from the container. The application router is solely responsible for application selection and must not implement application logic. For example, the application router cannot modify a request or send a response.

For more information regarding the Application Router, check the Application router section To configure it, you need to configure the Service Tag in the container server.xml configuration file :

<Service name="Sip-Servlets"
className="org.mobicents.servlet.sip.startup.SipStandardService"
sipApplicationDispatcherClassName="org.mobicents.servlet.sip.core.SipApplicationDispatcherImpl"
additionalParameterableHeaders="header1,Header2"
bypassResponseExecutor="false"
bypassRequestExecutor="false"
darConfigurationFileLocation="file:///home/deruelle/workspaces/mobicents-sip-servlets/sip-servlets-examples/call-blocking-demo/call-blocking-servlet-dar.properties" >

Here is a description of the sip Service tag's attributes :

• className : This attribute specifies that the servlet container will be a converged (sip + http) servlet container. You can also use it to handle load balancing and failover
• sipApplicationDispatcherClassName : This attribute specifies the class name of the org.mobicents.servlet.sip.core.SipApplicationDispatcher implementation to use. The routing algorithm and application selection process is done in that class.
• darConfigurationFileLocation : The default application router file location. Used by our default application router to know the application selection logic. Check JSR 289 Spec Appendix C.
• additionalParameterableHeaders : A comma-separated list of header names that are treated as Parameterable by the container. For these headers setting and getting parameters is allowed, others will result in ServletParseExcpetion. There are a number of standard headers that are already Parameterable, you generally don't have to include them here.
• bypassResponseExecutor/bypassRequestExecutor : Since Mobicents Sip Servlets uses a ThreadPoolExecutor backed by a LinkedBlockingQueue to dispatch the requests/responses.
  There could be a race condition where two different threads can handle two responses(180 Ringing/200 OK) at the same time, one taking over the other.(200 OK dispatched to the app before the ringing) So those flags (false by default) allow not to use the Executors thus using jain sip serializing per transaction to ensure such race conditions don't occur.

Logging

This is a part that is a little tricky since there are 2 level of logging :

• The container level which is configured by the log4j.xml file usually located in the lib directory of the container.
• The nist sip stack which is configured by the above Connector tag.