Subject: Nation-Specific ISUP implementations, Overlap Signaling & Number Portability Database Queries

From: James Yu <[email-masked]>
Date: Mon, 13 Dec 1999 10:20:23 -0600

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.

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 13 Dec 1999 15:00:56 -0500

You certainly seem to pack alot of things into this note.  An attempt to
summarize:
(a) ISUP interworking between gateways
(b) Call routing decisions based on ISUP capabilities
(c) Timing/location of portability query
(d) Complexity of originating switch performing NPDB queries due to
national variants
(e) Overlap signalling and its complexities to call signalling,
particularly international

Here's a 2-bit opinion on some of these things...

(a) ISUP interworking was discusesed for a bit in IPTEL, and it looked
like the consensus was that gateways must be ready to fall back to some
common denominator ISUP capability set if they don't support any common
ISUP variation.

(b) Right now, the call routing portion of the solution (TRIP) is not
considering ISUP variations when making call routing decisions.  It was
discussed, but the consensus appeared to be that falling to a common
international capability set was an acceptable solution.  So it looks
like ISUP variations won't impact the route the call takes to a
destination gateway.

(c) By just reading the notes, it looks like there might be consensus to
perform the portability query before initiating the call and accessing
things like call routing.

(d) I would hope that enum does not require the querier to know all of
the possible national variants to NPDB queries.  Enum should define a
common query mechanism that is independent of national variants.  The
system should be a superset of the national variants and be able to
coordinate the information across nation's boundries.  Without this, the
whole thing seems like very unhelpful.  Enum queries really have to be
international.  

(e) About a month ago there was alot of discussion on overlap signalling
in SIP.  If you haven't read the discussion, you might want to review
it.  There were several proposals on how to handle it.  I don't recall
how well the interaction between overlap signalling and LNP was
discussed, but I recall it being mentioned a few times.  I'm sure others
can provide further elaboration of those discussions.    

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

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 13 Dec 1999 12:08:42 -0500

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.

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.

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.

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.

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.

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
>
>