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:

  • SIP Connection Type
  • Events
  • AnchorSite
  • Expert Settings

SIP Connection Type

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.

SIP Connection Events

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:

  • Call Initiated
  • Call Answered
  • Call Bridged
  • Call Hangup

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.

AnchorSite™

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 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.

SIP Expert Settings

Encode Contact Header

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

DTMF Types

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

  • RFC 2833
  • Inband
  • SIP Info

RFC 2833 (Recommended)

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

Inband

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.

SIP Info

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 Passthrough

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.

Enable Comfort Noise for Call on Hold

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.

RTCP Settings (Real-time Control Protocol)

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.

Report Frequency

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

RTCP Port

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.


Can't find what you're looking for? Click the chat bubble at your lower right-hand corner and talk to the support team!

Did this answer your question?