Configure your termination SIP Trunk

Configuring your termination SIP Trunk will allow you to make calls from your own IP-PBX, User account, or SIP Trunk. MessageBird provides routes for more than 100 countries.

In this article, we’ll show you the following:

Whitelisting

Whitelisting is used in our platform to make sure that the calls terminating on your SIP Trunk are from a trusted source i.e. the IP address(s) defined by you. Unknown IP traffic gets blocked by our SIP servers. You'll add your whitelisted IP addresses when you set up your ACL.

Digest Authentication

Digest Authentication: SIP RFC3261 uses the same mechanism used by the HTTP protocol for authenticating users, which is a simple challenge-response authentication mechanism that allows a server to challenge a client request and allows a client to provide authentication information in response to that challenge.

The SIP protocol uses the Digest Authentication scheme that is used with the HTTP authentication mechanism, which by default uses MD5 as the default algorithm.

When a UAS receives a request from a UAC, and an acceptable Authorization header is not sent, the UAS can challenge the originator to provide credentials by rejecting the request with a 401/407 status code with the WWW-Authenticate/Proxy-Authenticate header field. The UAS MAY include multiple WWW-Authenticate/Proxy-Authenticate headers to allow the UAS to utilize the best available algorithm supported by the client.

If the UAS challenges with multiple WWW-Authenticate/Proxy-Authenticate headers with the same realm, then each one of these headers MUST use a different digest algorithm. The UAS MUST add these headers to the response in the order that it would prefer to see them used, starting with the most preferred algorithm at the top, followed by the less preferred algorithms.

When the UAC receives a response with multiple headers with the same realm it SHOULD use the topmost header that it supports, unless a local policy dictates otherwise. The client MUST ignore any challenge it does not understand.

When the UAC receives a 401 response with multiple WWW-Authenticate headers with different realms it SHOULD retry and include an Authorization header containing credentials that match the topmost header of any one of the realms.

If the UAC cannot respond to any of the challenges in the response, then it should abandon attempts to send the request; e.g., if the UAC does not have credentials for any of the realms.

Set it up on your MessageBird Dashboard

Step 1: Create and configure an Access Control List (ACL)

First, we need to create an Access Control List (ACL). Once it's set up, you can add your own IP addresses and username/password accounts to control access.

NOTE: To manage the authentication of your VoIP infrastructure you can create multiple ACLs, each with one or more accounts.

Access Control List

  1. Log into your Dashboard, then click the Voice icon on the toolbar on the left-hand side of your screen. Select SIP Trunking from the menu that appears.

  2. Select Access Control from the menu on the left.

  3. Under Access control lists, Click Add new.

  4. A pop-up window will appear. In the Name field, enter a recognizable name for your access control list, e.g. ACL_OUTBOUND_SIP_TRUNK.

  5. Click Save.

IP Addresses

In this step, you'll whitelist your IP addresses by adding them to your ACL.

  1. In the IP Addresses section, click Add New. A pop-up window will appear. Enter the IP address that you would like to authenticate for the termination of SIP Trunking calls.

  2. Click Save.

  3. If you want to add more IP addresses, click on Add New and start the process again.

Accounts

In this step, you'll create and add accounts to your ACL.

  1. Next, scroll down to Accounts, then click Add New. A pop-up window will appear.

  2. In the Name field, enter a username for the user that you want to give access to.

  3. In the Password field, create a password for the user.

  4. Click Save.

NOTE: If you have entered both an IP address and a username/password, both need to be used in the SIP-INVITE header. Below, you’ll find an example of a FROM field as part of an SIP-INVITE header with the username 31000000:

SIP from address: sip:31000000@[yourdomain].sip.messagebird.com;transport+UDP

Step 2: Create your own subdomain

A subdomain is a personal DNS inside the MessageBird.com domain, such as yourcompany.sip.messagebird.com.

Only calls to this specific subdomain will be authenticated by the attached ACLs (created in the previous section.)

Follow these steps to add a subdomain:

  1. From the Voice page, click SIP Trunks.

  2. Next to Domains, click Add New.

  3. A pop-up will appear.

  4. In the Name field, enter the name of the subdomain that you want to use.

  5. In the Domain field, enter the address you want to use for your SIP communication. A valid domain name contains: - A minimum of one character. - Valid characters ranging from 0-9, a-z and A-Z.

  6. Click Save.

  7. Now you’ve created a subdomain, you can attach an ACL. Under Attached ACLs, click on Attached Access Control List. A pop-up will appear.

  8. From the drop-down menu, select the ACL that you created in the previous section.

  9. Click Save. And that’s it! Your outbound SIP Trunk is ready.

NOTE:

  • A domain name can have multiple attached ACLs.

  • An ACL can be attached to multiple domains.

SIP-INVITE header formatting

Now you’re ready to place calls from your VoIP platform to our SIP servers! Please be aware that only accounts attached to this domain can place calls. Therefore the full domain name should be used in the SIP-INVITE header.

This is an example of a SIP-INVITE header:

sip:[E164 Number]@[your_domain].sip.messagebird.com

For example:

sip:3123456789@mydomain.sip.messagebird.com

Utilizing specific Point of Presence (POP) with your domain

MessageBird has POP (Point Of Presence) in three different regions:

  • EU-POP

  • US-POP

  • APAC-POP

You can link your domain to a POP that is closer to the region of origination. By selecting a better POP, you can achieve a better Quality of Service (QOS) and enhanced connectivity levels.

By using the default configuration of [your_domain].sip.messagebird.com your traffic will be redirected to our European servers or, in the case of a local failure, to one of the 3 available regions. To be able to keep your traffic bound to one region and avoid an additional hop through our European servers, you can configure the domain name as follows:

  • Asia: [your_domain].apac1.sip.messagebird.com [your_domain].apac2.sip.messagebird.com

  • USA: [your_domain].us1.sip.messagebird.com [your_domain].us2.sip.messagebird.com

  • EU: [your_domain].eu1.sip.messagebird.com [your_domain].eu2.sip.messagebird.com

By using these subdomains inter-region failover is not guaranteed.

Call anonymization and PAI (P-Asserted Identity)

MessageBird supports anonymous calling features, where the identity of the user is protected.

How it works:

SIP Identity is established with the To and From headers. The To header indicates the user that you wish to establish a session with. The From header indicates who you are.

For example, you might encounter an INVITE that looks like this:

INVITE sip:3123456789@test1.sip.messagebird.comSIP/2.0 Max-Forwards= 70 Via SIP/2.0/UDP 3987654321@test2.sip.messagebird.com; branch=198398334 To: “alice” <sip:3123456789@test1.sip.messagebird.com> From: “bob” <sip:3987654321@test2.sip.messagebird.com>; tag=12345

In this INVITE, ‘Bob’ is attempting to establish a session with ‘Alice’. When set up in this way, Alice’s phone will likely show her that Bob is calling.

However, if Bob didn’t want Alice to know who is calling, Bob might want to suppress the sending of his identity. We can accomplish this with SIP!

Here’s how: Instead of putting his identity in the From header, Bob’s SIP phone would do something like this:

From: “Anonymous” <sip:Anonymous@anoymous.invalid>; tag=12345

Now, when Alice receives the INVITE message, she will be unaware of the name of the caller, and her phone might instead display “Unknown”.

However, while Bob may want to keep his identity hidden from Alice, the network SIP elements might not want to deal with an unknown, anonymous caller. A caller’s true identity is still required for class of service processing, billing, call detail recording (CDR), call recording, or any other traditional network activity.

This is where another SIP header comes into play. P-Asserted-Identity is used within the “trusted” realm of a SIP network to allow servers and services to process SIP messages for the known, authenticated user and not an anonymous caller. P-Asserted-Identity is inserted by a trusted SIP element (e.g. SIP Proxy) and preserved for the message’s entire time within the trusted realm. In other words, as a call is being processed by the SIP network, a P-Asserted-Identity header will be part of all SIP messages for that call (i.e. INVITE, ACK, BYE). As soon as any message leaves the trusted realm, the header is stripped and anonymity is restored.

Using the above example, this is how the same INVITE message might look within the trusted realm:

INVITE sip:alice@test1.sip.messagebird.comSIP/2.0 Max-Forwards= 70 Via SIP/2.0/UDP 3987654321@test2.sip.messagebird.com; branch=198398334 To: “alice” <sip:3123456789@test1.sip.messagebird.com> From: “Snonymous” <sip:Anonymous@anonymous.invalid>; tag=12345 P-Asserted-Identity: “bob” <sip:3987654321@test2.sip.messagebird.com> P-Asserted Identity: tel:+19524563516

NOTE: P-Asserted Identity headers can be used to establish a SIP name as well as a public telephone number.

Last updated