Examples of gov.nist.javax.sip.SipStackImpl

• gov.nist.javax.sip.SipStackImpl
  Implementation of SipStack. The JAIN-SIP stack is initialized by a set of properties (see the JAIN SIP documentation for an explanation of these properties {@link javax.sip.SipStack} ). In addition to these, the following aremeaningful properties for the NIST SIP stack (specify these in the property array when you create the JAIN-SIP statck):

  • gov.nist.javax.sip.TRACE_LEVEL = integer
    Use of this property is still supported but deprecated. Please use gov.nist.javax.sip.STACK_LOGGER and gov.nist.javax.sip.SERVER_LOGGER for integration with logging frameworks and for custom formatting of log records. This property is used by the built in log4j based logger. You can use the standard log4j level names here (i.e. ERROR, INFO, WARNING, OFF, DEBUG, TRACE) If this is set to INFO or above, then incoming valid messages are logged in SERVER_LOG. If you set this to 32 and specify a DEBUG_LOG then vast amounts of trace information will be dumped in to the specified DEBUG_LOG. The server log accumulates the signaling trace. This can be viewed using the trace viewer tool . Please send us both the server log and debug log when reporting non-obvious problems. You can also use the strings DEBUG or INFO for level 32 and 16 respectively. If the value of this property is set to LOG4J, then the effective log levels are determined from the log4j settings file (e.g. log4j.properties). The logger name for the stack is specified using the gov.nist.javax.sip.LOG4J_LOGGER_NAME property. By default log4j logger name for the stack is the same as the stack name. For example, properties.setProperty("gov.nist.javax.sip.TRACE_LEVEL", "LOG4J"); properties.setProperty("gov.nist.javax.sip.LOG4J_LOGGER_NAME", "SIPStackLogger"); allows you to now control logging in the stack entirely using log4j facilities.
  • gov.nist.javax.sip.LOG_FACTORY = classpath Use of this property is still supported but deprecated. Please use gov.nist.javax.sip.STACK_LOGGER and gov.nist.javax.sip.SERVER_LOGGER for integration with logging frameworks and for custom formatting of log records.
    The fully qualified classpath for an implementation of the MessageLogFactory. The stack calls the MessageLogFactory functions to format the log for messages that are received or sent. This function allows you to log auxiliary information related to the application or environmental conditions into the log stream. The log factory must have a default constructor.
  • gov.nist.javax.sip.SERVER_LOG = fileName
    Use of this property is still supported but deprecated. Please use gov.nist.javax.sip.STACK_LOGGER and gov.nist.javax.sip.SERVER_LOGGER for integration with logging frameworks and for custom formatting of log records. Log valid incoming messages here. If this is left null AND the TRACE_LEVEL is above INFO (or TRACE) then the messages are printed to stdout. Otherwise messages are logged in a format that can later be viewed using the trace viewer application which is located in the tools/tracesviewer directory. Mail this to us with bug reports.
  • gov.nist.javax.sip.DEBUG_LOG = fileName Use of this property is still supported but deprecated. Please use gov.nist.javax.sip.STACK_LOGGER and gov.nist.javax.sip.SERVER_LOGGER for integration with logging frameworks and for custom formatting of log records.
    Where the debug log goes. Mail this to us with bug reports.
  • gov.nist.javax.sip.LOG_MESSAGE_CONTENT = true|false
    Set true if you want to capture content into the log. Default is false. A bad idea to log content if you are using SIP to push a lot of bytes through TCP.
  • gov.nist.javax.sip.LOG_STACK_TRACE_ON_MESSAGE_SEND = true|false
    Set true if you want to to log a stack trace at INFO level for each message send. This is really handy for debugging.
  • gov.nist.javax.sip.STACK_LOGGER = full path name to the class implementing gov.nist.core.StackLogger interface
    If this property is defined the sip stack will try to instantiate it through a no arg constructor. This allows to use different logging implementations than the ones provided by default to log what happens within the stack while processing SIP messages. If this property is not defined, the default sip stack LogWriter will be used for logging
  • gov.nist.javax.sip.SERVER_LOGGER = full path name to the class implementing gov.nist.core.ServerLogger interface
    If this property is defined the sip stack will try to instantiate it through a no arg constructor. This allows to use different logging implementations than the ones provided by default to log sent/received messages by the sip stack. If this property is not defined, the default sip stack ServerLog will be used for logging
  • gov.nist.javax.sip.AUTOMATIC_DIALOG_ERROR_HANDLING = [true|false]
    Default is true. This is also settable on a per-provider basis. This flag is set to true by default. When set to false the following behaviors are enabled:
    • Turn off Merged requests Loop Detection:
      The following behavior is turned off: If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction.
  • gov.nist.javax.sip.IS_BACK_TO_BACK_USER_AGENT = [true|false]
    Default is false This property controls a setting on the Dialog objects that the stack manages. Pure B2BUA applications should set this flag to true. This property can also be set on a per-dialog basis. Setting this to true imposes serialization on re-INVITE and makes the sending of re-INVITEs asynchronous. The sending of re-INVITE is controlled as follows : If the previous in-DIALOG request was an invite ClientTransaction then the next re-INVITEs that uses the dialog will wait till an ACK has been sent before admitting the new re-INVITE. If the previous in-DIALOG transaction was a INVITE ServerTransaction then Dialog waits for ACK before re-INVITE is allowed to be sent. If a dialog is not ACKed within 32 seconds, then the dialog is torn down and a BYE sent to the peer.
  • gov.nist.javax.sip.MAX_MESSAGE_SIZE = integer
    Maximum size of content that a TCP connection can read. Must be at least 4K. Default is "infinity" -- ie. no limit. This is to prevent DOS attacks launched by writing to a TCP connection until the server chokes.
  • gov.nist.javax.sip.DELIVER_TERMINATED_EVENT_FOR_NULL_DIALOG = [true|false]
    If set to false (the default), the application does NOT get notified when a Dialog in the NULL state is terminated. ( Dialogs in the NULL state are not associated with an actual SIP Dialog. They are a programming convenience. A Dialog is in the NULL state before the first response for the Dialog forming Transaction). If set to true, the SipListener will get a DialogTerminatedEvent when a Dialog in the NULL state is terminated.
  • gov.nist.javax.sip.CACHE_SERVER_CONNECTIONS = [true|false]
    Default value is true. Setting this to false makes the Stack close the server socket after a Server Transaction goes to the TERMINATED state. This allows a server to protectect against TCP based Denial of Service attacks launched by clients (ie. initiate hundreds of client transactions). If true (default action), the stack will keep the socket open so as to maximize performance at the expense of Thread and memory resources - leaving itself open to DOS attacks.
  • gov.nist.javax.sip.CACHE_CLIENT_CONNECTIONS = [true|false]
    Default value is true. Setting this to false makes the Stack close the server socket after a Client Transaction goes to the TERMINATED state. This allows a client release any buffers threads and socket connections associated with a client transaction after the transaction has terminated at the expense of performance.
  • gov.nist.javax.sip.THREAD_POOL_SIZE = integer
    Concurrency control for number of simultaneous active threads. If unspecificed, the default is "infinity". This feature is useful if you are trying to build a container.
    • If this is not specified, and the listener is re-entrant, each event delivered to the listener is run in the context of a new thread.
    • If this is specified and the listener is re-entrant, then the stack will run the listener using a thread from the thread pool. This allows you to manage the level of concurrency to a fixed maximum. Threads are pre-allocated when the stack is instantiated.
    • If this is specified and the listener is not re-entrant, then the stack will use the thread pool thread from this pool to parse and manage the state machine but will run the listener in its own thread.
  • gov.nist.javax.sip.REENTRANT_LISTENER = true|false
    Default is false. Set to true if the listener is re-entrant. If the listener is re-entrant then the stack manages a thread pool and synchronously calls the listener from the same thread which read the message. Multiple transactions may concurrently receive messages and this will result in multiple threads being active in the listener at the same time. The listener has to be written with this in mind. If you want good performance on a multithreaded machine write your listener to be re-entrant and set this property to be true
  • gov.nist.javax.sip.MAX_CONNECTIONS = integer
    Max number of simultaneous TCP connections handled by stack.
  • gov.nist.javax.sip.MAX_SERVER_TRANSACTIONS = integer
    Maximum size of server transaction table. The low water mark is 80% of the high water mark. Requests are selectively dropped in the lowater mark to highwater mark range. Requests are unconditionally accepted if the table is smaller than the low water mark. The default highwater mark is 5000
  • gov.nist.javax.sip.MAX_CLIENT_TRANSACTIONS = integer
    Max number of active client transactions before the caller blocks and waits for the number to drop below a threshold. Default is unlimited, i.e. the caller never blocks and waits for a client transaction to become available (i.e. it does its own resource management in the application).
  • gov.nist.javax.sip.PASS_INVITE_NON_2XX_ACK_TO_LISTENER = true|false
    If true then the listener will see the ACK for non-2xx responses for server transactions. This is not standard behavior per RFC 3261 (INVITE server transaction state machine) but this is a useful flag for testing. The TCK uses this flag for example.
  • gov.nist.javax.sip.MAX_LISTENER_RESPONSE_TIME = Integer
    Max time (seconds) before sending a response to a server transaction. If a response is not sent within this time period, the transaction will be deleted by the stack. Default time is "infinity" - i.e. if the listener never responds, the stack will hang on to a reference for the transaction and result in a memory leak.
  • gov.nist.javax.sip.DELIVER_TERMINATED_EVENT_FOR_ACK = [true|false]
    Default is false. ACK Server Transaction is a Pseuedo-transaction. If you want termination notification on ACK transactions (so all server transactions can be handled uniformly in user code during cleanup), then set this flag to true.
  • gov.nist.javax.sip.READ_TIMEOUT = integer
    This is relevant for incoming TCP connections to prevent starvation at the server. This defines the timeout in miliseconds between successive reads after the first byte of a SIP message is read by the stack. All the sip headers must be delivered in this interval and each successive buffer must be of the content delivered in this interval. Default value is -1 (ie. the stack is wide open to starvation attacks) and the client can be as slow as it wants to be.
  • gov.nist.javax.sip.NETWORK_LAYER = classpath
    This is an EXPERIMENTAL property (still under active devlopment). Defines a network layer that allows a client to have control over socket allocations and monitoring of socket activity. A network layer should implement gov.nist.core.net.NetworkLayer. The default implementation simply acts as a wrapper for the standard java.net socket layer. This functionality is still under active development (may be extended to support security and other features).
  • gov.nist.javax.sip.ADDRESS_RESOLVER = classpath
    The fully qualified class path for an implementation of the AddressResolver interface. The AddressResolver allows you to support lookup schemes for addresses that are not directly resolvable to IP adresses using getHostByName. Specifying your own address resolver allows you to customize address lookup. The default address resolver is a pass-through address resolver (i.e. just returns the input string without doing a resolution). See gov.nist.javax.sip.DefaultAddressResolver.
  • gov.nist.javax.sip.AUTO_GENERATE_TIMESTAMP= [true| false]
    (default is false) Automatically generate a getTimeOfDay timestamp for a retransmitted request if the original request contained a timestamp. This is useful for profiling.
  • gov.nist.javax.sip.THREAD_AUDIT_INTERVAL_IN_MILLISECS = long
    Defines how often the application intends to audit the SIP Stack about the health of its internal threads (the property specifies the time in miliseconds between successive audits). The audit allows the application to detect catastrophic failures like an internal thread terminating because of an exception or getting stuck in a deadlock condition. Events like these will make the stack inoperable and therefore require immediate action from the application layer (e.g., alarms, traps, reboot, failover, etc.) Thread audits are disabled by default. If this property is not specified, audits will remain disabled. An example of how to use this property is in src/examples/threadaudit.
  • gov.nist.javax.sip.COMPUTE_CONTENT_LENGTH_FROM_MESSAGE_BODY = [true|false]
    Default is false If set to true, when you are creating a message from a String, the MessageFactory will compute the content length from the message content and ignore the provided content length parameter in the Message. Otherwise, it will use the content length supplied and generate a parse exception if the content is truncated.
  • gov.nist.javax.sip.CANCEL_CLIENT_TRANSACTION_CHECKED = [true|false]
    Default is true. This flag is added in support of load balancers or failover managers where you may want to cancel ongoing transactions from a different stack than the original stack. If set to false then the CANCEL client transaction is not checked for the existence of the INVITE or the state of INVITE when you send the CANCEL request. Hence you can CANCEL an INVITE from a different stack than the INVITE. You can also create a CANCEL client transaction late and send it out after the INVITE server transaction has been Terminated. Clearly this will result in protocol errors. Setting the flag to true ( default ) enables you to avoid common protocol errors.
  • gov.nist.javax.sip.IS_BACK_TO_BACK_USER_AGENT = [true|false]
    Default is false This property controls a setting on the Dialog objects that the stack manages. Pure B2BUA applications should set this flag to true. This property can also be set on a per-dialog basis. Setting this to true imposes serialization on re-INVITE and makes the sending of re-INVITEs asynchronous. The sending of re-INVITE is controlled as follows : If the previous in-DIALOG request was an invite ClientTransaction then the next re-INVITEs that uses the dialog will wait till an ACK has been sent before admitting the new re-INVITE. If the previous in-DIALOG transaction was a INVITE ServerTransaction then Dialog waits for ACK before re-INVITE is allowed to be sent. If a dialog is not ACKed within 32 seconds, then the dialog is torn down and a BYE sent to the peer.
  • gov.nist.javax.sip.RECEIVE_UDP_BUFFER_SIZE = int
    Default is 8*1024. This property control the size of the UDP buffer used for SIP messages. Under load, if the buffer capacity is overflown the messages are dropped causing retransmissions, further increasing the load and causing even more retransmissions. Good values to this property for servers is a big number in the order of 8*8*1024.
  • gov.nist.javax.sip.SEND_UDP_BUFFER_SIZE = int
    Default is 8*1024. This property control the size of the UDP buffer used for SIP messages. Under load, if the buffer capacity is overflown the messages are dropped causing retransmissions, further increasing the load and causing even more retransmissions. Good values to this property for servers is a big number in the order of 8*8*1024 or higher.
  • gov.nist.javax.sip.CONGESTION_CONTROL_ENABLED = boolean Defailt is true. If set to true stack will enforce queue length limitation for UDP. The Max queue size is 5000 messages. The minimum queue size is 2500 messages.
  • gov.nist.javax.sip.TCP_POST_PARSING_THREAD_POOL_SIZE = integer Use 0 or do not set this option to disable it. When using TCP your phones/clients usually connect independently creating their own TCP sockets. Sometimes however SIP devices are allowed to tunnel multiple calls over a single socket. This can also be simulated with SIPP by running "sipp -t t1". In the stack each TCP socket has it's own thread. When all calls are using the same socket they all use a single thread, which leads to severe performance penalty, especially on multi-core machines. This option instructs the SIP stack to use a thread pool and split the CPU load between many threads. The number of the threads is specified in this parameter. The processing is split immediately after the parsing of the message. It cannot be split before the parsing because in TCP the SIP message size is in the Content-Length header of the message and the access to the TCP network stream has to be synchronized. Additionally in TCP the message size can be larger. This causes most of the parsing for all calls to occur in a single thread, which may have impact on the performance in trivial applications using a single socket for all calls. In most applications it doesn't have performance impact. If the phones/clients use separate TCP sockets for each call this option doesn't have much impact, except the slightly increased memory footprint caused by the thread pool. It is recommended to disable this option in this case by setting it 0 or not setting it at all. You can simulate multi-socket mode with "sipp -t t0". With this option also we avoid closing the TCP socket when something fails, because we must keep processing other messages for other calls. Note: This option relies on accurate Content-Length headers in the SIP messages. It cannot recover once a malformed message is processed, because the stream iterator will not be aligned any more. Eventually the connection will be closed.
  • gov.nist.javax.sip.DELIVER_UNSOLICITED_NOTIFY = [true|false]
    Default is false. This flag is added to allow Sip Listeners to receive all NOTIFY requests including those that are not part of a valid dialog.
  • gov.nist.javax.sip.REJECT_STRAY_RESPONSES = [true|false] Default is false A flag that checks responses to test whether the response corresponds to a via header that was previously generated by us. Note that setting this flag implies that the stack will take control over setting the VIA header for Sip Requests sent through the stack. The stack will attach a suffix to the VIA header branch and check any response arriving at the stack to see if that response suffix is present. If it is not present, then the stack will silently drop the response.
  • gov.nist.javax.sip.MAX_FORK_TIME_SECONDS = integer Maximum time for which the original transaction for which a forked response is received is tracked. This property is only relevant to Dialog Stateful applications ( User Agents or B2BUA). When a forked response is received in this time interval from when the original INVITE client transaction was sent, the stack will place the original INVITE client transction in the ResponseEventExt and deliver that to the application. The event handler can get the original transaction from this event.
  • gov.nist.javax.sip.MESSAGE_PARSER_FACTORY = name of the class implementing gov.nist.javax.sip.parser.MessageParserFactory This factory allows pluggable implementations of the MessageParser that will take care of parsing the incoming messages. By example one could plug a lazy parser through this factory.
  • gov.nist.javax.sip.MESSAGE_PROCESSOR_FACTORY = name of the class implementing gov.nist.javax.sip.parser.MessageProcessorFactory This factory allows pluggable implementations of the MessageProcessor that will take care of incoming messages. By example one could plug a NIO Processor through this factory.
  • gov.nist.javax.sip.DELIVER_RETRANSMITTED_ACK_TO_LISTENER=boolean A testing property that allows application to see the ACK for retransmitted 200 OK requests. Note that this is for test purposes only
  • gov.nist.javax.sip.MIN_KEEPALIVE_TIME_SECONDS = integer Minimum time between keep alive pings (CRLF CRLF) from clients. If pings arrive with less than this frequency they will be replied with CRLF CRLF if greater they will be rejected. The default is -1 (i.e. do not respond to CRLF CRLF).
  • gov.nist.javax.sip.DIALOG_TIMEOUT_FACTOR= integer Default to 64. The number of ticks before a dialog that does not receive an ACK receives a Timeout notification. Note that this is only relevant if the registered SipListener is of type SipListenerExt
  • gov.nist.javax.sip.TLS_CLIENT_PROTOCOLS = String Comma-separated list of protocols to use when creating outgoing TLS connections. The default is "SSLv3, SSLv2Hello, TLSv1". Some servers do not support SSLv2Hello, so override to "SSLv3, TLSv1".
  • gov.nist.javax.sip.TLS_SECURITY_POLICY = String The fully qualified path name of a TLS Security Policy implementation that is consulted for certificate verification of outbund TLS connections.
  • javax.net.ssl.keyStore = fileName
    Default is NULL. If left undefined the keyStore and trustStore will be left to the java runtime defaults. If defined, any TLS sockets created (client and server) will use the key store provided in the fileName. The trust store will default to the same store file. A password must be provided to access the keyStore using the following property:
    properties.setProperty("javax.net.ssl.keyStorePassword", "<password>");
    The trust store can be changed, to a separate file with the following setting:
    properties.setProperty("javax.net.ssl.trustStore", "<trustStoreFileName location>");
    If the trust store property is provided the password on the trust store must be the same as the key store.
    
    

  Note that the stack supports the extensions that are defined in SipStackExt. These will be supported in the next release of JAIN-SIP. You should only use the extensions that are defined in this class. @version 1.2 $Revision: 1.125.2.1 $ $Date: 2010/07/01 18:24:27 $ @author M. Ranganathan
  

Related Classes of gov.nist.javax.sip.SipStackImpl