Courseware:IT Plus - SIP interface

The book gives a deeper understanding how to set up SIP interface

Introduction

In this book (and the following) we will take a deeper look into the relay part of the firmware. You may be asking yourself right now,"What is the relay part of the firmware?". If you investigate the myApps UI and Advanced UI you won't find the term relay anywhere. The answer is simple. Relay is another term for the gateway layer you can configure on Gateway / General.

This book is a practical example of a customer scenario. Please read our theory books (Gateway Interfaces Theory (optional): CDPN/CGPN MapsRouting Engine Theory (optional) ) if you need a more in depth theoretical background.

Scenario description

The scenario in this book is not complicated. An Austrian company (based in vienna) ordered a DDI SIP trunk and we will set it up for them.

Please upload the start configuration this lesson to your devices, afterwards click  the button on your device page to upload the startup configuration to your app services as well.

Trunks Settings plugin

In general, we recommend using the Trunks plugin in the Settings app to set up a trunk for connecting your PBX to the PSTN. The Trunks plugin can configure FXO, BRI, PRI, and SIP interfaces. In this book (as the title already suggests), we will focus more closely on SIP interfaces.

During the configuration, you will need to select the country of origin for your SIP provider. This will display all available and supported SIP provider profiles in this country. We recommend using one of these profiles rather than setting up the trunk manually.

The reason is that each profile includes all the necessary SIP tweaks and interface mappings required to communicate properly with the selected provider. This saves you the effort of figuring out compatibility settings yourself. Unfortunately this is necessary because there is no SIP trunk standardization yet and not all providers tend to behave the same.

If none of the listed profiles match your provider, you can choose the Standard SIP Trunk option. This creates a generic SIP trunk configuration that works with most SIP providers.

Set up the following DDI SIP trunk. Afterward, we will explore the advanced configuration to review what the plugin has done and examine opportunities for further optimization. To do this, we’ll activate Expert Configuration right from the beginning.

• Name and SIP: trunk

• Number: 0
  
  
• interface/SBC: hq.dvl-ckl2.net

This option determines on which device the SIP interface will be configured. In the following chapters, we will take a closer look at what an SBC is and explore the different design options available.

• Default SIP Trunk

• Country Code: +43

• Connection type: DDI

• International number: +43192258541

• Lowest extension: 0

• Number mappings:

+43192258541 -> <empty>

• User: sip92258541

• Password: ip411

• Protocol: UDP

• Domain: sip.dvl-ckl2.net

• Proxy: <leave empty>

• Media Relay: on

• Expert Mode: on

The Expert configuration is only available when editing an existing trunk, not when creating a new one. Once enabled, the configuration of the Trunks plugin cannot be changed. If you make a typo or select an incorrect property, you must delete the entire trunk and start over.

SBC functionality

The innovaphone SIP interface, available on all gateways, implements all the functions typically provided by a Session Border Controller (SBC) for SIP trunk connections. These functions include:

• Protocol translation (SIP vs. H.323)

• Security offloading (e.g., encrypted/unencrypted conversion)

• Media pin-holing (NAT traversal, ICE/STUN/TURN)

• Media anchoring (media relay)

• Header manipulation (for SIP interoperability issues)

The SIP interface is separate from the PBX because it is embedded in the gateway layer of the device. Although in most installations the SBC and PBX run on the same device, different internet access scenarios may require the SBC to run on a separate device. We will explore these scenarios in the following chapters.

SBC in DMZ

Two routers (at least one of them performing NAT and potentially also including firewalls) are located in a Demilitarized Zone (DMZ):

The purpose of a DMZ is to ensure that no traffic is routed directly from the internet to the internal company LAN. Instead, all traffic is relayed by a trusted entity within the DMZ, in a (hopefully) controlled and secure manner.

To implement this setup, you install an innovaphone gateway platform (such as an IPVA or IP0013) in the DMZ. Signaling traffic to the SIP provider is handled by the SBC via the SIP interfaces (SIP-IFs), and RTP traffic is managed by the SBC when media relay is enabled for the SIP interface.

SBC on Router

However, in many cases, the customer does not have a DMZ. In this case, you would use a similar approach. You would install an Innovaphone Gateway Platform in the DMZ as before. The difference is that it also functions as a NAT router.

SBC internally

In many cases, the internet access infrastructure is set and cannot be changed. In this case, an existing NAT router is used.

For this setup, a slightly different approach is used: an innovaphone gateway platform is installed in the customer's LAN.

This configuration is recommended when supporting a high number of concurrent SIP trunk calls with media relay is necessary. This shifts the load imposed by the media relay function away from the PBX, enabling you to safely support a greater number of extensions.

SBC internally with PBX

It is also possible to modify the previous scenario such that the PBX runs on the same box.

This is the most popular configuration because it creates small, simple setups. However, keep in mind that the media relay consumes network and CPU load. Running an SBC with media relay on the same box that runs the PBX limits the number of extensions that can be safely supported on that box.

SBC internally with PBX - SIP interface without registration

If your SIP provider does not require registration, you need to create a NAT map on your router to forward SIP traffic to your device. Unfortunately, this opens access to your device, which a malicious attacker can use from the internet through this port. Therefore, this must be avoided.

In this case, we recommend splitting the SBC and the PBX into two separate devices.

No-Nos

Just to clarify this:

You must not expose your PBX to the internet directly!

Attaching the PBX directly to the internet is dangerous. It is not recommended.

SIP Interface

SIP interfaces handle registration to a remote peer that uses SIP (e.g., a SIP provider). In our scenario, the IP811 will serve as the SIP provider (PSTN simulation). If you navigate to Gateway / SIP, you will see that your SIP interface is registered both to the IP811 and internally to your own PBX.

Please open the SIP interface configured by the Trunks plugin,  assign it a meaningful name, and click OK to save your configuration.

You will notice, there are quite a few available settings, many of which are not self-explanatory. That is why we recommend using the Trunks plugin along with the SIP Profiles it offers. This approach simplifies configuration, as you no longer need to worry about specific interoperability settings. You simply enter your account details, and the SIP profile automatically applies the necessary options to ensure compatibility with your provider.

In this book, we will cover the most important configuration options. If you are interested in a setting that we have not included, feel free to consult the  reference article in the wiki.

General Configuration

The registration to a SIP provider is  always initiated by the device unless the checkbox Without Registration is set. In this case no registration is done at all. In order for the SIP interface to know where to sent its registration attempt only an address has to be specified.

• Type: Unless you are setting up a federation with another PBX, select the Provider option. This allows you to establish a connection to a remote SIP endpoint, such as a SIP provider.

• Transport: Choose the transport layer protocol: UDP, TCP, or TLS. All three support operation with or without registration, depending on whether the Without Registration checkbox is enabled.

• AOR (Address of record): This is the registration ID used by the SIP interface to register with the provider. It typically consists of a user part and a domain part (e.g., user@provider.com).

• Local Port: You can define a local source port for this interface. It's recommended to leave this field blank so that a random port is chosen. If you manually assign a specific port, this port cannot be used by another SIP interface. For example, if two SIP interfaces are configured to use port 5060, only one will work due to the port conflict.

• Local Hostname: The SIP interface compares the Domain/IP Address configured here against the domain part of the TO field and removes it if they match. This is only relevant for SIP federation scenarios.

• Proxy: By default, the destination of each SIP message is derived from the domain part of the AOR. If that domain cannot be resolved or used properly, you can manually specify the destination (Proxy) address here.

In our SIP interface configuration, we can see that the Trunks plugin has set the following options:

• Type is set to Provider. This is the expected behavior, as the Trunks plugin does not support the configuration of SIP federation—this must always be configured manually.

• The Protocol is set to UDP, which matches the selection we made in the Trunks plugin.

• The Without registration flag was not set. As a result, the PBX will create a registration on the IP811.

• The AOR user part is set to sip92258541, which corresponds to the Username field we entered in the Trunks plugin.

• The AOR domain part is set to sip.dvl-ckl2.net, which reflects the Domain value we configured in the Trunks plugin.

There is no need to change anything. The registration works as expected.

STUN Server

Earlier in this book, we discussed common VoIP network design scenarios. In several of those scenarios, the SBC interface is located behind a NAT router, which can pose challenges for RTP traffic. The issue is that the SIP provider cannot route RTP packets to a private IP address received in signaling.

In practice, most SIP providers implement NAT detection. This allows them to determine the correct IP address and port to send media data to, even if the received address is private. As a result, in most cases, you don’t need to configure a STUN server.

However, some providers do not support NAT detection. In such cases, it may be necessary to use STUN, and possibly media relay, to establish proper communication.

If you configure a STUN Server address, the SIP interface uses the STUN protocol to discover its external IP address and port.

 As shown in the picture, the SIP interface sends a STUN request to the configured STUN server. Since the device is behind a NAT router, the NAT changes the source address of this request to its own public address. The STUN server then examines the source address and informs the SIP interface of the public IP and port from which the request was received.

The SIP interface uses this information to populate:

• The Contact header in SIP REGISTER messages.
• The connection information (c-line) in the SDP, if media relay is enabled.

If the device is behind a symmetric NAT, the external address learned via STUN is not used, as it would be ineffective. A symmetric NAT only allows responses from the exact destination to which the request was sent—no other external device can reuse that NAT mapping.

Authorization

To authorize the SIP interface at the provider, the SIP interface has the option to add credentials. If the user name is the same as the user-part of the AOR, you can leave the user name blank.

Let's test it and configure it  with no username, even though the Trunks plugin set it properly.

Username	leave empty
Password	ip411

You will see that the SIP interface remains registered.

Media Properties

For each call passing through this interface,  media properties are applied to fine-tune signaling and RTP traffic.

• General Coder Preference: This option allows you to select your preferred codec. If you configure this codec exclusively, the provider must support it. Otherwise, the SIP endpoint will reject the offer with a 415 - Unsupported Media Type response.

• Enable T.38: Enable this option to transmit faxes digitally using the T.38 protocol. Many providers do not support T.38, so in such cases, this option should be disabled.

• Media Relay: When enabled, RTP traffic is  passed through the SIP interface. This means the provider will exchange media directly with the PBX's IP address rather than the IP address of the calling endpoint. Since many providers do not support media traffic to multiple IP addresses, you should set this dropdown to On in those cases.

• No ICE: This checkbox disables ICE (Interactive Connectivity Establishment), so no ICE candidates are sent to the remote side. ICE is a mechanism to dynamically select a suitable transport path for voice data. Since most SIP providers do not support ICE, you will generally check this option to avoid interoperability issues.

• SRTP Key Exchange: This dropdown determines the protocol used to exchange the SRTP key. You can choose between SDES and DTLS or prioritize one over the other. Selecting "No encryption" means the voice data will be sent without encryption.

A detailed explanation of all media properties can be found in the  this wiki page.

Enabling media relay along with an exclusive codec allows the SIP interface to enforce the codec choice, which often resolves interoperability issues with provider equipment.

As mentioned, many providers do not support T.38. As a result, please deactivate it.

SIP Interop Tweaks

A number of interop features can be configured here to enhance interoperability between the SIP interface and the SIP provider. The most common options are listed in  this wiki article.

Internal Registration

SIP interfaces must register in two directions: with the SIP provider and with the PBX's trunk object.

As you can see in the Internal Registration section of the SIP interface,  only two parameters are needed for a successful internal registration.

Protocol	H.323/TLS
Gatekeeper Address(primary)	hq-dvl-ckl2.training.innovaphone.com

You may wonder why no name or password is necessary for the internal registration. If these fields are left empty, the interface will use its serial number (MAC address) as the registration name with the PBX. However, to distinguish the device's individual interfaces, the interface name will be appended to the serial number. For example, the registration name of the SIP1 interface will be 0090334000b3-SIP1. As a result, this name must be configured as the Hardware ID on your trunk object.

As soon as you register an interface with the PBX (except for a GWx interface), two direct routes are created between the interface and the VoIP interface used for registration. These VoIP interfaces are named R plus a short name for the interface in question, followed by the optional interface index. For example, the implicit VoIP interface for the SIP1 interface of our IP411LEFT is called RS1.

Below is a list of all the interfaces that will be created once you register the corresponding interface.

Interface Type	Shorthand	Sample
SIPx (SIP client)	S	RS2
TELx (FXS)	AB	RAB2
FXOx (FXO)	FX	RFX2
BRIx (basic rate ISDN)	B	RB2
PRIx (primary rate ISDN)	P	RP2
TEXT	TEXT	RTXT
TEST (constant MoH)	TST	RTST
TONE (dialtone)	TON	RTON
HTTP (webmedia HTTP client)	WEB	RWEB
ECHO (test echo)	ECH	RECH
SIGx (virtual signalling)	SP	RSP2
FAX	FAX	RFAX
CONF (conference)	CONF	RCNF
SCNF (soft-conference)	SCNF	RSCF

Testing the SIP interface

To test your configuration, we registered your IP232 to the provider simulation running on your IP811. This simulates a phone connected to the PSTN in Germany.Keep in mind that your PBX is located in Austria.

Now call 00049703112345610 from your IP111 (John Doe) and call 004319225854114 from your IP232.

Both calls should already work thanks to the interface maps and routing engine maps created by the Trunks plugin. We will take a closer look at these in the following chapters.

Interface maps

As mentioned in the previous chapter, both the CDPN (called party number) and CGPN (calling party number) must be modified for outgoing and incoming calls. To achieve this, the Trunks plugin automatically configures number mappings for each SIP interface. Please go to Gateway / SIP and click  the interface maps already created by the Trunks plugin.  A new window will appear allowing you to configure the following:

• CGPN In: inbound calling party number
  
• CDPN In: inbound called party number
  
• CGPN Out: outbound calling party number
  
• CDPN Out: outbound called party number

First, let's clarify the direction of traffic. A call from the provider to the SIP interface is considered inbound, and a call from the gateway to the provider is considered outbound.

• A CGPN In map modifies the calling party number (From number) of a call coming from the provider to the gateway.
• A CDPN In modifies the called party number (To number) of a call coming from the provider to the gateway.
• A CGPN Out modifies the calling party number (From number) of a call from the gateway to the SIP provider.
• A CDPN Out map modifies the called party number (To number) of a call from the gateway to the SIP provider.

Next, we need to determine the number format used by the SIP provider, both for sending and receiving calls. Unfortunately, there is no universal standard. Most providers either use the full E.164 format (e.g., +497300912345610) or an international format with a prefix (e.g., 00497300912345610), but this can vary significantly.

This variation in behavior is why we provide tested Trunk profiles for many common providers, as mentioned earlier. It is highly recommended to use these profiles whenever possible.

In this fictional scenario, the SIP provider simulation expects to receive and send numbers in full E.164 format, with a plus sign (+) prepended.

Please open the syslog on Maintenance / Diagnostics / Logging and activate the Gateway Calls and Gateway Routing as Logging option. This will allow you to view the actual numbers being transmitted and received, helping verify correct configuration.

Inbound call

CGPN-IN

Let us discuss the inbound call first. So please go ahead and call 004319225854114 from your IP232 again and look at the log afterwards.

The syslog shows us the CDPN and CGPN of the incoming call in this message:

ROUTE 0 INTERFACE MAP if=SIP1:'to SIP provider' CGPN-In I49703112345610->0049703112345610, CDPN-In I4319225854114->14, DGPN-In ->

Interestingly, the number of the caller is prefixed with an I (CGPN-In I49703112345610). This I stands for the international flag. The SIP interface has a function to convert an international flag by a leading + symbol and vice versa. As a result, we know that the incoming CGPN was in the format +49703112345610.

When we look at the CGPN-In section of the interface map, we see 2 rules.

• If the call is coming from an Austrian extension, the country code is removed and instead the national prefix is added.
• If the call is an international call, the international flag is removed and exchanged with the internal prefix 00

So the syslog shows us that the interface map is applied and the call is routed to the PBX with the CGPN 0049703112345610. The trunk line object then prepends another zero for the external line prefix and as a result the user will see the number 00049703112345610 on his screen. This is the format the user would expect to see, because this number can be dialed back (we can try this as soon as we created the interface maps for outgoing calls).

CDPN-IN

Now let's have a look at the CDPN of the incoming call:

CDPN-In I4319225854114->14

Again, like the CGPN, the CDPN comes in international format. If we would apply a similar map to the CDPN (which adds 00 for international numbers), we'd end up with 004319225854114.

Looks good, but: If we forward the number 004319225854114 to the PBX, the call will be routed back to the trunk object (which has number 0) and back to the provider which will create a loop. Obviously this should be avoided.

The PBX expects to receive only the extension number of John Doe, which is 14 in our case. Therefore, we need to strip our own trunk access number.

But if we look into the interface maps the Trunks plugin creates we see way more maps than removing the E.164 except the extension number. The reason is that the Trunks plugin wants to be on the safe side and removes number formats it might receive.

If you have more than one interface map, the list will be evaluated from top to bottom. The first matching map will be used.

As the call moves through the device, the CDPN and CGPN are changed by both the interface map and the trunk line object.

Outbound call

As a next step we will have a look at the outgoing call.

Please call 00049703112345610 from John Doe (IP111) and take a look into your log again. You will see this line n the log.

ROUTE 0 INTERFACE MAP if=RS1:'to SIP provider' CGPN-In 14->14, CDPN-In 0049703112345610->0049703112345610,

...

ROUTE 1 INTERFACE MAP if=SIP1:'to SIP provider' CGPN-Out 004319225854114->I4319225854114, CDPN-Out 0049703112345610->004970311234561

CDPN Out

Le'ts have a look at the CDPN-Out first because there is not much to do here. The interface maps passes the CDPN as he receives it.

To improve the configuration we can  change the international prefix to the international flag, which is translated to a plus sign by the SIP stack.

CGPN Out

The syslog shows that the CGPN coming from the PBX to the relay on interface RS1 is simply 14. This makes sense, as it corresponds to the extension number of John Doe. Please note that no interface maps are applied to automatically generated interfaces like RS1, which is why no number manipulation occurs at this stage.

The call is then passed through the routing engine and forwarded to the SIP1 interface. At this point, we can see that the CGPN has already been manipulated by the routing engine—a topic we will cover in the next chapter.

Next, the SIP1 interface maps are applied. The incoming number is 004319225854114. We can see that the international prefix (00) has been removed and replaced with the international flag.

Now, let's examine the interface maps created by the Trunks plugin. There are three rules that evaluate the CGPN based on whether it has an international, national, or no prefix. Depending on the match, the CGPN is transformed into a complete E.164 number, with the extension number appended.

Voila.

Routing Engine Maps

The final step is to check the routing table to see what the Trunks plugin configured for us.

Inbound route

The inbound route is rather unspectacular. Every call received on the SIP1 interface is simply forwarded to RS1 and then to the PBX through the trunk object.

Outbound route

Please open the syslog and then let's do another outbound call and dial 00049703112345610 from John Doe (IP111) once more.

You will see the following:

ROUTE 1 INTERFACE MAP if=RS1 CGPN-In 14->14, CDPN-In 0049703112345610->0049703112345610, DGPN-In ->

ROUTE 1 EVAL ROUTE route=RT2

The call is routed to RT2, which is the outbound route.

ROUTE 1 EVAL MAP route=RT2 map=1 dest='TONE' in=''->out=''

The first map in the outbound route is being evaluated. No CDPN map is present, and the destination is the TONE interface.

ROUTE 1 MAP(CDPN-MATCH OK) route=RT2 map=1 dest='TONE' in=''->out=''

Since no CDPN map restricts access, this map applies to every outbound call.

ROUTE 1 APPLY CDPN-MAP in='0049703112345610'->out='0049703112345610'

No transformation is applied to the CDPN; it remains unchanged.

To explain the purpose of the TONE interface: when the caller goes off-hook and dials "0," they hear a dial tone. This behavior mimics what users expect from analog or ISDN lines. However, SIP trunks do not provide this natively, so the TONE interface is used to simulate this behavior. If overlap dialing is not performed, the system proceeds to the next map.

ROUTE 1 EVAL MAP route=RT2 map=2 dest='SIP1' in=''->out=''

This line indicates that the second map in the route is being evaluated. Its destination is the SIP1 interface.

ROUTE 1 MAP(CDPN-MATCH OK) route=RT2 map=2 dest='SIP1' in=''->out=''

No CDPN restrictions are configured, so this map is applicable

ROUTE 1 EVAL CGPN-MAP cgpn=14 verify=true in=''->out='00431922585410'

The CGPN of the call is "14." This map has the "verify CGPN" option enabled (verify=true, meaning it will only be applied if the CGPN matches the specified CGPN.

ROUTE 1 EVAL CGPN-MAP FAILED(verify=true)

The map fails because it only applies to calls with a restricted number, as specified in the routing table. If the call had a restricted flag, the CGPN would have been changed to 00431922585410.

ROUTE 1 CONTINUE TO NEXT MAP route=RT2 map=2 dest='SIP1' in=''->out='' reason='verify cgpn failed'

Since the verification failed, the routing engine proceeds to the next map.

ROUTE 1 EVAL MAP route=RT2 map=3 dest='MAP' in=''->out=''

The third map is now evaluated. Its destination is a MAP, meaning it doesn’t hand off to an interface yet—it continues routing logic.

ROUTE 1 MAP(CDPN-MATCH OK) route=RT2 map=3 dest='MAP' in=''->out=''

No CDPN match condition is set, so the map is valid for every call.

ROUTE 1 EVAL CGPN-MAP cgpn=14 verify=false in='000...'->out='00'

ROUTE 1 EVAL CGPN-MAP cgpn=14 verify=false in='00...'->out='0043'

ROUTE 1 EVAL CGPN-MAP cgpn=14 verify=false in=''->out='0043192258541'

Here, multiple CGPN maps are evaluated. The CGPN is "14," and the verify=false means, that the verifiy CGPN check mark is not active. These maps apply to all calls if the CGPN pattern is true. Only the last map matches for our call.

ROUTE 1 EVAL CGPN-MAP SUCCESS in=''->out='0043192258541'

Since the last map matches, the number 0043192258541 is prepended to the CGPN.

ROUTE 1 APPLY CGPN-MAP in='14'->out='004319225854114'

The routing engine logs the CGPN transformation—from "14" to "004319225854114"

ROUTE 1 CONTINUE TO NEXT MAP route=RT2 map=3 dest='MAP' in=''->out='' reason='processed MAP interface'

Since the destination is a MAP interface, the call proceeds to the next map in the route.

20250722-123528 ROUTE 1 EVAL MAP route=RT2 map=4 dest='SIP1' in=''->out=''

20250722-123528 ROUTE 1 MAP(CDPN-MATCH OK) route=RT2 map=4 dest='SIP1' in=''->out=''

20250722-123528 ROUTE 1 APPLY CDPN-MAP in='0049703112345610'->out='0049703112345610'

20250722-123528 ROUTE 1 SUCCESS route=RT2 map=4 dest='SIP1' in=''->out=''

The fourth map is evaluated, and its destination is the SIP1 interface. No CDPN transformation is applied, so the CDPN remains unchanged. The call is then handed over to the SIP1 interface maps, which were already discussed in the previous chapter.

Calls without CDPN

We did not choose Austria as the country for our example by accident. Although a DDI line is used, you must be able to reach an Operator in Austria without dialing an extension number or a 0. This means that you have to handle incoming calls with the CDPN 0043192258541 in our example.

Start your syslog again and call 0043192258541 from your IP232.

The log shows us that the interface map works as they should. Our CDPN-in maps subtracts the entire E.164 number so that an empty CDPN is forwarded to the routing table.

ROUTE 0 INTERFACE MAP if=SIP1 CGPN-In I49703112345610->0049703112345610, CDPN-In I43192258541->, DGPN-In ->

The call is then disconnected due to an incomplete number. Neither the gateway nor the PBX know what to do with this call. As a result the log shows us this error message.

CALL 0 B:Rel 0049703112345610-> / SIP1:0049703112345610:->RS1:: Cause: Invalid number format (incomplete number)

Fortunately we have a solution for this issue. You need to configure the  incomplete value in the trunk object.

Please set the incomplete value to 13 or Richard Roe. in the PBX Trunk Line object called trunk. He should receive any incomplete call. Please test the call to 0043192258541 from your IP232. This time the call will be forwarded to Richard Roe.

Force Enblock

Now let's take a look at the routing table to discuss a parameter we've previously ignored: the Force Enblock checkbox.

When performing overlap dialing—that is, going off-hook and dialing digits one by one—each digit is sent individually to the SIP provider if the Force Enblock option is not enabled in the outgoing route. However, some SIP providers might reject or disconnect such calls, as they expect the full number to be received in one complete message.

Not all SIP providers support overlap dialing, as defined in RFC 3578. In such cases, it's essential to ensure the entire number is sent as a complete message.

To handle this, the Trunks plugin enables the Force Enblock option by default. When this option is set, the routing table pauses for a configurable timeout (typically 4 seconds) to wait for additional digits. If no further digits are received within that period, the number is considered complete and sent to the provider as-is.

This ensures compatibility with SIP providers that do not support overlap dialing and helps avoid premature call rejections.

MSN Trunk

So far, we have only discussed the use of a DDI trunk, which allows you to have a range of extensions. In the remainder of the book, we will explore how the Default SIP trunk is configuring MSN trunks:

• A trunk with Multiple Subscriber Numbers (MSN), where there is one registration with the provider for each MSN

• A trunk with Multiple Subscriber Numbers (MSN), where there is a single registration with the provider for all MSNs

MSN - single registration

If your SIP provider offers an MSN trunk with a single username and password, you should  select No in the Default SIP Trunk configuration. Afterwards you  can define number mappings. These mappings specify the MSN numbers provided by your SIP provider and the corresponding internal numbers they are mapped to.

Once configured, you'll notice that a single SIP interface is used to establish the connection with the provider. The general configuration—such as authorization, media properties, and internal registration—is handled in the same way as with a DDI interface. The key differences appear in the interface maps and routing maps.

Routing Table

The only difference compared to the DDI interface is the map  !->00431922585411. The exclamation mark means that any incoming CGPN (Calling Party Number) digits are removed and replaced with 00431922585411.In other words, any unknown extension number is mapped to the external MSN number you configured as the first map in the Trunks plugin.

Interface maps

By now, you should be able to interpret  the interface maps. All CGPN-Out maps (expect the map 00-> I) will not apply, as the routing maps already handle the necessary transformations.

The CDPN-In maps, are used to strip the MSN number from the CDPN and replace it with the corresponding extension number, ensuring that the correct extension rings. Each MSN number configured in the Number Mappings section of the Trunks plugin is mapped to a specific internal number. To ensure compatibility, we included all possible number formats that the provider might use when sending the CDPN (Called Party Number).

MSN - individual registrations

When each MSN number has a separate username and password, you should  select Yes as individual registration in the Default SIP trunk configuration.

As you proceed with the configuration, you can  add a different username and password for each MSN number. Once completed, you will have a separate SIP interface for each MSN. Keep in mind that a maximum of 16 SIP interfaces is supported.

Routing Table

Note that  only the first SIP interfaces has an internal registration to the trunk object. All other SIP interfaces register with the SIP provider's SBC.  The routing table is configured so that inbound calls from each interface are routed to RS1. For outbound calls, the extension number is evaluated (verify CGPN=true), and the call is routed to the corresponding SIP interface based on the originating extension.

Interface maps

 The interface maps are identical to the single-registration variant. However, in this case, each interface only maps its own MSN to the corresponding internal extension.

If you're looking for hands-on practice, please continue with the next book, where we offer more practical exercises and in-depth configurations.