To the Clearwater community,
In this sprint, we're looking to add (partial) support for number portability.
I've put a description of the changes we're planning to make - please do let us
know if you have any feedback on them!
### Background ###
Number portability (NP) allows subscribers to keep their numbers if they change
their service provider, move to a new location, or change what services they've
subscribed to. The original number may not be directly routable after it's been
ported. A deployment trying to route a request to this number must therefore
find out how to first route the call to the correct new deployment. This is
typically provided by a routing number (a value that can be translated into a
route to the correct deployment) that's discovered through ENUM.
In SIP, the NP information is carried in the rn and npdi parameters in the
request URI. The rn parameter contains the routing number that allows a request
to be routed to the correct deployment. The npdi parameter is an indicator for
whether NP information has already been looked up for a request. There are
other routing parameters (e.g. rn-context), but these are not covered by this
sprint.
We're expecting NP information to be conveyed through ENUM lookups. An example
of an ENUM record containing NP data (defined here as including the npdi or rn
parameters) is:
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+pstn:tel"
"!^.*$!tel:+1-215-555-0123;npdi;rn=+1-215-555-0199!".
This result should be interpreted as "the number +1-215-555-0123 has been
ported, and "+1-215-555-0199" should be used to route the call to the correct
deployment". Note that this value is used for routing, and doesn't correspond
to an actual number. It's expected that the same value is used for all
subscribers on a deployment (e.g. the ENUM lookup will return the same routing
number for all subscribers ported from deployment A to deployment B, and
deployment A will be able to use this routing number to route the request to
deployment B)
Another example of an ENUM record containing NP data is:
$ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+pstn:tel"
"!^.*$!tel:+1-215-555-0123;npdi!".
In this case the ENUM result should be interpreted as showing that the number
hasn't been ported - as there's no rn parameter, but the NP status has been
looked up - as there's a npdi. If there are multiple ENUM records for the
number (e.g. off-net and on-net results), then the RFC doesn't mandate how the
user should choose between them. It's expected that the user will control this
by setting different preferences on the NAPTR records.
So what are we going to change?
The BGCF is enhanced to support ENUM lookups and, if the ENUM lookup returns NP
information, to route the request accordingly. The I-CSCF and S-CSCF are also
updated to support ENUM lookups returning NP information, and to process
requests based on the results. The ENUM service is enhanced to support the
Enumservice 'PSTN', with subtype 'tel' when doing NAPTR lookups (as this is the
typical way of receiving NP information).
In more detail, the changes are:
### Configuration ###
A new configuration option, override_npdi, is added. If this is set to true,
then the I-CSCF, S-CSCF and BGCF will perform an NP lookup and processing even
when the request URI has npdi set. This defaults to false. This option is
necessary as sometimes the NP data can be out of date, and preventing a
re-lookup will cause a request to fail.
The BGCF configuration file is enhanced to accept routing numbers as well as
domains. A single entry in the JSON file must provide either a domain or a
routing number value (not both).
An example of the new BGCF file format is:
{
"routes" : [
{ "name" : "<routing using a domain>",
"domain" : "<SIP trunk IP address or host name>",
"route" : ["<IBCF SIP URI>", "<IBCF SIP URI>"]
},
{ "name" : "<routing using a routing number>",
"routing number" : "<routing number value>",
"route" : ["<SIP URI>" , "<SIP URI>"]
}
]
}
### ENUM ###
The (DNS) ENUM service already supports NAPTR records for ENUM lookups.
To receive number porting records, the Clearwater ENUM service is enhanced to
accept "E2U+pstn:tel" NATPR records.
### BGCF ###
The BGCF is enhanced so that if it:
* Receives a request where the request URI represents a telephone
number and
* The request URI does not contain the 'npdi' parameter, or
* The request URI does contain the 'npdi' parameter but override_npdi
is true.
Then it will do an ENUM lookup to attempt to retrieve NP data.
If NP data is successfully retrieved by the BGCF, it updates the request URI by
adding the 'npdi' parameter and, if the number has been ported, the ported-to
number in the 'rn' parameter. If the request URI is a SIP URI, the npdi and rn
parameters are added to the userinfo part of the SIP URI.
The BGCF then routes the request based on the 'rn' parameter if present,
otherwise it routes the request as normal.
Routing on routing numbers is very similar to routing on domains. In both cases
the routing number/domain value is looked up in the bgcf.json file and, if
there is a match, a set of routes is returned to use for routing the request.
To make this simpler to configure, the received routing number has its dashes
stripped (so +1-655-5 is converted to +16555) before it's checked against the
stored BGCF configuration. No other changes to the routing number are made, and
only exact matches are accepted (e.g. +16555 does not match 16555).
### I-CSCF ###
In terminating processing, if the I-CSCF makes an unsuccessful user location
query where the HSS response is that the user doesn't exist, and the
request-URI is a Tel URI (note any SIP URIs that represent a telephone number
will have already been converted to Tel URIs at this point), then the I-CSCF
attempts to convert the Tel URI into a SIP URI using an ENUM lookup.
The I-CSCF is enhanced so that if:
* The translation to a SIP URI (that doesn't represent a telephone
number) fails, and
* The ENUM response includes NP data
Then the I-CSCF updates the request URI by adding the 'npdi' parameter and, if
the number has been ported, the ported-to number in the 'rn' parameter.
If the request URI already contained the npdi parameter before the ENUM lookup,
then the I-CSCF will only update the request URI if explicitly configured to do
so (where override_npdi is true). The ENUM lookup will always be done as it
could successfully route to a SIP URI.
The I-CSCF then routes the request to the BGCF.
If the ENUM lookup successfully translates the URI to a SIP URI (that doesn't
represent a telephone number), then any NP data returned with the SIP URI is
ignored.
### S-CSCF ###
At the end of originating processing (so after routing to application servers),
if the request URI represents a telephone number then the S-CSCF attempts to
convert this into a SIP URI through an ENUM lookup.
The S-CSCF is enhanced so that if:
* This translation to a SIP URI (that doesn't represent a telephone
number) fails, and
* The ENUM response includes NP data
Then the S-CSCF updates the request URI by adding the 'npdi' parameter and, if
the number has been ported, the ported-to number in the 'rn' parameter. If the
request URI is a SIP URI, the npdi and rn parameters are added to the userinfo
part of the SIP URI.
If the request URI already contained the npdi parameter before the ENUM lookup,
then the S-CSCF will only update the request URI if explicitly configured to do
so (where override_npdi is true).
The S-CSCF then routes the request to the BGCF.
If the ENUM lookup successfully translates the URI to a SIP URI (that doesn't
represent a telephone number), then any NP data returned with the SIP URI is
ignored
If you want more information on number portability, then the relevant
specifications for this change are:
* TS 24.229 - IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP)
* RFC 4769 - IANA Registration for an Enumservice Containing Public
Switched Telephone Network (PSTN) Signaling Information
* RFC 4694 - Number Portability Parameters for the "tel" URI
_______________________________________________
Clearwater mailing list
[email protected]
http://lists.projectclearwater.org/listinfo/clearwater
