Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signalin g & NumberPortability Database Queries

From: James Yu <[email-masked]>
Date: Wed, 15 Dec 1999 08:46:13 -0600

Bert,

Please see inserts marked by ****.

James

-----Original Message-----
From: Albert Manfredi [mailto:[email-masked]]
Sent: Monday, December 13, 1999 12:09 PM
To: James Yu; [email-masked]
Cc: [email-masked]
Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap
Signaling & NumberPortability Database Queries

I don't think I understand all the issues you're raising. But, on
the number portability database (NPDB) question, why not just map
each portable number only to an E.164 number in the NPDB? The DNS
could do that job quite well, I think.

**** It is not clear what "why not just map each portable number only to an
E.164 number in the NPDB?" means.  Please clarify. ****

For simple telephony devices, when a user dials a portable number,
the central office starts by querying the DNS or other similar
database. The reply is E.164, and the central office knows whether
this number is local, long distance, or international with respect
to itself. It knows this because it is programmed to know its own
country code and area code. So it knows how to translate that E.164
number into something it can dial. And it dials accordingly,
changing nothing from current practice.

**** I assume that the "E.164" in the reply means the routing prefix or the
LRN (with country code). ****

Smart terminals can query the NPDB (DNS) directly and translate the
E.164 number returned into something in the local dialing plan. Or
use the IP address, if available.

**** It is not clear why "local dialing plan" is involved in this example if
the smart device is already connected with the internet.   If the smart
terminal uses the internet to get the routing prefix or LRN but accesses the
SCN for call initiation, there is no way this "smart terminal" can provide
both the dialed number and the routing prefix/LRN to the SCN. ****

The simplest way to accommodate mobile terminals is to have them
operate through a home server, as if they are always at that home
location. This seems wasteful when one is roaming.

Alternatively, the mobile station, when accessing the the NPDB via
its roaming access base station, can have that base station
translate the E.164 number returned by the NPDB into the local
dialing plan.

**** It won't be a "base station" performing that function.  Either a mobile
(services) switching center (MSC) or some interworking function will perform
that function. But it is not clear why a mobile station will need to access
the NPDB directly unless it is the "smart terminal" you mentioned earlier
and is using Internet to reach the called party.  ****

But I don't think that most of these issues are enum wg issues. I
could be wrong. Also, I don't understand all the acronyms you use,
but maybe that's just me.

**** Please list those acronyms.  I can provide the info.  They might have
been provided in earlier messages. ****

Bert
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of James
> Yu
> Sent: Monday, December 13, 1999 11:20 AM
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: [Enum] Nation-Specific ISUP implementations,
> Overlap Signaling
> & NumberPortability Database Queries
>
>
> The following discussions focus on SCN-IP-SCN calls.
>
> There are nation-specific variatoins in ISUP
> implementations.  I don't know
> whether this issue has been discussed (I'm new to IETF).
> When we have only
> a few GWs, it is fine that those GWs support many ISUP
> implementations.  But
> when many GWs are deployed, it is not likely that every
> GW will support many
> ISUP implementations.  Some may be used only for domestic
> use.  So it is
> likely that an international call may need to be routed to an
> "international" GW (or more than one) that interworks between two
> nation-specific ISUP implementations.  To fully use the
> IP network, then the
> "international" GW will further route the call to a "domestic" GW
> (destination GW) that terminates the call into the SCN.
> The call can
> certainly be routed to the destination SCN but the call
> charge may be
> higher.
>
> This would seem to be inefficient that the user traffic
> must be routed
> through additional GW(s).  ISUP interworking probably can
> be done via a pure
> signaling conversion/mapping so that the user traffic can
> be routed directly
> to the destination GW.
>
> If we need to perform number portability queries, then a
> good place would be
> the destination "international" GW because it is close to
> the destination
> country and supports the destination country's Number
> Portability Database
> (NPDB) interface.  In that case, simple ISUP interworking
> mentioned above
> won't be sufficient.  A NPDB query also needs to be
> launched. The response
> to the NPDB query will decide the destination GW that
> should terminate the
> call.
>
> Due to number portability, the called party's serving SCN
> switch changes
> when the called user switches to a new service provider.
> Whenever that
> happens, the NPDB will reflect the current new serving
> switch or network
> information (via Location Routing Number in the North
> America or Routing
> Prefix in the Europe), and the "destination" GW that can
> reach the serving
> switch or network may change.  So a NPDB query is
> required to determine the
> correct GW to terminate the call.
>
> At ENUM, we have been discussing where to perform the
> NPDB queries.  The
> originating GW needs to support all nation-specific NPDB
> interfaces if it is
> to query those NPDBs.  This would be expensive.  Also
> there is an issue
> about the encapsulated ISUP message in the SIP if originating GW's
> nationa-specific ISUP message is encapsulated (may be
> everyone should use
> ITU-T ISUP that is used between international switches
> for communicating
> among the entities in the IP domain).  The destination GW
> can support
> specific NPDB interface; however, it may be the wrong GW
> because it cannot
> reach the serving switch in the SCN that serves the called party.
>
> Overlap signaling would make the issue more complicate.
> If the call routing
> decision is to route to the "international" GW, it is
> fine because number
> portability is confined within a national domain.  That
> "international" GW
> will then wait for additional address information and
> performs the NPDB
> query, if required.  But if the call is to be routed
> directly to the
> destination GW, and if the originating GW is the one to
> perform the NPDB,
> then it has to collect all the address information before
> it can launch the
> query.  But the issue is that the originating GW may not
> know it has
> collected all the address digits.
>
> It seems that the best entity that knows that it has
> collected all the
> digits and can perform the NPDB query would be the destination
> "international" GW.
>
> I have linked several issues (nation-specific ISUP
> implementations, number
> portability, and user traffic routing efficiency)
> together that need to be
> addressed as a whole.  There may be other issues.  It is
> hoped that one or
> more solutions can be identified and finalized.
>
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/enum
>

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 15 Dec 1999 14:35:36 -0500

> E.164 number in the NPDB?" means.  Please clarify. ****

I was suggesting here that the number portability database (NPDB)
would be a database which maps

portable number <---> E.164 "home" number,

in its simplest incarnation, and that therefore putting this
function within the existing DNS, as in

portable no.(as Internet name) <--> IP addr <--> E.164 (in AESA)

ought to work. A portable number is just a globally unique arbitrary
ID, after all, much like the Internet name is.

> LRN (with country code). ****

It means the standard E.164 format, with country code etc., but not
in any one national dialing plan. In the US, for instance, you would
have to add "011" in front of it to dial out.

> the smart device is already connected with the internet. ****

Because it is possible that the destination side is not
IP-connected. In the general case, the smart terminal might have to
initiate a telephone call, and the local dialing plan would be
needed. Or are you assuming the use of MEGACO or something like
that?

> **** If the smart

Not sure what this means.

> that function. ****

Good point.

> **** But it is not clear why a mobile station
> will need to access

Good point again, but again, the smart user might need to call a
dumb telephone. Take the case where I fly from Wash DC to Paris with
my roaming host, and want to dial a portable number of my French
buddy, who happens to be located in Paris. I want the number
returned from the NPDB to be translated into the local Paris
numbering plan. (Perhaps this is not a problem if we assume MEGACO.)
I would not want to make that local Paris call via Wash DC.

In any event, if a roaming mobile station needs to dial a non-IP
called party with portable number, that destination portable number
will need to be translated into the roaming station's _current_
national numbering plan. That was the only point I was trying to
make. Someone has to translate the E.164 number returned by the NPDB
into something that can be dialed locally. (This is not an enum
issue, though.)

> been provided in earlier messages. ****

SCN, LRN, and GW. I think GW means gateway. The others are obviously
telephone number formats.

Bert