SIP Proxy Support

Warning

This documentation is outdated and is included for historical purposes only.

SIP Endpoint SDK can now be used with Genesys SIP Proxy, which provides high availability without requiring a virtual IP address.

Configuration

Domain Names

SRV records are not currently supported by SIP Endpoint SDK, which supports only A (or AAAA) records. Because of this, Genesys SIP Proxies should be configured with a single fully qualified domain name (FQDN) that resolves via DNS into multiple IP addresses via A (or AAAA) records in DNS server.

For information on how to configure SIP Proxy, consult the SIP Proxy Deployment Guide.

SIP Transaction Timeout

Name	Description	Valid Values	Default	Recommended
sip_transaction_timeout	SIP transaction timeout value in milliseconds.	1 through 32000	32000 (32 seconds)	4000 (4 seconds)

Because the default SIP transaction timeout value is too long for use by customer-facing applications, Genesys strongly recommends that you set the sip_transaction_timeout value to 4000, as shown here:

 <domain name="policy">
   <section name="endpoint">
	...
     <setting name="sip_transaction_timeout" value="4000"/>
	...
   </section>

Limitations

• Genesys SIP Proxy does not support scenarios involving switchovers in mid-transaction. Because of this, call answer and CANCEL may not work properly in such situations. In particular, the incoming call cannot be answered under these circumstances and must be released. Also, the outgoing call may be stuck on SIP Server for an unpredictable length of time. (Please note that this is a limitation of Genesys SIP Proxy and not of SIP Endpoint SDK.)
• You must configure the reg_interval parameter (in the SIP Endpoint configuration file) to a positive value (for example, 30) if you want your SIP Endpoint to resend REGISTER and SUBSCRIBE messages to a new SIP Proxy when the current SIP Proxy is down. SIP Endpoint does not resend the REGISTER or SUBSCRIBE if reg_interval is configured to 0.
• The SIP Endpoint SDK always retries INVITE once, regardless of the number of proxies configured.

Technical Background

The following background information describes certain features of the SIP Endpoint SDK internals that might be helpful in planning your application.

Warning

This information is subject to change without notice and is not supported by Genesys.

High Availability

Because the SIP Endpoint SDK already supports DNS queries for each transaction, the load balancing aspect of High Availability is already taken care of, although it may require configuring an IP address rotation in DNS server. The missing parts for High Availability support are:

• Temporarily blacklisting the IP address on failure (no response), so the next SIP message is sent to a different proxy: The proposed method for this assigns a specific penalty to each IP address in the list from the DNS, based on how recently that IP address has failed. When a selection must be made, the one with the lowest penalty value is chosen. If there are no penalty-free IP addresses, the algorithm chooses the least-recently blacklisted address, which may now be available. Because of this algorithm, there is not much sense in making the blacklist interval configurable, and it is currently hard-coded to 10 minutes. (After that, the address is fully cleared and can be tried again).

• You must set the sip_transaction_timeout parameter to a value less than 32000 milliseconds, as described in the Configuration section above, with the recommended setting being 4000.

• Automatic re-transmission of failed (timed out) SIP messages to a new proxy: Given the current GSIPLIB architecture, this re-transmission must be done separately for each message type. Thus, it must be tested for all possible use cases, notably:
  • REGISTER and SUBSCRIBE renewal—by design, switching to a new SIP proxy obeys the configured reg_interval parameter, so if re-registration is disabled by a value of 0, the endpoint does not resend the REGISTER or SUBSCRIBE message.
  • Initial INVITE to be retried once to a different SIP proxy (and reported as failed in case of a double failure).
    Note: To give application code full visibility to the SIP call ID , an in-progress state is reported twice for the same session ID (with the state reported as disconnected in between them).
  • Mid-call INVITE for Hold and Retrieve operations to be retried once, transparent to application code.
  • Retrying a 200 OK response to an initial INVITE (answering the call) and call-terminating BYE and CANCEL requests work differently from other requests. These retry operations work only when the sip_transaction_timeout parameter is set to a value lower than 32000 milliseconds (as described in the Configuration section above), with the recommended setting being 4000. These requests are retried continuously for 32 seconds total (cycling throught the list of configured proxies), after which the call is abandoned.

ICMP Messages

It is not currently possible to intercept ICMP messages using GSIPLIB, because exceptions are processed on the transport level, but the reaction must be implemented on the transaction level and there is no easy way to pass control between those two levels. Because of this, these failures may be detected in the current release by timeout only. This is not much of a limitation, however, as ICMP messages are generated only when:

• The server is on Windows
• No firewall is blocking them
• The host is alive

Therefore, these messages are unreliable and their use would add very little to the timeout method.