Lots of fixes have gone into SailFin 2.0, some of these fixes are related to functionality whereas others are to improve performance. The changes sometimes required creation of new user configurable properties in order to extract the optimal-performance/desired-behavior depending on the users deployment. This article tries to explain some of the properties/attributes that were introduced in SailFin 2.0 to address specific issues.

Note : Not all these properties have been tested and certified.  Hence use them at your own risk. Please refer to the product documentation if you are using a supported version.

Configuration related to DNS failover functionality :

DNS failover is implemented in SailFin as per RFC 3263, it ensures that if the SIP message cannot be sent to the first host obtained from a DNS lookup then the next in the list has to be used to send the message. In case of UDP, to detect a message delivery failure at the network layer, we rely on the fact that an ICMP error response was received for the host that is not reachable. If for some reason (firewall or other) the ICMP error responses do no arrive , then we have to fall-back to the mechanism based on Timer B/F (defaults to 32) expiry to perform the retry. For sake of brevity lets call the former as fail-fast and the later as fail-safe. To implement the fail-fast solution, SailFin maintains a list of hosts for which a ICMP eror was received, and before sending a UDP message the destination address is checked with this list to find out if its reachable, if its not then a 503 is returned back which results in a DNS lookup and a new host being picked up. There is a duration for which a unreachable host lives in this list, after which it is removed and ready to be used, and this duration by default is 0 seconds (or the fail-fast is turned off). To enable the fail-fast DNS failover , one has to configure the stale connections timeout in the configuration

asadmin set server-config.sip-service.property.udpStaleConnectionsTimeout=5

The above command sets the connections to be removed after 5 seconds. This property is owned by the network layer and is used by it to track failed targets. Other modules in sailfin (like the resolver manager) have their own mechanism of tracking failed targets, like the one mentioned below.

For deployments where the ICMP responses do not reach the SailFin instance, one has to rely on the fail safe approach for accomplishing DNS failover.  When sending of a UDP message times out with Timer B firing then it is added to a global quarantine list of failed hosts, this is to ensure that other requests do not use the same failed target, and again a host is quarantined only for a certain duration.
The quarantine time is made configurable and split into two defaults; one for 503's received from the network layer (as descirbed above) and one for 408's from Timer B/F. The reason is that 408's already did a lot of retries and expectation is that such a situation will last longer.

Following command sets the quarantime timeout for 503s,

   asadmin set server-config.sip-container.property.defaultQuarantineTime=5

Following command sets the quarantine timeout for 408s

asadmin set server-config.sip-container.property.timeoutBasedQuarantineTime=5

Refer to issues

Converged Load Balancer configuration (for Http):The converged load balancer proxy creates TCP connections from a front-end (instance which receives the request) to the back-end (instances that processes it) to proxy the Http request. And this connection is pooled and re-used once the response has been sent back to the client. Having one connection to proxy all the requests may not scale well and allowing the proxy to create unlimited number of connections is also not an optimal solution. So, the number of connections that will be created and pooled can be configured by the user using the following system property (jvm-options) in SailFin.

asadmin create-jvm-options --target <your-config>  "\-Dorg.jvnet.glassfish.comms.clb.proxy.maxfebeconnections=10"

Default value is 20
This should be  an integer value of number of http proxy connections from the front end to backend.
This is a developer level property and may not be supported officially in the supported version of SailFin.

Converged Load Balancer configuration - Responses over UDP

UDP responses from the backend are routed back to the client through the front-end. If the deployment topology permits then it would be desirable to send the UDP responses directly back to the client (UA) from the backend where it gets processed, this would save one network hop (from backend to frontend). The below property can be used to achieve the functionality of by-passing the front-end for responses on UDP transport.

asadmin set domain.converged-lb-configs.<your-clb-config>.property.sendUDPResponseFromBackend=true.

This is a developer level property and may not be supported officially in the supported version of SailFin.

Network/Transaction related  - Using UDP listener address for outgoing requests:

By default SailFin uses the listener port as the source port to sends out UDP packets. But this could cause some issues in certain OSs. To disable this functionality, the user can set the above system property.

asadmin create-jvm-options --target <your-config> "\-Dorg.jvnet.glassfish.comms.disableUDPSourcePort=true"

This is a developer level property and may not be supported officially in the supported version of SailFin.

Transaction related : Drop invite re-transmissions.

UAC sends INVITE and SailFin responds back with 100, but before the 100 reaches the UAC, the UAC retransmits the INVITE. But before the re-transmitted invite reaches SailFin and can be processed, the transaction corresponding to the first invite is completed and a 200 is sent to the UAC. Thus the retransmitted invite results in  a new transaction in SailFin and when it reaches the servlet it ends up a creating a new INVIte to the UAS . The below property should be used if the user encounters the following case and wants to ensure that the re-transmitted invite is detected and ignored by SailFin.

asadmin create-jvm-options --target <your-config>


This is a developer level property and may not be supported officially in the supported version of SailFin.

Please refer to issue

Network Related : SSL handshake timeout.

asadmin set server-config.sip-service.property.sslHandshaketimeout =15

This integer value (in seconds) determines how long should the network layer in SailFin wait to complete the handshake with an SSL client. Default value is 10 seconds.

Ignoring user=phone parameter

The following is to avoid strict processing of user=phone parameter.
For more information, please see https://sailfin.dev.java.net/issues/show_bug.cgi?id=1716.

asadmin create-jvm-options --target <your-config>  \-Dorg.glassfish.sip.ignoreUserParameter=true


Microsoft OCS compatibility

System property to switch on some extensions to support microsoft OCS interoperability. It make
sure that the callid created by sailfin is less than 32 characters.
More information at https://sailfin.dev.java.net/issues/show_bug.cgi?id=1611

asadmin create-jvm-options --target <your-config> \ -Dorg.glassfish.sip.ocsInteroperable=true


Optional JSR 289 features - Modification of from/to headers.

System property to enable the optional 289 feature to modify from/to headers. More information at https://sailfin.dev.java.net/issues/show_bug.cgi?id=1641


asadmin create-jvm-options --target <your-config>  \-Dorg.glassfish.sip.allowFromChange=true



This is a debug aid to print debug information about a response created in the sailfin VM
(either by application). For the specified response code, sailfin will print debug information
including a stack trace when the response is created.

asadmin create-jvm-options --target <your-config>  \-Dorg.glassfish.sip.debugResponse=XXX