Configuring and Understanding LRN Dipping and Number Portability
Local Routing Number (LRN) Dipping - Sequence of routing to terminate calls to a customer's phone number, inclusive of a Service Control Point server, to cater for Number Portability.
Number Portability - Entitles owner of number to reassign their existing phone number to another carrier, location, service or provider.
The resulting configuration of both LRN Dipping and Number Portability, given the relative nature, is completed by the same method in your Sippy Softswitch.
Configure LRN Dipping and Number Portability
LRN Provider will provide you with the required credentials for the configuration of LRN Dipping process for your calls, enabling LRN and resulting Number Portability routing.
1. Add LRN server details to "System Parameters/ SIP, Media, LRN" section menu(see how to search it in step 4). LRN Server Address is listed as an IP address/hostname for the external LRN Server.
1.1 Custom port is supported (starting from Sippy 2020). In all earlier versions, it's hardcoded to send the INVITE to LRN server to his 5060 port, thus only IP address/hostname at no port is expected there.
1.2 More than one LRN server could be configured as a comma-separated list starting from Sippy 2021
2. A set of timeouts could be configured for LRN:Server Address is listed as an IP address for the external LRN Server.
2.1 LRN Server Timeout - the time the system must wait to receive an answer from the LRN server, before trying next LRN server in the list. Note, that this timeout is superseded by LRN Request(Total) Timeout, which limits the total amount of time dedicated to performing LRN lookup for the call. Available starting from 2021 version.
2.2 LRN Request(Total) Timeout (seconds): global timeout for all LRN servers. It's the time system dedicates for LRN lookups before routing the call using CLD. Available starting from 5.2 version.
3. If caching of past requests to LRN provider is needed, set the checkbox Enabled LRN Cache and select needed value for LRN Cache Expires in. Sippy stores LRN results for the set period of time, between 1 day and 3 months.
Please navigate the appropriate section:
4. If Vendor requires to get the number received from LRN server in RURI, starting from Sippy 2021 it's possible to add it by enabling Add LRN to RURI option.
5. Enable LRN in your specified Routing Group. With LRN server configured, LRN lookup would be performed for any outbound call that is terminated through this Routing Group, either in cache or by doing an extra lookup to the LRN provider - IF Enabled LRN Cache checkbox was not set, every call through such Routing Group would trigger lookup to LRN provider
6. Specify LRN Translation Rule if required, according to our Understanding Number Translation. The listed rule of "s/^/1/" for example will add prefix "1" to every LRN query routed to your LRN provider, and will result in the call being charged according to your "1*" prefix Tariff
7. Ignore LRN checkbox in the Vendor's Connection properties. If enabled then LRN CLD will be ignored for this routing entry and system will use prefix from route of matching destination set for the original CLD, using the rate from the tariff with LRN CLD to charge the customer for the call.
The resulting CDRs for the routed calls according to LRN Dipping and Number Portability will be shown with an LRN_CLD in the report.
Note: starting from 5.2 version when Local Calling is configured, Sippy might do extra lookup for CLI - in such case LRN_CLI would be added in CDR report.
More information regarding fields on System Parameters page could be found in following documentation:
The call flow with enabled LRN dipping is as follows:
1. Call comes in.
2. The Sippy softswitch applies the CLD Translation Rules from Authentication Rules and Account to the original CLD.
The resulting CLD would be referred as 'The CLD'. More details on number translation could be found here.
3. Sippy sends the INVITE request to the LRN server with the CLD.
4. The LRN response is rewritten with the 'LRN Translation Rule'.
Let's call the result the "LRN CLD".
Example of the reply received from LRN provider:
|SIP/2.0 302 Moved Temporarily|
Via: SIP/2.0/UDP xxx.xxx.xxx.180:5067;branch=z9hG4bK015131aa1ae069e0e0aa0b56d6c66b8a;received=xxx.xxx.xxx.180;rport=5067
From: "1 CALL CONNECT" <sip:firstname.lastname@example.org>;tag=0b42b2e5764aba75101d202cc511ee7b
CSeq: 200 INVITE
Server: Cisco 3845
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
>>> Contact: Transfer <sip:131xxx8709;npdi;email@example.com>
The following string should be received from vendor for the case the number has changed:
|Contact: Transfer <sip:131xxx8709;npdi;firstname.lastname@example.org>|
Mandatory parameters should be placed from the left side from @
- npdi - the LRN server indicated that the number has changed
- rn - the routing number, LRN CLD is followed after rn=
- the routing number (after rn=) should be followed with @ symbol
- hostname/IP address after @ symbol
Sippy requires all three parameters to use this LRN dipping result in the billing, violation of the syntax or missing of one of the parameters forces to skip the LRN dipping result.
Only the routing number (213xxxx933) is used from the whole 302 Moved temporarily packet.
Routing number MUST be followed with @ sign, after @ sign there MUST be the host/IP, so that we distinct the username in the routing number from the host name.
All other cases would be treated as if we have not received anything from LRN provider:
|Contact: Transfer <sip:131xxx8709;>|
The LRN provider could also send us the format of the contact string that we can not recognize properly
for instance, without one of the mandatory parameters like npdi, thus we'll skip the dipping results as well for such cases
|Contact: Transfer <sip:131xxx8709;npdi;>|
|Contact: Transfer <sip:131xxx8709;npdi;rn=>|
|Contact: Transfer <sip:131xxx8709;rn=213xxxx933>|
|Contact: Transfer <sip:131xxx8709;npdi;rn=213xxxx933>|
|Contact: Transfer <sip:131xxx8709;npdi;rn=213xxxx933@>|
In all cases above the LRN CLD won't be extracted from the packet.
5. The softswitch charges the Account with the rate based on the LRN_CLD.
If no LRN CLD was received from vendor side then charge will be applied based on the original CLD.
5.1 If LRN is enabled and prefix for LRN_CLD hasn't been found in the Tariff, the call will be rejected with No Rate Found
6. The softswitch selects the list of Routing Entries from Routing Group with matching Vendor Connections to send the call to based on the LRN_CLD
unless the option 'Ignore LRN' in the connection is checked, then, then Original CLD is used.
Note, routing will be applied for the connections with the original CLD and LRN CLD based on the routing policy.
6.1. If LRN is not ignored, then the Destination Set is searched for a prefix based on the LRN CLD and call is sent out with the non-LRN CLD (just original CLD) rewritten with Vendor Connections' CLD Translation Rule.
6.2. If LRN is ignored, then the Destination Set is searched for a prefix based on non-LRN CLD (just original CLD) and call is sent out with the non-LRN CLD (just original CLD) rewritten with Vendor Connections' CLD Translation Rule.
6.3 If LRN is enabled and prefix for LRN CLD hasn't been found in the Destination Set, corresponding Routing Entry won't be used for this call, if no matching Routing Entries are found, the call will be rejected with No Route Found error.
In CDRs you can only see original CLD, LRN CLD is not being displayed there. As long as LRN CLD is only used for billing/routing ( not for actual call setup) you can see a new parameter "Billing Prefix" for vendor download CDRs and customers CDRs on selfcare.
There is no need to add LRN IP as vendor.
Starting from 2020 version it's possible to put LRN CLD (rn/ndpi) in RURI of outgoing INVITE to Vendor.
This could be achieved by setting checkbox Add LRN to RURI in System Parameters - SIP, this change would affect calls to any Connection in Environment
Shorthand route sequence:
- Received ORIG_CLD
- Apply auth. CLD tr rule for the ORIG_CLD, got CLD
- Apply account CLD tr rule for the CLD, got CLD
- LRN sent a request with CLD (LRN IP should be only in "system parameters"), received in response something like LRN_CLD
- Searching routes by LRN_CLD(use "Enable LRN" in the Routing Group), but use plain CLD for actual call
- For each route:
6.1 Apply vendor->connection -> "CLD tr rule" for the CLD, as result got CLD_OUT
6.2 Send calls out via connection with CLD_OUT