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

From: James Yu <[email-masked]>
Date: Mon, 13 Dec 1999 14:17:05 -0600

Matt,

It is a good summary of the key points.  You mentioned iptel that I forgot
to cc to.  So I'm adding it to the cc list.

My point is that the WGs should address their respective agendas while
keeping those issues in mind so that the solution(s) developed by each
individual WG can all work together.

James

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Monday, December 13, 1999 3:01 PM
To: James Yu
Cc: [email-masked]'; [email-masked]'
Subject: Re: [Enum] Nation-Specific ISUP implementations, Overlap
Signaling & Number Portability Database Queries

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

---------
This message came from the IETF IPTEL Working Group Mailing List.