Trunking Requirements

Pattern sent to 9Line must be "911" or "933"

Each environment may require customized digit manipulation to route calls correctly. Ensure that dial peers are configured to match the appropriate called numbers (e.g., 911 and 933 for testing) and that any required transformations are applied for proper routing.

Calls not matching these patterns will be rejected; however, the INVITE will be logged in the 9Line portal's Call Logs for troubleshooting purposes.

TCP must be used for call signaling

Session Border Controllers (SBCs) may fragment large INVITE messages. If these fragmented packets arrive out of order, the INVITE message becomes unusable when using UDP as the transport. Because UDP lacks mechanisms for reordering packets, fragmentation can lead to failures in message reconstruction.

With TCP-based connections, the SBC can reassemble fragmented packets in the correct order, ensuring the integrity of the INVITE message.

Calls must be presented with the G.711ulaw codec

G.711ulaw is required for calls to the 9Line service. You must remove all other audio and all video codecs from the SIP INVITE as this can lead to the call being rejected or no audio on a call.

You can easily verify what codecs are being offered as a record of the INVITE we received is present on each call in the Call Logs section of the 9Line portal.

Use NAT and SIP message manipulation for public-to-private IPv4 mapping

To facilitate communication with 9Line, your network firewall must perform Network Address Translation (NAT) on IPv4 packets. This process will change the source IP address of the Session Border Controller (SBC) to a public IP address, allowing external connectivity.

Additionally, your SBC must handle SIP message manipulation to replace any internal private IP addresses with the public IP address in all SIP messages. This ensures that all messages appear to originate from the public IP, maintaining compatibility with external networks and preventing exposure of internal network details.

NAT and SIP Header Manipulation for Callback Compatibility

If using a 1-legged SBC configuration, configure SIP message manipulation to adjust the SIP-Req-URI header to map the external IP to the internal IP for callback calls. This is critical to prevent callback failures due to IP mismatches.

SIP Header Passing for HELD Compliance

Ensure that unsupported SIP headers are passed if HELD (HTTP-Enabled Location Delivery) is required. This allows the inclusion of location information within SIP messages for compliance with emergency calling standards.

Ensure DTMF Relay Configuration for SIP INVITE

The configuration should include RFC2833-compatible DTMF Relay. This format is known as Realtime Transport Protocol (RTP) Named Telephone Events (NTE) and is the only format supported for DTMF signals to be correctly relayed.

Use SIP Keepalives for Failover

When an SBC fails or becomes unreachable, it can cause disruptions to emergency calls. To minimize such disruptions and ensure high availability, we require the use of SIP OPTIONS keep-alive messages between your SBCs and ours.

SIP OPTIONS is a method defined in the SIP protocol that allows SIP devices to check the availability of other SIP devices. By sending periodic SIP OPTIONS messages between SBCs, you can detect and respond to failures or changes in network conditions more quickly than relying on passive monitoring or periodic polling. This can help reduce downtime and improve the overall quality of service.

To enable SIP OPTIONS keep-alive messages between your SBCs and ours, you should follow these steps:

1. Configure your SBCs to send SIP OPTIONS messages to 9Line SBCs regularly. The interval should be set based on the expected maximum network delay and the desired level of responsiveness. As general guidance, most customers have chosen an interval between 15 to 30 seconds.
2. 9Line SBCs will respond to SIP OPTIONS messages with a 200 OK response code. This indicates that the SBC is reachable and functioning properly. If the SBC is not reachable or is experiencing issues, it may respond with a different response code, such as 4xx or 5xx, indicating the reason for the failure.
3. During maintenance windows, 9Line will respond with a 503 Service Unavailable message. Your SBC must be configured to send the call to the next 9Line SBC cluster to ensure calls will failover.
4. Depending on the reason for the non-200 OK response, your SBCs will take different actions, such as rerouting traffic to a backup 9Line SBC or triggering an alarm. Many SBCs will detect non-200 OK messages and fail a route by default, but please confirm this operation with your SBC vendor.

By using SIP OPTIONS keep-alive messages, you can improve the reliability and availability of your SIP-based network, reduce the risk of disruptions, and enhance the overall quality of service.