Overview of SIP Connections

To access the basic settings of a connection, click the small edit icon on the far right of the desired connection at the SIP Connections tab in the Mission Control Portal.

If you are looking for a detailed overview of the inbound/outbound SIP Connection settings, please review this article for more information.

As seen below, you can distinguish your SIP Connections by giving them unique names. Each time you create a SIP Connection, it will have a universally unique identifier - this is mainly used for interacting with our API programmatically.

The basic settings have four different category's, each of which are described in detail below:

We offer three different authentication types to register your switch to ours. Deciding on what registration type to use depends on your use case. Please have a read of our SIP Connection Types article for more information on this section.

The connection event settings allows you to send all connection events to a webhook of your choice. If our system fails to deliver the webhook, it will send the event to your Failover URL.

There are 4 different events that can be sent:

NOTE: You will need to make sure that you use a call control application to control the call, using the SIP Connection ID to issue commands is not advised. Otherwise, whatever application you are using to receive these events should appropriately ensure that the SIP device responds over SIP signalling.

The Park Outbound Calls feature provides a simple mechanism for users to “park” their outbound calls instead of connecting them to their destination. The call then awaits further orders from its connected application.

Parked calls provide a ringback to the caller, waiting for a command via the Telnyx Call Control API to define the call action. Typical commands include answer, play audio, bridge to another call, and transfer to another number. You can learn more about Call Control commands in our Developer Docs.

The AnchorSite® settings allows the user to select the media server in which their calls are anchored. In most cases, the closer the server is to the user geographically, the better the latency. This setting defaults to Latency if not modified.

When the AnchorSite® is set to Latency, we will proactively monitor the latency from your endpoints to our points of presence (PoP) to determine where your media should be anchored in order to ensure your packets get off the internet as fast as possible.

Please note, there are limitations to selecting latency depending on the authentication type of your SIP Connection, whereby your calls may be anchored on a media server further away if we are unable to identify the latency between our media servers and the IP's associated with the SIP Connection, through ICMP requests from our network. Please make sure you whitelist our media IP addresses on your firewall as these will be used to check latency.

For credential based SIP Connections, please make sure to include the SIP Connections username in the contact header in your first SIP INVITE. This will allow our SIP Proxy to identify the settings associated with your SIP Connection and ensure the anchorsite selected is chosen. Again, if the username is not included in the first SIP INVITE attempt, there is no way for us to identify your SIP Connection in order to guarantee AnchorSite®.

This setting will encode the SIP contact header sent by Telnyx to avoid issues with NAT and ALG scenarios.

The DTMF Type setting allows the user to specify the type of DTMF to be used on the call. There are three different options:

The standards-based mechanism used to send DTMF digits in-band (RTP) that is supported by many vendors in the industry.

Sending of information within the same band or channel used for data such as voice or video. This option is the most prone to issues.

Used by SIP network elements to transmit digits out-of-band as telephone-events in a reliable manner independent of the media stream.

Enable on-net T.38 if you prefer the sender and receiver negotiating T.38 directly. If this is disabled, Telnyx will be able to use T.38 on just one leg of the call depending on each leg's settings.

When this option is checked, Telnyx will generate comfort noise when you place a call on hold. If this option is unchecked, you will need to generate comfort noise or on-hold music to avoid RTP timeouts.

RTP is used to transmit media between endpoints. As the media traverses the endpoints, RTCP packets are generated periodically by both the caller and the called party. However, unlike RTP, they don’t contain media. Instead, RTCP packets are used to report statistics about the ongoing call. Telnyx provides the ability to use either RTCP+1 or RTCP mux at the connection level.

The report frequency specifies the interval in seconds between sending RTCP packets back to the users media IP, while the call is in progress.

This setting defaults to RTCP+1. The other option, RTCP mux, is multiplexing both the RTP and RTCP through a single UDP port. One of the reasons why RTCP mux is used is for simplifying NAT traversal since only a single port is used for media and control messages.