How LRN Lookup Works

Step 1: The NPAC Source

All LRN data originates at NPAC (the Number Portability Administration Center), operated by iconectiv under FCC authority. When a subscriber ports their number, the gaining carrier submits a porting order to NPAC. NPAC validates it and updates its authoritative database.

Step 2: LRN Data Distribution

Once NPAC processes a porting event, it distributes the update to authorized service providers in near-real-time. Authorized providers (like SIPSmart) maintain a continuously-updated replica of the NPAC database, receiving change notifications within seconds of porting completion.

Step 3: The LRN API Query

When a VoIP carrier receives a call to route, their softswitch fires an LRN lookup before selecting an outbound trunk. The query contains the DNIS (dialed number) and returns:

• The LRN (current routing address)
• OCN (terminating carrier identifier)
• SPID (service provider ID)
• Rate center and LATA
• Ported status flag

Step 4: Redis Caching

Production LRN services use multi-tier Redis caching to handle high call volumes without overloading the primary database. Hot numbers (frequently called) are served from memory at sub-millisecond latency. Cache TTLs are calibrated against porting frequency — typically 30–60 seconds for active porting periods, longer for stable ranges.

Step 5: SIP Routing Decision

The LRN is passed to the carrier's LCR (Least Cost Routing) engine or routing table. Instead of routing by DNIS NPA-NXX, the switch routes by LRN prefix — selecting the interconnect that reaches the terminating carrier identified by the OCN.

SIPSmart Infrastructure Architecture

SIPSmart's LRN lookup infrastructure uses:

• NPAC-direct connection for authoritative data
• Multi-node distributed U.S. infrastructure for nationwide geographic optimization
• L1 Redis cache (in-memory, <1ms) for hot number ranges
• L2 SSD-backed MySQL replica (2–5ms) for cold path
• L3 NPAC live query (8–12ms) for very recent ports not yet cached