Summary

This guide will walk you through configuring and verifying SRV records for SIP (Session Initiation Protocol) settings in our Target Platform Integration (TPI) settings for our CCaaS platform.

We’ll cover the importance of SRV records, how to test them, and the protocol options available.

• Some context, up to this point we had a feature toggle called [RESTART]LOOKUP_DNS_SRV_RECORD . With this new release, we won’t need to utilize this feature toggle to enable SRV lookup. In the screenshot below you’ll see that this setting now exists by default in the TPI settings

SRV Record vs. SIP Outbound Proxy

When setting up a customer, we have two options for SIP server connection in the UCaaS Platform Settings:

1. SRV Record
   1. Use this if specified. If an SRV Record is entered in the settings, it will take precedence over the SIP Outbound Proxy.
   2. Purpose: The SRV Record directs traffic based on the priority and weight of available servers, providing flexibility and reliability through failover and load balancing
   3. Action: Perform an SRV lookup before registering any handset when an SRV Record is provided
2. SIP Outbound Proxy
   1. If the SRV Record is left blank, we default to the SIP Outbound Proxy for the connection
   2. Purpose: This provides a static connection endpoint, typically used if SRV is not available or supported

Best Practice: Always prioritize the SRV Record if available, as it enhances system resilience and load management

This newest build with include both of these options - Here is an example: (note that the SRV is actually an option now)

Testing SRV Records

To ensure the SRV Record is configured correctly, it’s essential to test it before deploying a customer. Here are two tools that are particularly useful for SRV verification:

1. nslookup.io SRV Lookup
   1. Why Use It: This tool sorts results by priority and weight, which is important for understanding the server hierarchy in failover situations
   2. Ideal For: When you need a prioritized list of servers from the SRV record
2. MXToolbox SRV Lookup:
   1. Why Use It: Allows testing of multiple SRV records and displays recent searches, making it easy to compare results
   2. Ideal For: When testing several SRV records or when you want to quickly access previous test results

Example SRV Record Format in Netsapiens

• For our Netsapiens setup, SIP settings will often include SRV records in the format _sip._tcp."domain". Always verify these SRV records with one of the tools above to confirm their priority, weight, and reachability

Verifying SRV Record Support

• To check if a service provider supports SRV, enter an SRV record based on the Outbound Proxy URL in one of the testing tools. For example, for Viirtue, you would try the following SRV records:
  • _sip._tls.core2-nj.syntelsolutions.com
  • _sip._tls.core2-nj.syntelsolutions.com
  • _sip._udp.core2-nj.syntelsolutions.com
• SRV Record Format
  • _sip: Indicates that the request is for SIP services
  • Protocol: Specifies _tls, _tcp, or _udp depending on the connection type.
  • Domain: The domain provided by the PBX, such as core2-nj.syntelsolutions.com
    • NOTE: This is specific to our Netsapiens/Viirtue platform. You’ll need to work with your platform or partner to get the outbound proxy of the respective system you want to integrate with.
  • By testing these records in one of the recommended tools, you can determine whether SRV support is available. If supported, the tool will return server details, including priority and weight. (See Selecting Servers Based on Priority and Weight Below)

Selecting Servers Based on Priority and Weight

• Netsapiens supports all three SIP protocols (TCP, UDP, and TLS). See the below examples using the tools I’ve outlined above

  

  

  

  
  

• NOTE: These are just examples of what it looks like if SRV is supported. Our codebase will automatically do what item 2 “server selection” outlines below. All you will have to do is enter in the corresponding SRV content, such as _sip._tcp.core2-nj.syntelsolutions.com

Here’s how to use this information effectively in the SRV Record field:

1. Selecting Protocol:
   1. If using TCP, enter _sip._tcp.core2-nj.syntelsolutions.com in the SRV Record field within the TPI settings
   2. For TLS and UDP, use _sip._tls and _sip._udp formats, respectively
2. Server Selection:
   1. Priority: Choose the server with the lowest priority first.
   2. Weight: If multiple servers have the same priority, refer to their weight to determine load distribution. A higher weight indicates a preference for that server
   3. Example: If two servers have priority 0 but weights of 50 and 100, the server with weight 100 should ideally handle more traffic
3. Current Code Behavior:
   1. Our system is currently set to select only the lowest priority server with the highest weight available

• This approach simplifies server selection and prioritizes connection stability

Protocol Options for SRV Testing

• In SRV testing, you can use any of the following protocol variations. However, we primarily rely on _sip._tls. or _sip._tcp. in our configurations
  • Available protocol formats for SRV testing:
    • _sip._tls.
    • _sip2._tls.
    • _sip._tcp.
    • _sips._tcp.
    • _sip._udp.
    • _sips._udp.
  • When entering these SRV records in the testing tools, you’ll confirm if SRV support is active based on the results returned
    • NOTE: If _sip._tls, or _sip._tcp doesn’t yield results and the claim of the customer is that SRV is supported, you may consider trying all of the variations as outlined above as they can differ by integration platform
      • _sips._tls for instance, though not our “typical”, still might yield results when _sip._tls does not

By following this guide, you should be able to effectively set up, verify, and troubleshoot SRV records in the TPI settings for our CCaaS platform.

This ensures a more resilient and flexible configuration with automatic failover and load balancing capabilities where SRV is supported.

SIP trunk failover behavior with SRV records

This article describes how Xima handles SIP REGISTER failover when configured against an SRV record with multiple targets. It is intended for carriers, ITSPs, and integrators connecting Xima to a hosted SIP platform such as Broadworks.

SRV record handling

Xima resolves the SRV record and uses the returned targets in priority order. Registration is attempted against the highest-priority target first; lower-priority entries are used only after a failover event.

Failover trigger

Xima rolls to the next SRV target after three consecutive failed REGISTER attempts against the current target. The rollover is driven entirely by this failure count; there is no timer governing when failover occurs, and no minimum or maximum interval that gates the decision.

The same rule applies at every level of the SRV list. If the secondary subsequently sees three consecutive failures, Xima rolls to the next entry — wrapping back to the primary in a two-entry SRV.

Failback behavior

Xima does not proactively probe higher-priority SRV targets after a failover. Once registration has moved to a secondary (or lower) target, it remains there as long as that target continues to register successfully. There is no failback timer, no periodic recovery check, and no configuration option to enable one.

This has two practical consequences:

1. No risk of double-registration on a recovered primary. Some PBXs require a hold-off (often around 3700 seconds) to avoid re-registering on a primary that has just recovered, which platforms like Broadworks may treat as a duplicate registration. Because Xima does not attempt to fail back, this hold-off pattern is not needed.
2. Registration is sticky to the failover target. If your deployment requires registration to return to the primary after recovery, this must be driven externally — for example by briefly removing the secondary from service to trigger the three-failure rollover.

Relationship to registration timers

The SIP re-REGISTER interval (the timer that governs how often Xima refreshes its registration with the current target) is a separate setting from the failover logic described above. Adjusting the re-REGISTER interval does not change when Xima rolls between SRV targets, and does not introduce or extend any failback hold-off.