Outbound Calls on Trunk

From Pbxnsip Wiki

How to Present Caller-ID

When the PBX sends a call to a trunk, it has to present the source of the call. Usually the source of the call is the caller-ID of the calling extension; this source is the number that the called party should see in the display and this number is also the number that the carrier uses for billing purposes.

However in cases of redirected calls, things get more complicated. Here the original caller-ID should be in the display of the called party, while for billing purposes a local identity on the PBX must be used.

Also, in many cases it is necessary to translate a local number (e.g. "sip:123@localhost") into a global telephone number (e.g. "sip:9781234567@itsp.com;user=phone"). The "user=phone" parameter indicates that the domain name should be ignored when presenting this number. This number is also called "ANI" (coming from "Automatic Number Identification").

If you are using FXO gateway, things are different because of the physical nature of FXO. If you want to assign DID numbers for FXO, check out Assigning DID numbers for FXO.

Generating the ANI

When the PBX generates an outbound call on a trunk, it checks if the SIP URI in the To/From-Header and the identity headers (P-Preferred-Identity, P-Asserted-Identity or Remote-Party-ID) already have the user=phone flag. If that is the case, those numbers remain unchanged.

If they do not contain the flag, the PBX checks the following locations:

• If the local account has an ANI number set, it replaces this number. Every extension or any other account that has a dial plan also has an ANI number field, where this value can be set. By entering this information it is clear how this account will be presented to the outside world.

• If that ANI is not set, the PBX checks if there is a Prefix set in the trunk. If this is the case, it puts the prefix in front of the primary account number and uses that as ANI. This is very useful in cases when a trunk deals with a range of numbers (typical outside of the NANPA area, e.g. Europe). The "extension" number is just put behind the prefix.

• Otherwise, the PBX checks if the DID number has been set for this trunk. If this is the case, the PBX just uses this setting. This is a typical scenario in the NANPA area, where a trunk has a primary number associated with it. When someone calls this number, the caller will typically hit an auto attendant that processes this DID number.

Representing the Source

The PBX differentiates between two numbers that need to be presented on the trunk.

• The first number is the "display" number. This number is the number that the user should see on the display of the phone. In the case of a redirected call, this number would be the original caller-ID that the PBX saw on the incoming call.

• The second number is the "network" number. That number is the number that the provider wants to see for billing purposes.

Over the last couple of years, different providers developed different ways to represent the two numbers:

• RFC3325 describes a way to represent these two numbers. In most cases it makes sense to use the "P-Asserted-Identity" header. In this case, the "From" header in the INVITE represents the display number, while the "P-Asserted-Identity" header has the network number.

• A similar representation can be done with the "P-Preferred-Identity" header. The PBX only changes the name of the header from "P-Asserted-Identity" to "P-Preferred-Identity"; the rest stays the same like in the first method.

• "No Indication" just discards the display number and uses only the network number in the "From" header. This method is a fallback when the provider cannot deal with any other method. The disadvantage here is clearly that any redirection information gets lost.

• The "Remote-Party-ID" is described in a draft that expired years ago; however there is still a lot of equipment outside that is supporting this method. In this case, the "From" header in the INVITE represents the network number, while the "P-Asserted-Identity" header has the display number.

• The method "RFC3325, but don't hide" should not be used. It is used in environments where the fields got mixed up, which is causing even more confusion.