Local Number Portability (LNP)

Allows the IMG 2020 to route ported numbers for SIP and SS7. Routing on LNP is supported on the ANSI protocol only. Mapping of LNP parameters is supported on both ANSI and ITU. The IMG 2020 complies with the following:

• RFC3398 Section 7.2.1.1 (INVITE to IAM procedures) for SIP to SS7 call scenarios.

• RFC3398 Section 8.2.1.1 (IAM to INVITE procedures) for SS7 to SIP call scenarios

Generic Example

Below is call flow for a basic LNP scenario. Subscriber A (508-4445555) is calling Subscriber B (508-8623606). Subscriber B has been ported and the Local Exchange Carrier (LEC) servicing Customer B is Local Exchange Carrier 2 (LEC2) and its Local Routing Number is (333-2233445)

Open

The IMG 2020 does not perform the LNP. 

TAGS

The LNP feature adds the following tags into the R-URI Header.

Examples

SIP to SS7 Interworking

The Local Number Portability feature interworks the SS7 LNP information into SIP network. Refer to call flow diagrams below.

SS7 to SIP Call Flow

Open

SIP to SS7 Call Flow

SIP to SIP-I

Local Number Portability (LNP) allows a customer the ability to transfer either an existing fixed line or mobile telephone number assigned by a local carrier and reassign it to another carrier. The IMG 2020 now supports taking the LNP data in the R-URI on the SIP leg and interworking it into the R-URI and ISUP MIME on the SIP-I leg. The IMG 2020 also supports taking the R-URI message from the SIP-I leg and interworking it into the R-URI message on the SIP leg. This functionality is by default always enabled and does not need any special configuration for it to function.  

The LNP data in the IAM message is encapsulated in the GAP and FCI parameters. The GAP digits field carries the ported number (equivalent to RN tag). The FCI M-bit carries the ported number indication (equivalent to NPDI tags). For SIP-I, the LNP data in the R-URI and in the IAM are redundant. The IMG 2020 will retrieve the LNP data from the R-URI and the IAM message will not be parsed.

SIP-I to SIP scenario

SIP-I leg- The R-URI will be parsed to retrieve the LNP data (RN and NPDI tags).

SIP-I leg- The IAM in the ISUP MIME will not be parsed.

SIP leg- The LNP data will be relayed in the R-URI as RN and NPDI tags.

SIP to SIP-I scenario

SIP leg- The R-URI will be parsed to retrieve the LNP data (RN and NPDI tags).

SIP-I leg- The LNP data will be relayed in the outgoing SIP R-URI as RN and NPDI tags in the user-info part.

SIP-I leg- The LNP data will also be relayed in the outgoing IAM (ISUP MIME) as GAP and FCI parameters.

The LNP data is relayed between SIP and SIP-I and no processing of the data will take place.

SIP - SIP-I Call Flow

The Call Flow below represents the interworking of LNP from both SIP to SIP-I and SIP-I to SIP. The call flow displays a video call being received from MSC A in SIP-I format. The IMG 2020 will receive the call and will add the LRN and NPDI parameters into the INVITE message sent out on the SIP leg to the Video Gateway. The Call Flow below references the Call Trace that is linked in the Call Trace Example in next section.

Call Trace Example

Refer to the Call Trace - LNP (SIP-SIPI) topic to display the call trace for the call flow diagram above. 

Configuration

There is no configuration required. The LNP Handling of SIP to SIP-I feature by default is always enabled.

Additional Information (SIP-SIP-I)

• In the R-URI, the RN and the NPDI tags can be located in the “userinfo” part or in the “uri-parameters” part.

• The IMG 2020 will decode the tags at the two locations.

• The IMG 2020 will encode the tags only at the “userinfo” location.

·         When viewing a Call Trace and the Routing Number (rn) and Number Portability DIP indicator (npdi) are included in the INVITE messaging, the format can change dependent on the interworking scenario. Below is a table displaying the format for each scenario