Local Number Portability - Revision history

Cbilodeau: fix column width

2015-04-28T18:02:56Z

fix column width

← Older revision		Revision as of 14:02, 28 April 2015
Line 15:		Line 15:

	{\| cellpadding="5" border="1" class="wikitable"		{\| cellpadding="5" border="1" class="wikitable"
	! Scenario		! width="150" \| Scenario
	! Description		! Description
	! TelcoBridges support		! TelcoBridges support

Atremblay: Updated page with regards to redirections

2015-04-28T17:51:49Z

Updated page with regards to redirections

@@ Line 10: / Line 10: @@
 When the first subscriber within an NPA-NXX group changes service providers, the entire NPA-NXX is considered “ported” (all 10k numbers) which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange.   Every call to that NPA-NXX will trigger a query to a database to determine the LRN of the number of the switch responsible for the NPA-NXX-XXXX being called.
-=== Implementation of LNP relay ===
+=== LNP and TelcoBridges ===
-Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translates' mode or not by looking at the content of the ISUP message.  If the ISUP call does not contain any LNR number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly.  Although TelcoBridges's Toolpack framework does not make the actual query to the database (also known as the 'DP' [pronounce 'dip']), it is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body.  What is relayed and how it is relayed depends on the profile configuration options.
+TelcoBridges products support the LNP use cases described by the following table.
-==== Configuration ====
+{| cellpadding="5" border="1" class="wikitable"
 Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts.  Through all the [[Routing_script_tutorial:Mini_Development_Guide#Script_parameters_protocol_mapping|routing script variables]] accessible to scripts are some related to LNP such as 'ported_number'.   The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP.  Then its mapping to the outgoing call depends on configuration parameters of the profile for the outgoing NAP.
 [[Toolpack:Modify_NAP_profile_A|Configuring LNP in v2.6]]

Cbilodeau: move configuration content to web portal tutorial guide (profile)

2012-12-10T21:30:13Z

move configuration content to web portal tutorial guide (profile)

@@ Line 14: / Line 14: @@
 Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translates' mode or not by looking at the content of the ISUP message.  If the ISUP call does not contain any LNR number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly.  Although TelcoBridges's Toolpack framework does not make the actual query to the database (also known as the 'DP' [pronounce 'dip']), it is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body.  What is relayed and how it is relayed depends on the profile configuration options.
-==== Call flow and configuration options ====
+==== Configuration ====
 Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts.  Through all the [[Routing_script_tutorial:Mini_Development_Guide#Script_parameters_protocol_mapping|routing script variables]] accessible to scripts are some related to LNP such as 'ported_number'.   The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP.  Then its mapping to the outgoing call depends on configuration parameters of the profile for the outgoing NAP.
-===== Incoming call mapping =====
+[[Toolpack:Modify_NAP_profile_A|Configuring LNP in v2.6]]

Cboulanger: Adjust table title to be more precise

2012-09-17T15:20:55Z

Adjust table title to be more precise

← Older revision		Revision as of 11:20, 17 September 2012
Line 35:		Line 35:
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
	! ~~Parameter~~ !! SS7 !! SIP		! Incoming NAP conf. !! Incoming SS7 !! Incoming SIP
	\|-		\|-
	\| Ignore \|\| CPN => called <br />GAP => X \|\| CPN => called <br />RN => X		\| Ignore \|\| CPN => called <br />GAP => X \|\| CPN => called <br />RN => X

Cboulanger: Adjusted indentation for table

2012-09-17T15:19:12Z

Adjusted indentation for table

@@ Line 69: / Line 69: @@
 {| class="wikitable"
 |-
-! Parameter !! SS7 !! SIP
+! Outgoing NAP config.!! Outgoing SS7 !! Outgoing SIP
 |-
-| No insertion || bitM = 0<br />if ported_number then<br />ported_number => CPN<br />called => X<br />else<br />called => CPN || RN and ndpi not present<br />if ported_number then<br />ported_number => CPN<br />called => X<br />else<br />called => CPN
+| No insertion || bitM = 0<br />if ported_number then<br />
 |-
-| Always || bitM = 1<br />ported_number => GAP<br />called => CPN || ndpi=yes<br />if ported_number then<br />called => RN<br />ported_number => CPN<br />else<br />called => CPN<br />RN not present
+| Always || bitM = 1<br />ported_number => GAP<br />called => CPN || ndpi=yes<br />if ported_number then<br />
 |-
-| Relay || called=>CPN<br />if ported_number then<br />bitM = 1<br />if ported_number is empty then<br />ported_number => X<br />else<br />ported_number => GAP <br />else<br />bitM = 0 || if ported_number then<br />ndpi=yes<br />if ported_number is empty then<br />called => CPN<br />RN not present<br />else<br />called => RN<br />ported_number => CPN<br />else<br />called => CPN
+| Relay || called=>CPN<br />if ported_number then<br />
 |}

Cboulanger: /* Incoming call mapping */

2012-09-17T15:07:49Z

Incoming call mapping

@@ Line 41: / Line 41: @@
 | Terminate || GAP => called<br />CPN => X  <br />ported_number not available  || CPN => called<br />   RN => X<br />    ported_number not available
 |-
-| Forward || if bitM=1 then<br />"" => ported_number<br />if GAP then<br />CPN => called<br />GAP => PNB<br />else<br />CPN => called || if npdi=yes then<br />"" => ported_number<br />if RN then<br />CPN => ported_number<br />RN=> called<br />else<br />CPN => called
+| Forward || if bitM=1 then<br />
 |}

Cboulanger: /* Outgoing call mapping */

2012-09-17T01:26:34Z

Outgoing call mapping

← Older revision		Revision as of 21:26, 16 September 2012
Line 50:		Line 50:
	<br />		<br />
	[[File:LNP_profile_outgoing.PNG\|500x\|750px]]		[[File:LNP_profile_outgoing.PNG\|500x\|750px]]
			<br />
	<br />		<br />
	The following table contains the pseudo-code of the mapping to the outgoing call according to the configuration AND what was present in the routing script variables:		The following table contains the pseudo-code of the mapping to the outgoing call according to the configuration AND what was present in the routing script variables:
	~~<br />~~
	<br />		<br />
	{\| class="wikitable"		{\| class="wikitable"

Cboulanger: /* Outgoing call mapping */

2012-09-17T01:26:21Z

Outgoing call mapping

← Older revision		Revision as of 21:26, 16 September 2012
Line 47:		Line 47:

	The image below shows the different configuration options available and affect on how the system will map the '''outgoing''' call information into the script variable available during routing.		The image below shows the different configuration options available and affect on how the system will map the '''outgoing''' call information into the script variable available during routing.
			<br />
	<br />		<br />
	[[File:LNP_profile_outgoing.PNG\|500x\|750px]]		[[File:LNP_profile_outgoing.PNG\|500x\|750px]]
	<br />		<br />
	The following table contains the pseudo-code of the mapping to the outgoing call according to the configuration AND what was present in the routing script variables:		The following table contains the pseudo-code of the mapping to the outgoing call according to the configuration AND what was present in the routing script variables:
			<br />
	<br />		<br />
	{\| class="wikitable"		{\| class="wikitable"

Cboulanger: /* Incoming call mapping */

2012-09-17T01:26:06Z

Incoming call mapping

← Older revision		Revision as of 21:26, 16 September 2012
Line 22:		Line 22:
	<br />		<br />
	[[File:LNP_profile_incoming.PNG\|500x\|650px]]		[[File:LNP_profile_incoming.PNG\|500x\|650px]]
	<br />		<br /><br />
	The following table contains the pseudo-code of the mapping according to the configuration AND the content of the incoming call signaling:		The following table contains the pseudo-code of the mapping according to the configuration AND the content of the incoming call signaling:
	<br />		<br />

Cboulanger: /* Implementation of LNP */

2012-09-17T01:25:40Z

Implementation of LNP

← Older revision		Revision as of 21:25, 16 September 2012
Line 10:		Line 10:
	When the first subscriber within an NPA-NXX group changes service providers, the entire NPA-NXX is considered “ported” (all 10k numbers) which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange. Every call to that NPA-NXX will trigger a query to a database to determine the LRN of the number of the switch responsible for the NPA-NXX-XXXX being called.		When the first subscriber within an NPA-NXX group changes service providers, the entire NPA-NXX is considered “ported” (all 10k numbers) which means that this particular NPA-NXX combination has become a portable number and no longer represents a specific exchange. Every call to that NPA-NXX will trigger a query to a database to determine the LRN of the number of the switch responsible for the NPA-NXX-XXXX being called.

	=== Implementation of LNP ===		=== Implementation of LNP relay ===

	Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translates' mode or not by looking at the content of the ISUP message. If the ISUP call does not contain any LNR number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly. Although TelcoBridges's Toolpack framework does not make the actual query to the database, it is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body. What is relayed and how it is relayed depends on the profile configuration options.		Most carriers and operators exposing ISUP interfaces to CLECs detects if an incoming call is in the 'translates' mode or not by looking at the content of the ISUP message. If the ISUP call does not contain any LNR number, then the carrier/operator switch does a query to the SS7 database to figure out the LRN and adjust the call information accordingly. Although TelcoBridges's Toolpack framework does not make the actual query to the database (also known as the 'DP' [pronounce 'dip']), it is able to terminate or relay a call from SIP to SS7 providing the LRN information is contained in the SIP body. What is relayed and how it is relayed depends on the profile configuration options.

	==== Call flow and configuration options ====		==== Call flow and configuration options ====

	Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts. Through all the [[Routing_script_tutorial:Mini_Development_Guide#Script_parameters_protocol_mapping\|routing script variables]] accessible to scripts are some related to LNP such as 'ported_number'. The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP.		Toolpack processes sequentially the incoming call by parsing the content of the signalling protocol and mapping it to "protocol-agnostic" internal variables that are accessible by the routing scripts. Through all the [[Routing_script_tutorial:Mini_Development_Guide#Script_parameters_protocol_mapping\|routing script variables]] accessible to scripts are some related to LNP such as 'ported_number'. The mapping of the information found in the incoming call depends on the option selected in the "incoming" parameters of the LNP section in the profile associated with the incoming NAP. Then its mapping to the outgoing call depends on configuration parameters of the profile for the outgoing NAP.

	===== Incoming call mapping =====		===== Incoming call mapping =====
	The image below shows the different configuration options available and affect on how the system will map the '''incoming''' call information into the script variable available during routing.		The image below shows the different configuration options available and affect on how the system will map the '''incoming''' call information into the script variable available during routing.
			<br />
	[[File:LNP_profile_incoming.PNG\|500x\|650px]]		[[File:LNP_profile_incoming.PNG\|500x\|650px]]
			<br />
	The following table contains the pseudo-code of the mapping according to the configuration AND the content of the incoming call signaling:		The following table contains the pseudo-code of the mapping according to the configuration AND the content of the incoming call signaling:
			<br />
	'''CPN''' = called party number or the TO sip header<br />		'''CPN''' = called party number or the TO sip header<br />
	'''called''' = called number variable accessible in routing script<br />		'''called''' = called number variable accessible in routing script<br />
Line 47:		Line 47:

	The image below shows the different configuration options available and affect on how the system will map the '''outgoing''' call information into the script variable available during routing.		The image below shows the different configuration options available and affect on how the system will map the '''outgoing''' call information into the script variable available during routing.
			<br />
	[[File:LNP_profile_outgoing.PNG\|500x\|750px]]		[[File:LNP_profile_outgoing.PNG\|500x\|750px]]
			<br />
	The following table contains the pseudo-code of the mapping to the outgoing call according to the configuration AND what was present in the routing script variables:		The following table contains the pseudo-code of the mapping to the outgoing call according to the configuration AND what was present in the routing script variables:

	<br />		<br />
	{\| class="wikitable"		{\| class="wikitable"