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 required credentials for configuration of LRN Dipping process for your calls, enabling LRN and resulting Number Portability routing.
1) Add LRN server details in your System Parameters menu. LRN Server Address is listed as IP address of external LRN Server.
No port is supported yet, it's hardcoded to send the INVITEs to LRN server to his 5060 port, thus only IP address is expected there.
2) Select your LRN Cache Timeout. Sippy stores LRN results for the set period of time, between 1 day and 3 months.
3) Enable LRN in your specified Routing Group. With LRN option enabled, the call will be charged according to tariff relating to prefix of number received in LRN field.
4) 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.
- Resulting CDR's of routed calls according to LRN Dipping and Number Portability will show with LRN_CLD in report.
'Enable LRN' checkbox and 'LRN translation Rule' text field have been added to the Routing Group properties. For the case there is no Enable LRN checkbox on the routing group, no LRN lookup would be done.
'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.
'LRN server address' field in System Parameters - IP address of your LRN provider
'LRN cache timeout' field in System parameters - time for keeping number and translated number in cache, should be added in "system parameters". The cache is checked before doing the lookup to the LRN server.
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. We'll relate to the resulting CLD as 'The CLD'.
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:email@example.com>;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;firstname.lastname@example.org>
The following string should be received from vendor for the case the number has changed:
|Contact: Transfer <sip:131xxx8709;npdi;email@example.com>|
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.
6. The softswitch selects the list of Vendor Connections to send the call to, based on the Original CLD
depends upon the option 'Ignore LRN' in the connection, if the checkbox is not enabled, then LRN_CLD is used.
Please 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 the CLD and call is sent out with the 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, the call will be rejected.
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.
Please note, There is no need to add LRN IP as vendor.
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