Howto13r3:Central SIP trunk with multiple subscriber numbers

This is a duplicate of Course13:IT Plus- E.164 and consolidated trunk lines

How to add fat SIP trunk lines to an E.164 scenario.

E.164 and consolidated trunk lines

E.164 configurations are not much different from separate PBX installations per location in terms of trunk lines. You would have a dedicated trunk line at each site (possibly from different SIP providers) and register it with the trunk line objects located at the different location nodes.

However, one of the advantages of E.164 configurations is that you don't have to run a separate PBX for each location. Instead, you can run many or even all locations with a single PBX. This way, you can manage many or all of your locations in a single system. As a result, SIP vendors have begun offering fat pipe trunks that combine calls for multiple subscriber numbers (in multiple area codes and sometimes even in multiple countries) into a single SIP trunk.

Such a system can be combined with an E.164 setup, creating a clean and lean PBX system for multiple locations.

We will look into this type of trunk lines in this book.

To start, please load the start configuration files for this lesson to your device.

Challenges

As mentioned in the last section, the idea of using a fat pipe SIP trunk is that there is only one SIP connection to the provider over which all calls from all sites are sent and received.

However, on our PBX side, we usually have one "trunk line" object per site. This must remain the same, because various settings are made on the "Trunk line" object that are specific to the location (e.g. the "Loopback" setting). This means that incoming calls from the SIP provider must be assigned to a "trunk line" object in the PBX on the basis of their called number ("trunk number").

Outgoing calls, on the other hand, go through the local "trunk line" object in the PBX, but must then all be sent (i.e. concentrated) through the one SIP connection to the provider. It must be possible to clearly assign these calls to the various locations within the SIP protocol. The PBX must therefore be able to provide a corresponding marking.

We can implement both requirements with the help of a so-called concentrator PBX.

Concentrator PBX

The task of the  concentrator PBX is therefore to consolidate outgoing calls via many Trunk line objects into a single SIP trunk and to distribute incoming calls to the corresponding Trunk line object based on the called number.

To achive this, a new, specially crafted E.164 PBX is created and connected both to the SIP provider and our real PBX.

Creating the concentrator

We will be using the IP411RIGHT as a platform for the new concentrator PBX.

So let's set up a new PBX. This PBX is separate from your user PBX (where you defined your E.164 plan and registered your users). It has a different object database and the configuration is therefore not replicated from your master PBX. It shall not be part of your PBX tree.

So it cannot be a slave PBX but rather a separate master PBX. However, you will still need some licenses for it to run properly. Of course, you may choose to install dedicated licenses on that box (the IP411RIGHT in our case) but you don't need to.

There is a special PBX mode called a "license only slave". In this mode, the PBX behaves like a master PBX but it still registers to another PBX, solely to obtain licenses from that PBX.

In this course, the concentrator PBX would in fact work well without any connection to the master PBX as we are using the test mode all over the place. However, in real-life you probably would want to configure it to obtain licenses from the master.

Basic settings

Let us set up such a license only slave PBX on PBX / Config / General:

• select Slave as PBX Mode
• set System Name to concentrator.net
• set PBX Name to concentrator
• set Response Timeout, and Dial Complete Timeout to a ridiculous big (that is, long) value such as 9999. Those functions shall be handled by the real user PBX, if necessary
  
• set No of Regs w/o Pwd. to 0
• check the Adjust LDAP results for e.164 check-mark

Also, to set up access to the licenses available on the master PBX, do the following settings in the Slave PBX area:

• set Registration to H.323/TLS (actually, H.323 would do fine too, but we don't want to see unencrypted traffic anywhere in our installation)
• set Master to the IP address of your real master PBX which is 172.31.31.2 in your case
• check the License Only check-mark
  
• fill in the password of the PBX object for the concentrator PBX on your real PBX, which is ip411 of course
• set the Master-GK-ID property to the value of the System Name property in your real PBX (dvl-ckl2.net in your case)
• be sure that Replication is set to OFF as we do not want any objects to be replicated from the master PBX

Anything else can be left as is.

You will probably see a red reset required message on the bottom of the page. Do you know how to get rid of this without a real reset?

To avoid a reset of the box when a reset due to PBX configuration changes is required, you can switch the PBX Mode to OFF, click OK and the turn it back to Slave. This re-initializes the PBX without a reset (and fortunately, all your settings will re-appear when you switch back to slave mode).

As a last step, you should change the name of the box (as given in the Device Name property on General / Admin) to Concentrator-PBX so to remind us that the IP411RIGHT is now used for this purpose. Of course, this step is not strictly required for the concentrator PBX to function However, you need to refresh your browser windows (using F5 in most browsers) for the name change to be seen.

The concentrator PBX object

To obtain the required licenses from the user PBX, the concentrator PBX needs to register to the user PBX. This is why we configured the properties in the Slave PBX section of the concentrator PBX.

Wait a second, when you look at the PBX/General page, shouldn't there be an indication that our new license only slave PBX is registered to the master PBX? This usually shows up next to the License only field in the Slave PBX area.

But it doesn't.

The reason is quite easy (and sort of obvious): our master PBX has no knowledge of your new concentrator PBX.

To fix that, we need to:

• open the PBX / Objects page
• add a new PBX-type object
• set both Long name and Name to concentrator (which is the value of the PBX Name property in our concentrator PBX)
• set a weird Number (something that you will never use in your real numbering plan) such as ###42. We do not need this number anywhere but the PBX insists in having one in each PBX-type object
• set Parent node to root
• set Parent PBX to hq (which is the value of the PBX Name property in your real master PBX)
• check the Hide from LDAP check-mark
• set the ip411 as password
  

Anything else can be left as-is.

In this chapter's introduction we said: It (our concentrator PBX) has a different object database and the configuration is therefore not replicated from your master PBX. This is why we configured it as a slave PBX without replication.

The PBX-type object for a PBX however must exist both on the master PBX and the slave PBX itself. Due to the replication of objects from the master to the slave, this is normally the case right away. However, in our case where we disabled the replication, it needs to be created manually. Before we can create any objects on the concentrator PBX though, we need to set the PBX password.

The creation of the concentrator PBX object requires the following steps:

• set the PBX password property to ip411 on the PBX/Config/Security page of the concentrator PBX (that is, on the IP411RIGHT). Of course, in real life, you would choose a different password, but you already know this ...
• switch to the PBX/Objects page of the concentrator PBX and create the hq PBX-type object just like it exists on the user PBX (that is, on the IP411LEFT)
• finally create the concentrator PBX-type object on the concentrator PBX exactly like you did before on the user PBX (that is, on the IP411LEFT)

The hq object is needed on the concentrator PBX so that you can set the Parent PBX of the concentrator PBX object properly.

The Node Tree

The next step is to create all the E.164 country and area-code nodes on the concentrator PBX.

As before in the user PBX, we need to create a Node type object for each country code:

• create a new Node type object with Name and Long name properties set to node-cc-germany, Number property set to 49, Parent Node property set to root and Escape property set to 0
  
• likewise create node-cc-switzerland with Number 41
• and finally node-cc-italy with Number 39 (Do not forget to set the Escape property to 00)

We need to create the area code node-type objects as well:

• create a new Node type object with Name and Long name properties set to node-ac-germany-berlin, Number property set to 30, Parent Node property set to node-cc-germany, Escape property set to 0 and set Members not to be called
• likewise create node-ac-switzerland-zurich with Number 44 and Parent Node node-cc-switzerland, Escape property set to 0 and set Members not to be called

Remember that Italy has a 2-level numbering plan and therefore no area codes. This is why we do not need to create a node-ac-italy-verona.

Subscriber number objects

In the user PBX, we have also created  Node-type objects for subscribers (e.g. node-branch-verona or node-branch-zurich) or Number Map-type objects in the case of extra MSNs (such as for node-branch-zurich-msn2).

However, in the concentrator PBX, we will create all subscribers as Gateway-type objects. More precisely, we will create such Gateway-type objects for each subscriber number used in our numbering plan, whether it is an MSN or a DDI connection.

So we need to create the following Gateway-type objects on the concentrator PBX: node-branch-berlin, node-branch-verona, node-branch-zurich and node-branch-zurich-msn2 .

These names (e.g. node-branch-verona) may seem a bit misleading, since we will create them as objects of type Gateway and not of type Node. Nevertheless, we want to keep the names used in the user PBX for consistency.

To create the above mentioned Gateway-type objects (node-branch-berlin, node-branch-verona, node-branch-zurich, node-branch-zurich-msn2) on PBX / Objects proceed as follows:

• use Gateway as object type
• set Name and Long Name, Number and Node identical to the corresponding Node-type object in the user PBX
  
• set PBX to the PBX Name of your concentrator PBX, which is concentrator
• set both Hardware Id and Name in the the first entry in the Devices section to trunk- with the name of the object itself appended (e.g. for node-branch-verona use trunk-node-branch-verona)
• in this first entry in the Devices section, tick  the Config VoIP check-mark

As we use these gateway objects in a specific way, a few more settings need to be done on the Gateway tab:

• tick  the Prefix check-mark in the Gateway tab.
  
  This makes sure that for outgoing calls from the user PBX through the trunk in to the concentrator PBX, the full E.164 number of the caller is sent as CGPN. For example, when Edward Hyde calls out through the trunk-node-branch-berlin, the PBX would send his extension number (which is 11) as CGPN. With the Prefix check-mark ticked, the number of the gateway object (which is 54321) is added, so 5432111 is sent
  
  
• enter 0 as No Prefix Number property in the Gateway tab of the gateway object.  This value has to match the trunk line object on the user PBX (which will be 0 in all 4 cases). We will create the trunk line object in the next chapter of the book.

This inhibits the function of the Prefix check-mark for cases where an incoming external call is forwarded (e.g. with a CFU) to an external destination again

Trunk objects in the user PBX

So far (and especially also in the previous book E164 PBX Setups), we did not care about the trunk lines in the user PBX, that is, we have not looked at the "Trunk line"-type objects required for the Berlin, Zurich and Verona branch offices. Now it's the time to do this.

We can not use the PBX Manager plugin for this, as it does not allow us to create objects anywhere else than in the root node. Also, as we have seen in the  picture before, we do not want real SIP trunks to register with them. Instead, the concentrator PBX shall register with the trunk lines in the user PBX.

Instead, we will be creating "Trunk line" PBX objects for each location using the advanced UI on our user PBX (that is, the IP411LEFT).

Let us see how to do this.

We will begin with the trunk line for the Berlin office.

• create a new Trunk line type PBX object
• set Long name and Name to trunk-node-branch-berlin
  
• set Number to 0 (as usual for trunk line objects)
• set the Password property to ip411 (as usual in this course, of course you would ... but you already know that)
  
• set Node to the Berlin branch office node, which is node-branch-berlin
  
• set PBX to the name of your user PBX, which is hq
  
• when you click on Apply now, you will see that the value of the Name property is copied to the Hardware Id property of the first entry in the Devices list, which is exactly what we want
  

You may recall that trunk-node-branch-berlin is exactly the name which we used in the concentrator PBX for the Hardware Id in the Gateway object representing the Berlin office subscriber number. In fact, it is essential that the Hardware Id property in the first entry of the Devices list is  set identically for both objects!

Do not select the TLS only check box, as this will block the registration.

Registration to the "Trunk line" object

Now that we have created the Trunk line object for Berlin on the user PBX, we need to think about the registration that shall take place on this object.

Recalling the  overall picture of the concentrator PBX, we need to arrange that the node-branch-berlin Gateway object in the concentrator PBX  registers with the trunk-node-branch-berlin Trunk line object in the user PBX.

Do you remember that we have  ticked the Config VOIP option in the first entry of the Devices list in the node-branch-berlin Gateway object in the concentrator PBX?

The Config VOIP option changes the behavior of an object so that it creates an outgoing registration instead of accepting an incoming registration.

When you tick this check-mark for an entry in the Devices list and save the object then (e.g. with Apply), a  new tab appears with the Name of the device entry as tab header. This tab can be used to configure the outgoing registration properly.

To configure the Gateway object on the concentrator PBX so that it registers with the Trunk line object on the user PBX, we need to perform the following steps:

• set the Password property on the "Gateway" object node-branch-berlin to the password previously configured for the "Trunk line" object trunk-node-branch-berlin (which is ip411 of course)
  
• set the registration configuration for the Gateway object on its  trunk-node-branch-berlin tab:
• the drop-down on the top needs to be set to H.323/TLS Registration
• the Gatekeeper Id property can be left empty, but we recommend to set it to the System Name of the user PBX which is dvl-ckl2.net
  (as opposed to the System Name of the concentrator PBX which is concentrator.net in our case)
  
• the Gatekeeper Address needs to be set to the IP address of your customer PBX. This is 172.31.31.2, the address of your IP411LEFT

If you change the password or other parameters of the object, the outgoing registration via the Config VoIP option does not take effect immediately. You must select the empty registration type and then set the H.323/TLS registration type again.

As soon as this configuration is done, we will see  a registration on the "Trunk line" object trunk-node-branch-berlin on the user PBX.

As an exercise, please create the trunk line object for the Verona office (remember to call it trunk-node-branch-verona) on the user PBX as well as the Config VoIP configuration within the node-branch-verona object on the concentrator PBX.

When you're done, you should see  another registration from the concentrator PBX on your user PBX. Well done!

MSN trunk lines

But how about the Zurich Trunk line? It is a little special, as it is a single trunk line with two subscriber numbers (MSN). On the concentrator PBX side, these are the two objects called node-branch-zurich and node-branch-zurich-msn2. On the user PBX however, we do want to create a single trunk line object only.

The trick here is to register both objects on the concentrator PBX with the single trunk line object on the user PBX.

Here is how to do it:

• create the trunk line object on the user PBX called trunk-node-branch-zurich (which is the value of the Hardware Id property in the first entry in the Devices list of the node-branch-zurich object on the concentrator PBX). Configure it similar to what you did with the other two trunk line objects
  
  
• configure the registration data in the node-branch-zurich object on the concentrator PBX, similar to what you did before for the other lines.
  
  You should now see a  third trunk line registration on your user PBX
  
  
• open the configuration of your new trunk-node-branch-zurich object and add a second entry to the Devices list. Set the Hardware Id property to trunk-node-branch-zurich-msn2.
  
  This is exactly the value of the Hardware Id property which is configured in the second Gateway object for Zurich on the concentrator PBX (node-branch-zurich-msn2). This represents the second MSN for the Zurich trunk line
  
  
• finally configure the registration data in the node-branch-zurich-msn2 object, similar to what you did before for the other lines.
  
  You should now see a  fourth trunk line registration on your user PBX (on the same trunk object as before).
  
  Also, you will see that all four Gateway objects on the concentrator PBX  have a registration towards your user PBX 172.31.31.2

MSN trunk lines are different from DDI trunk lines in a further way. When a call comes in to one of the subscriber numbers (+41 44 54321 for trunk-node-branch-zurich and +41 44 47111 for trunk-node-branch-zurich-msn2 in our case), we need to define to which internal extension the call shall be routed. The same is true for the outgoing call: the Trunk line object must decide which MSN (that is: which registration on the object) shall be used for the call.

The Trunk line object has a special mechanism to define this mapping: the Name property of the entries in the Devices list can be used to set the internal extension number that corresponds to the device. For this, the  Name property must be set to the Number property of the corresponding PBX object, prefixed with a hash-mark (#).

To define that MSN +41 44 54321 (which is trunk-node-branch-zurich) corresponds to Jane Doe (who has extension 11) and +41 44 47111 (which is trunk-node-branch-zurich-msn2) corresponds to John Doe (who has extension 12), proceed as follows:

• set the Name property of the device entry with Hardware-Id trunk-node-branch-zurich to #11
• set the Name property of the device entry with Hardware-Id trunk-node-branch-zurich-msn2 to #12

You can define up to 10 entries in the Devices list.

 

---

To summarize: for each subscriber number of a multi-MSN trunk line, you would

• create a a separate Gateway type object on your concentrator PBX
• register all of them with a single Trunk line type object with  multiple Devices entries (one per MSN) on your user PBX
• define the mapping between MSN and extension in the Trunk line object's Devices list
  

 Concentrator and user PBX trunk line relationship

Inbound call properties

You need to be aware, that each of your locations (Berlin, Zurich and Verona in our case) may receive external calls through two different channels:

• directly if the call origins from within the known E.164 plan in the user PBX.
  
  In this case, the Incomplete Name/No and No Response Name/No settings  in the respective node object take effect
  
  
• through the trunk line object when the call origins from the rest of the world.
  
  In this case, the Loopback, Incomplete, Invalid, Busy and No Answer settings  in the respective trunk line object take effect

It is therefore a good idea to configure the settings in our newly created trunk line objects according to the settings we already have in the respective node objects.

An interesting case is the Loopback property in the trunk line object. In an E.164 scenario, you can decide how the system shall behave when an attempt is done from another location to dial-out through the trunk of a location. When a user from within your E.164 node tree dials the trunk prefix of a remote trunk, then he will get access to the remote trunk line. This may make sense to allow manual non-local breakout. However, in many cases users expect that they are connected to the switchboard in this scenario, just as it was before. For this, you need to tick the Internal check-mark in the respective Trunk object settings in addition to setting the Loopback property.

While the other inbound call properties are optional, the Loopback setting in the trunk line object should be set in any case to inhibit trunk line access for external callers!

Set the Loopback property in the Berlin, Zurich and Verona trunk lines and also set the respective Internal flag. The loopback destination can be any valid user present in the PBX. For the sake of the lesson checker, please only use the Name column for the Loopback value. Of course, in real life, you could also use the Number column.

Connecting the SIP trunk

Looking at our  overall PBX picture, we can see that we already have configured the registrations from the concentrator PBX  to the Trunk line objects in the customer PBX. This has been done using the Config VOIP option of the Device entries in the node-branch-xxx Gateway objects.

The thing that is still missing is the registration from the concentrator PBX  to the SIP provider.

The concentrator trunk

Connecting the concentrator PBX to a SIP trunk is not much different from connecting just any other PBX to a SIP trunk:

• you create a Trunk line object in the PBX
  
• and you create a SIPx interface on the Gateway layer to create the interface to the SIP provider
  

In the concentrator PBX, we want a single trunk (hence the name fat-pipe) which is in the root node of the PBX.

The first step is to create the trunk line object in the concentrator PBX (on the PBX / Objects tab):

• create a new object of type Trunk Line
• set both Long Name and Name to fat-pipe
• set the Password to ip411 (this is the password which will be used by the SIPx interface later on to register with the concentrator PBX)
• be sure the Node is set to root
• set the PBX to concentrator (which is the PBX Name of our concentrator PBX)
• as for all trunk lines which are connected to a SIP trunk, tick the No Presence/Dialog Subscribe check-mark in the Trunk tab. This inhibits subscriptions towards the SIP provider which will be denied anyway (by virtually all providers)
  

Creating the SIPx interface

In principle, the SIP interface is set up like on a normal PBX. The main difference is that the interface on the local side (i.e. in the Internal Registration area) is not connected to an object on the user PBX, but to an object on the concentrator PBX.

The device on which the concentrator PBX was configured (in our case the IP411RIGHT) is used as the SBC.

Here in the training, we will use a SIP provider simulation which is pre-configured on your IP811 (the implementation details of this simulation are not relevant here, if you are curious though you can have a look at PBX/Dyn-PBXs on the IP811). You only need to understand that we therefore will use the IP811's IP address (which is 172.31.31.3) as IP address of our SIP provider.

So here are the SIP provider credentials:

AOR	fat-pipe-provider@PSTN-SIM
Proxy	172.31.31.3
Username	fat-pipe-provider
Password	ip411

On the local end, we use following credentials to register with the Trunk line object on the concentrator PBX:

Gatekeeper Address	127.0.0.1
Name	fat-pipe
Password	ip411

Creation of the SIP interface:

• on the top
• click on an unused entry in Gateway / SIP
• set Name to fat-pipe (in fact, the name is just informational, so you could use any other name)
• select Provider as Type
• select TCP as Transport (here, all choices would work but TCP is the most probably choice for real-world SIP providers)
• set AOR to fat-pipe-provider@PSTN-SIM
• set Proxy to 172.31.31.3
  
  
• in the Authorization area
  
• set Username to fat-pipe-provider
• set Password to ip411
  
  
• in the Internal Registration area
• select H.323/TLS as Protocol
• set Gatekeeper Address to 127.0.0.1 (which is the local host, that is, the IP411RIGHT)
• set Name to fat-pipe (this must be equal to the Hardware Id of the first entry in the Devices list of the fat-pipe trunk line object on the concentrator PBX)
• set Password to ip411

Now, external calls coming in from the provider will be fed in to the concentrator PBX in the root node context (as the fat-pipe object has root as Parent Node). However, we still need to make sure that all outgoing calls that are not part of our own E.164 node tree (that is, calls to subscribers in the rest of the world) are sent to the SIP trunk.

This is achieved by setting the Route Root-Node External Calls to property of our concentrator PBX to the Long name of the Trunk line object where our SIP interface registers with (which is fat-pipe):

To do this:

• set the Route Root-Node External Calls to property to fat-pipe on the PBX / Config / General tab

The interface maps

The SIP trunk on the concentrator PBX is located in the root node of the E.164 numbering plan. As such it is sending all numbers in a from-the-root fashion (such as e.g. 49305432111) which resembles the international format (as in +49305432111) and also expects all numbers in incoming calls to be in this format.

SIP providers (especially those that offer fat pipes) will behave similar. So numbers should be easily exchangeable back and forth. The only thing we need to take care of is that international numbers may come in two flavors:

• the "+ format" (as in +49 7031 73009), also known as international format
  
• and the unknown format (as in 0049 7031 73009)

SIP providers will always accept the "+ format" (some of them also accept the "unknown format"). So the thing that is left to do is to convert the from-the-root fashion numbers to the "+ format" and vice versa.

This conversion is accomplished by creating some interface maps on the SIP trunk:

• open the SIP interface tab on your concentrator PBX: Gateway / SIP
  
  
• click on the  little plus (+) sign next to your fat-pipe SIP interface. This will open a new dialog that allows you to define the interface maps
  
  
• in this dialog, we want to define mappings for both the CGPN and CDPN in both inbound and outbound direction.
  
  For all inbound numbers (that is CGPN In and CDPN In) in the international format (a.k.a + format), you simply want to strip the leading +:
  
  
• select International from the left dropdown list
• leave the next text field (which defines the matching pattern) empty, as you want to match any number
• leave the text field right next to the arrow symbol (which defines the replacement) empty
  
• leave the rightmost dropdown list as-is (empty)
  
  
• Also, you want to remove leading double 0 from numbers in the unknown format. So you add another rule for CGPN In and CDPN In:
  
  
• select Unknown from the left dropdown list
• set the next text field (which defines the matching pattern) to 00, as you want to match numbers starting with double 0
  
• leave the text field right next to the arrow symbol (which defines the replacement) empty
  
• leave the rightmost dropdown list as-is (empty)
  

• Likewise, you want to add the + on all outbound numbers. To do so, you add rules for both CGPN Out and CDPN Out:
  
  
• leave the leftmost text field (which defines the matching pattern) empty as you want to apply this rule to all outgoing numbers (remember that the concentrator PBX always sends all numbers in the from-the-root format)
  
• select International from the left dropdown list
• leave the next text field (which defines the replacements) empty
• leave the rightmost dropdown list as-is (empty)
  

 Interface maps

Outgoing calls UUI

There is still one issue which we have not yet solved: for billing purposes the provider needs to know who is initiating the call.

For normal calls this is easy: the calling party number can be used to identify the caller. This works even if the caller id is suppressed because it is conveyed in the signalling anyway with just an addition that it must not be shown to the remote user.

However, for diverted calls the situation is different. Suppose there is an incoming call from +1 (202) 4561111 (that is, the white house is calling) to your extension. As you are not in the office, a call forward to your mobile phone (say, +41 79 1234567) is done.

This diverted call will result in a call towards the provider that will carry the white house (+1 (202) 4561111) as calling party number. Obviously, your provider cannot bill the call to the white house and therefore will reject it. In this case, the originally called party number (+41 44 4123120, which is now the diverting party number) needs to be presented to the provider along with the diverted call.

There are two options to do this. Firstly, the call may carry the DGPN (diverting party number sent in a Diversion header) and the carrier can do the billing based on that. The PBX will always send the DGPN, so if your provider works that way, you're done.

However, many providers don't do that and require a specialized information known as Identity header with the call. The PBX will also send this information along with the call. The content of it can be  configured in the SIP interface dialog as different providers require different settings.

Choices are:

• CGPN in user part of URI. This is the calling party number and we have seen above that it doesn't work for diverted calls
• Fixed AOR. The AOR identifies the SIP trunk itself. This is a good choice for SIP trunks which carry only a single subscriber number. However, with our concentrator PBX SIP trunk, we need to support multiple subscriber numbers, potentially even located in multiple countries. So this doesn't work for us
• UUI. This options uses a value known as User User info that comes as part of the call and copies it into the Identity header. This looks promising!

change the Identity Header when Sending INVITE drop down in the SIP interfaced used to connect to the provider on Gateway / SIP to UUI.

As said before, the goal is to send an information to the provider that allows it to do the billing for the outgoing call. We have seen that this is information is either the calling party number or, in the case of a diverted call, the diverting party number.

The SIP interface, when configured to use the UUI as Identity header, takes the whole content of the UUI that comes with the call literally as a string and places it into the header. There is only one exception: the string "{initiator}" is replaced by either the diverting party number (if there is any) or the calling party number - which is exactly what we want.

However, where does the UUI come from? By default, no UUI is send with a call.

The solution is to insert the UUI in the routing table for outgoing calls towards the provider.

Here is how to do that:

• on the Gateway / Routes page of your concentrator PBX, you locate the  route towards your SIP interface (SIP1)
• you click on the right arrow next left to the To column
• on the new dialog opened, you put Add proper UUI in to the Description field
• and put <sip:{initiator}@PSTN-SIM>  into the Add UUI field
  

Let us look a bit at the field value for the Add UUI field. In almost all cases, the value to use will look almost exactly like what we configured here. The only difference would be the domain part after the @. Instead of PSTN-SIM (which is a pseudo domain used only here in the training), the real domain part of your provider would be used.

For example, <sip:{initiator}@sip-trunk.telekom.de> might be the required value. The proper domain value will most probably be the domain name that your provider has told you to use to register the SIP trunk. If in doubt, contact your provider.

Nonstandard UUI

Setting the UUI in the Gateway/Routes as described in the previous chapter works well if the provider accepts the full party number the call is to be billed to (that is, the full number including the calling/diverting extension).

Some providers however require different values for the Identity header.

For example, they may require you to send the exact subscriber number of a trunk (that is, without extension or the first MSN in case of multiple MSNs). Also, they may required you to send something completely unrelated to the number (e.g. a customer id or account name). If the required value is the same for all calls from all trunks, then the solution is still easy: you simply put the required string as value for the Add UUI property in the route towards the provider.

However, if a value specific to each Trunk line type object in the customer PBX is required, the approach is slightly different:

• you must make sure that the Add UUI property in the route towards the provider is empty
• instead, for each trunk line, you put the required value in to the  Set incoming call UUI property of the Gateway type object in the concentrator PBX that is registered with the respective Trunk line object in the customer PBX
• also, you set the Set outgoing call UUI property to - (minus sign). This will clear any UUI information which may be present in calls towards the user PBX

It is somewhat confusing that you enter the UUI for outgoing calls to the provider in the property Set incoming call UUI. This is because these Gateway type objects do mirror the Trunk line type objects in the user PBX. So what is an outgoing call as seen from the user PBX is an incoming call as seen from the concentrator PBX.

More on SIP tweaks

You might recall that the PBX Manager Trunks plugin has a list of pre-known providers and knows how to configure them right. A similar list is available in the Gateway/SIP area (e.g. on your concentrator PBX Gateway / SIP). If your SIP provider is listed, you're in luck as you could use the template available from the list and it would set all the nifty SIP options as required.

Unfortunately, this doesn't work quite well for those super-trunks we are talking about here.

Instead, our recommendation is to configure the SIP interface as discussed so far and then create an extra SIP interface using the template. You can use fantasy numbers and names there, as we are not going to use this SIP interface really.

Instead, you would

• create the interface
• open its property sheet
• and copy all settings from the Media properties and SIP Interop Tweaks sections to your original SIP interface

The only exception is the Identity Header when Sending INVITE settings which must be set to UUI as we already learned before.

Testing it

Testing a call from Richard Roe to John Doe would not make much sense because the call would remain on-net. The call would stay on the IP411LEFT and would not be routed to our Concentrator PBX.

To test or Concentrator PBX you'll find 3 different accounts on your IP111. A German, a Swiss and an Italian user, all located on our PSTN simulation. To test your configuration please open Maintenance / Diagnostics / Logging and tick the following options:

• Gateway calls
• Gateway routing
• PBX calls

Before you test our PSTN simulation, you need to know that the SIP trunk terminates at a German provider. As a result, national calls are only possible between Edward Hyde and 49 30 External Berlin user.

To reach your PSTN User please use this numbers from your local PBX users.

• To reach 49 30 External Berlin - 4242

International number: 00049304242

You can dial the national number from Edward Hyde: 00304242

• To reach 41 44 External Zurich - 4242

International number: 00041444242

• To reach 39 External Roma 064242

International number: 00039064242

To reach your local PSTN users please dial this numbers from the PSTN accounts of your IP111.

• To reach Edward Hyde

International number: 0049305432111

National Number(dial able from 49 30 External Berlin - 4242):0305432111

• To reach John Doe

International number: 00414454321

• To reach Jane Doe

International number: 00414447111

• To reach Richard Roe

International number: 0039045432111