SIP identity

With the growing popularity of VoIP services such as residential VoIP or business SIP trunking, the question of user identity becomes increasingly important, since the only critical piece of identity in a phone call is the caller number (also known as the CLI or ANI), and it is extremely easy to be forged. There is nothing that prevents an IP phone or PBX from placing a string into the “From:” SIP header that corresponds to the “Caller number.” When one receives a phone call that displays the caller number, for example, as 12065551234 – is it really the person who owns that phone number calling – or is it a fraudulent scam? The question of identity becomes more complex when a call traverses networks of several different service providers. Within this chain, only the first telco (the one the subscriber is directly connected to) can verify the end user’s identity; the other service providers must rely on the information that is provided as a part of the call data – so it is extremely important to know who your trusted contacts are. In many countries, strict regulations govern the responsibilities of service providers in regard to establishing the identities of their customers and passing this information on to the national telephony network or other carriers.

This is why there are several overlapping RFCs and technologies regulating the way the verified identity of the user is passed from one VoIP operator to another. PortaSwitch supports the most important ones and provides all required tools to conform to the requirements regarding the handling of the user identity.

A call is considered as coming from a trusted network if it originates via one of the nodes on your network (it is assumed that this node has already performed the required authorization and established the user’s identity, so the provided identity data will be reliable) or if it is coming from an external end-point that has been explicitly marked as trusted.

The process is split into three stages:

1. Extracting the user identity information from the incoming call information based on the incoming network/user trust settings:
   • For requests coming from the trusted network this is done in the following order: if P-Asserted-Identity data is available, then it is used as the identity CLI. Otherwise, if Remote-Party-ID (RPID) data is available, it is used as the identity.
   • When the network is not considered as trusted or neither of the above headers exist, the requested identity is extracted from the P-Preferred-Identity header or as a last resort, from the SIP From: header.
2. Deciding what the user identity should be, based on the user configuration (assigned by the PortaSwitch administrator – see below) and the data collected during the previous step.
3. Including the required identity data in the outgoing call information, based on the trust status of the user being called or terminating network.

On the PortaSwitch side, it is possible to set the following conventions for handling identity information:

• Never – accepts and continues relaying any identity value supplied by the remote party. This assumes that the remote party is trusted and undertakes full responsibility for the display number and name supplied.
• If Different From Account ID and Aliases – the identity could be the ID of the account that is authorized for the call – or any of the aliases assigned to this account. This allows a customer who is assigned two extra DIDs in addition to his primary number to place outgoing calls using any of these DIDs as his identity.
• If Different From All Customer Accounts – an identity is considered valid if it matches an account ID (or account alias) of any of this customer’s accounts. This is ideal for SIP trunking types of services, when a customer has his own PBX that contains multiple phone lines (extensions) provided on it. The supplied identity is fine as long as it matches one of the phone numbers provided for this customer.
• If Different From All Accounts in the Specified Batch – this is a more restrictive option than the one above as it requires that both the account that places the call and the account that matches the supplied identity are from the same batch. This allows you to create “groups” under the same customer. For example, if a UK user makes a call, this call will have an identity that matches any of the customer’s UK numbers; if a Canadian user makes a call, the identity used for this call will match any of the customer’s Canadian numbers. In this case, all UK and Canadian numbers will belong to their respective batches.
• If Different From All Accounts in the Specified Hunt group – this option requires that the account placing the call and the account that matches the supplied identity come from the same hunt group. This allows you to fine-tune the identity to be used for calls made by separate departments in your company. For example, calls made by the Sales department will have an identity that matches one of the extensions (phone numbers) from the hunt group “Sales,” while calls made by the Support department will have an identity that matches one of the extensions from the hunt group “Support.”
• If Different From All Accounts in the Specified Site – this option requires that the account placing the call and the account that matches the supplied identity come from the same customer site. This allows you to manage the identity for groups of accounts that come from the same customer (within the same PBX environment). For instance, if a customer owns two PBXes – a call from PBX A may only have an identity that matches phone numbers associated with PBX A and a call from PBX B may only have an identity that is associated with the phone numbers managed by PBX B. In these cases, each PBX will be represented as a separate customer site.
• Always – the identity will always be set to the value defined in the Identity field.

INVITE sip:1555122321@1.2.3.4:5060 SIP/2.0

To: <sip: 1555122321@mycompany.com> 

From: Link <sip:106@mycompany.com>;tag=+NzXt1udpNgp.o

Call-ID: 1a56ed52-d54e-1236-c3a5-005056b57430 

P-Asserted-Identity: Link <sip:1555122320@ mycompany.com >

Remote-Party-ID: Link <sip:1555122320@ mycompany.com>;party=calling

If an end-point is not trusted, the identity information (P-Asserted-Identity) it supplies will simply be ignored. In this case, the end-point may only suggest the desired identity via the P-Preferred-Identity header. If the desired identity passes all of the validation rules, it can be used as the identity for the outgoing call. After that, the P-Preferred-Identity header is discarded from the outgoing call information and never sent to another IP phone or vendor.

Sometimes people think about the VoIP identity as the “caller number” – the number that the party being called will see. This is not true, however – in many cases, they can differ. For instance, when a caller requests anonymity (to hide his CLI/ANI number from the party being called) his identity will still be delivered to the telco. This is why in the SIP INVITE message, the identity information is transported in a separate header from the CLI/ANI data that is transported in the SIP From: header. The “Caller number” value that will be placed in the From: header is controlled by the Display Number property. The possible values are:

• Never – will allow the remote IP phone or PBX to supply any CLI/ANI number.
• If Ruled Out by the Identity Constraint – will apply the same restrictions as the ones placed on the identity information (described above).
• If Different from the Used Identity – similar to the above, but makes it obligatory for the displayed number to always be the same as the identity CLI, so if a remote party provides a CLI that is valid, but not identical to the identity – it will be replaced with the identity CLI.