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.
    1.1 Custom port is supported starting from Sippy 2020, in earlier versions it's hardcoded to send the INVITE to LRN server to his 5060 port, thus only IP address is expected there.
    1.2 More then one LRN server could be configured as comma-separated list starting from Sippy 2021
  2. If needed, change LRN Request Timeout - the time in seconds Softswitch waits for reply from LRN server (added in Sippy 5.2). Starting from Sippy 2021 it's possible to setup the fixed timeout for cases where multiple LRN servers are specified, to request next LRN server from the list. Note, that this timeout is superseded by LRN request timeout, which limits total amount of time dedicated to perform LRN lookup for the call.
  3. If caching of past requests to LRN provider is needed, set 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.
  4. If Vendor requires to get number received from LRN server in RURI, starting from Sippy 2021 it's possible to add it by enabling the option in S
  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 extra lookup to 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. Resulting CDR's of routed calls according to LRN Dipping and Number Portability will show with LRN_CLD in 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.



Enable LRN checkbox and 'LRN translation Rule' text field have been added to the Routing Group properties. When Enable LRN checkbox is not selected on the routing group then, 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 Request Timeout field in System Parameters - the time in seconds Softswitch waits for reply from LRN server (added in Sippy 5.2)
LRN server address field in System Parameters - IP address of your LRN provider

Enabled LRN Cache and LRN Cache Expires in fields in System parameters - enable/disable local caching of successful LRN dips and time for keeping number and translated number in cache if it's enabled. 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. 

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;branch=z9hG4bK015131aa1ae069e0e0aa0b56d6c66b8a;;rport=5067
From: "1 CALL CONNECT" <sip:1110000000@>;tag=0b42b2e5764aba75101d202cc511ee7b
To: <>;tag=as53879514
CSeq: 200 INVITE
Server: Cisco 3845
Supported: replaces, timer
>>> Contact: Transfer <sip:131xxx8709;npdi;>
Reason: Q.850;cause=16
Content-Length: 0

 The following string should be received from vendor for the case the number has changed:

Contact: Transfer <sip:131xxx8709;npdi;>

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. 

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.

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:

  1. Received ORIG_CLD
  2. Apply auth. CLD tr rule for the ORIG_CLD, got CLD
  3. Apply account CLD tr rule for the CLD, got CLD
  4. LRN sent a request with CLD (LRN IP should be only in "system parameters"), received in response something like LRN_CLD
  5. Searching routes by LRN_CLD(use "Enable LRN" in the Routing Group), but use plain CLD for actual call
  6. 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