Subject: RE: TRIP

From: "John Mainwaring" <[email-masked]>
Date: Wed, 8 Dec 1999 10:45:28 -0500

Generally I agree with your remarks.

Specifically, I agree that the destination gateway is too late to do the
query, unless you take an RTP-like approach.  In effect, the default
destination gateway is a proxy for the donor switch.  By the time you get
there, it's a bit late to do a query.  On the other hand, you probably don't
want to push the query all the way back to the originating gateway.  That
would require either that each gateway have knowledge of portability
information for every NPA-NXX in existence or that an LNP or equivalent
query be launched on every call.

I think you are suggesting that LNP queries should be done at intermediate
points that are "close enough" to the destination to be expected to know
about the portability status of the destination.  If so, I agree with you.

I also agree with your suggestion that there may be a need for specialized
NPDB nodes in the IP network.  I'm not sure what form it should take, but
the existing NPDBs are not only engineered for the PSTN, they are a cost
center in the PSTN, and I understand that there are charges associated with
using them.  It may be appropriate to use them, or it may be better to
explore other solutions.  The point is that it is necessary to do more than
wave our hands and say "An NPDB query happens somewhere."

You are right that the FCC ruled out Release to Pivot or any solution that
relies on the donor network to complete a call in the PSTN.  I doubt if they
were even aware of the possibility of VoIP at the time they made that
ruling.  There are significant ongoing costs associated with NPDBs.  It
seems appropriate to consider other architectures, especially since there is
so little legacy encumbrance in SIP right now.  It's probably true that an
appropriately administered NPDB (loaded directly from the NPAC, as Brian
suggested) is a more robust solution than anything that relies on the donor.
My question is whether an RTP solution might be sufficiently reliable to be
acceptable in practice and sufficiently cheap to be attractive.  As you
pointed out in connection with wireless number portability, the FCC doesn't
always impose the same burdens in new areas as it does in the legacy
environment.

-----Original Message-----
From: James Yu [mailto:[email-masked]]
Sent: Wednesday, December 08, 1999 3:32 AM
To: Mainwaring, John [NC2:3B30-I:EXCH]
Cc: [email-masked]'
Subject: RE: TRIP

-----Original Message-----
From: John Mainwaring [mailto:[email-masked]]
Sent: Tuesday, December 07, 1999 4:02 PM
To: 'Jonathan Rosenberg'
Cc: [email-masked]'; James Yu; [email-masked]'
Subject: RE: TRIP

|From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 

|I'm less sure about deferring the LNP query to N-1. In the SIP 
|architecture, 
|at least, each proxy is responsible for doing a translation function 
|(called the 
|location service), which is similar in concept to an LNP 
|database query. 

I understand that SIP is different from the tandem network of circuit
switches.  I think SIP will require the originator to know LNP information,
but I'm not sure that existing collection of SCPs accessed by the TCAP/SS7
signaling system is the place to get it.

 *********  For SCN to SCN via IP or IP to SCN calls, the internet is the
N-1 network (although many networks may be involved in the IP-domain
routing), the entity that performs the LNP query via TCAP/SS7 over IP or
real-time or non-real-time LNP-like mechanism via DNS) can be the
originating GW/GK/SIP server or an intermediate GW/GK/SIP server but won't
be the terminating GW/GK/SIP server because it may be too late to perform
LNP query to find out that it does not reach the serving switch identified
by the LRN.  There are certainly many issues if the originating GW/GK/SIP is
to perform the LNP query.  For example, several protocols can be used
between a switch and a NPDB.  In Europe, I heard that there are
country-specific variations to the switch-NPDB interface protocol.  For the
originating GW/GK/SIP server to query all the NPDBs worldwide would be a big
burden.  

One possible solution is that a standardized query can be launched by the
entity which will be mapped by an interworking like entity to
country-specific NPDB query to reach the existing NPDBs.  Another potential
solution is to have NPDBs in the internet that support the standardized IP
entity-to-NPDB interface.  Certainly this does not rule out that the
existing NPDB from being enhanced to support this new IP-domain interface.
*************

 |I'll also 
|note that I have been told that the LNP dip being done at the N-1 
|carrier is 
|only a north american thing, and that in Europe, its done differently. 

Of course. 

Actually, last I heard the Europeans were still considering Release to
Pivot, which might be a plausible model for SIP.  Initiate to the default
code owner first, and allow for a "refuse with redirection" or something. 
It's got its weaknesses, which include putting a burden on the donor of the
ported number and relying on an uninvolved third party to set up a call, but
it does keep the supporting infrastructure simple. 

******* Release to Pivot will not work in the U.S. because the FCC has ruled
out any solution that relies on the donor network to complete the call. 
Also, the "donor" switch and the "pivot" switch at least must be upgraded to
support this solution.  If the switch does not store the new LRN/routing
prefix information for a ported-out number, a database dip must be performed
in order to provide the LRN/routing prefix in the ISUP Release message.  If
a "donor" switch stores the information, the provisioning/administration of
the information is not a simple process. **********

Another interesting working model is wireless roaming.  It is capable of
dynamically redirecting you anywhere (at least within a continent or so) and
it works at the level of individual telephone numbers.  Of course a single
wireless operating company owns all the numbers in an NPA NXX, which avoids
the major problem LNP was designed to create.  (No, that's not a typo, it's
editorial comment.) 

Probably it's more of an administrative problem than a technical one.  It's
so easy to fall into the trap of thinking there are technical solutions to
administrative problems, although technical solutions can certainly help
perpetuate administrative problems. 

******** FCC has granted a delay for the wireless carriers in the U.S. to
support local number portability (LNP) because the new entrants - PCS
carriers are too busy in deploying their networks.  LNP is intended to help
the new entrants to compete with the incumbent carriers.  So if the new
entrants ask for a delay, FCC certainly has no reason to push wireless LNP. 
Also there are issues on roaming where the roaming markets may not be
required to support LNP (LNP is to be supported in the top 100 major
Statistical Trading Areas in phases).  But I believe that the delay is
temporary because FCC's goal may be nation-wide number portability which
allows the subscriber to switch from wireline service provider to a wireless
service provider and move from one location to another location.  The LRN
method will allow that with minimum system upgrades.  The major issue about
location portability is the call charing/rating.  If flat rate is used for
all toll calls (e.g., 10 cents per minute regardless of the distance between
the calling party and called party), location portability can be supported
easily. 

            Wireles is a similar model if we view the "donor switch" as the
"home" system" and the "serving switch" as the "vistied system."  However,
there are differences.  The "home system" in the wireless model is the
service provider of the "roamer."  It authorizes the visited system to
provide the services to the roamer and guarantees the payment even if the
subscriber does not pay his/her bill.  Also, Mobile Application Part (MAP)
is used between the visited and home systems to register the "roamer" and to
get a temporary routing number to route the call to the visited system. 
Either the call must always be routed through the home system to reach the
visited system or a query to the home system must be performed first to
perform optimal routing to the visited system directly.  NPDB approach
actually allows the query to be done (for optimal routing) without the
involvement of the "donor" network.  *************

 John Mainwaring 
Nortel Networks 
[email-masked]

---

From: "Mark D. Foster" <[email-masked]>
Date: Wed, 8 Dec 1999 15:14:44 -0500

RE: TRIPWhile the FCC did not specify in 95-116 any particular signaling or
implementation standards for LNP, they did establish a number principles
with which any implementation must comply, whether wireline or wireless.  As
examples, they did say that LRN met their requirements, and that RTP and QoR
did not.

A core requirement was that a carrier who is serving ported numbers need not
be reliant on any other carrier (especially the donor network) for
completing calls, whether for call transport/routing or for signaling.
That's not to say that a carrier couldn't voluntarily opt to use another
carrier or the donor for queries or call routing, but the key here is
voluntarily.  Again, this requirement was imposed on all LNP implementations
in the US regardless of the network technology employed.

Similar requirements were adopted by the CRTC for Canada, and as I
understand it, by regulatory and/or industry bodies in some other countries
with IN-based NP (e.g. Belgium, Spain).

As various edicts from the FCC stand now, the only form of IP telephony
exempt from these rules is where the called party uses a general purpose
computer (e.g. PC) as the telephony terminal, self-installed with telephony
terminal software (e.g. net2phone).  This use is considered an "enhanced
service" by the FCC, and therefore exempt.  All other forms of IP telephony
(e.g. cable set-up box, DSL modem, IP-based wireless terminal, IP trunk to
PBX) apparently must comply with existing rules for common carrier services.

That at least some forms of Iptel must comply with the non-reliance
requirement in at least some countries suggests that the SIP, TRIP, enum,
etc., must be flexible enough to allow implementations that will satisfy
these requirements, and still be interoperable with those that don't.

In the US and Canada, the key to this was the N-1 trigger placement policy.
This was simply a guideline on which networks should be prepared to dip
calls placed to which areas in order to not force calls to be re-routed at
the donor network (termination routing).  Key to having flexibility on where
triggers are placed, resulting in NPDB queries, is having a form of
post-query signaling that makes the query results available to all
downstream networks.

The key data elements in ANSI ISUP are: the LNP-query-done indicator (bit in
the FCI); placing a routing number returned from the NPDB in the CdPN (LRN
or whatever), and moving the original dialed number to a GAP.  Subsequent
call routing is done on the routing number, while not loosing the dialed
portable subscriber number.  Given the need for SIP to interoperate with
ANSI ISUP, there should be some consideration of implementing these
semantics.

If SIP captured these fields, so as to provide a post-dip form of downstream
signaling, and TRIP were designed to build route tables based on
administratively assigned number ranges (which, by definition would make
calls to routing numbers [LRN] routable) , and enum did not require DNS
queries to be answered by donor networks, then the existing regulatory
requirements for LNP could be met.

R, Mark

      Mark D. Foster
      CTO
      TEL: +1 202 533 2800, or 2702
      1120 Vermont Ave NW, Suite 550
     EMAIL: [email-masked]
      NeuStar, Inc.
      FAX: +1 202 533 2975
      Washington, DC 20005

  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of John
Mainwaring
  Sent: Wednesday, December 08, 1999 10:45 AM
  To: 'James Yu'
  Cc: [email-masked]'
  Subject: RE: TRIP

  -----Original Message-----
  From: James Yu [mailto:[email-masked]]
  Sent: Wednesday, December 08, 1999 3:32 AM
  To: Mainwaring, John [NC2:3B30-I:EXCH]
  Cc: [email-masked]'
  Subject: RE: TRIP

  -----Original Message-----
  From: John Mainwaring [mailto:[email-masked]]
  Sent: Tuesday, December 07, 1999 4:02 PM
  To: 'Jonathan Rosenberg'
  Cc: [email-masked]'; James Yu; [email-masked]'
  Subject: RE: TRIP

  I understand that SIP is different from the tandem network of circuit
  switches.  I think SIP will require the originator to know LNP
information,
  but I'm not sure that existing collection of SCPs accessed by the TCAP/SS7
  signaling system is the place to get it.

   *********  For SCN to SCN via IP or IP to SCN calls, the internet is the
  N-1 network (although many networks may be involved in the IP-domain
  routing), the entity that performs the LNP query via TCAP/SS7 over IP or
  real-time or non-real-time LNP-like mechanism via DNS) can be the
  originating GW/GK/SIP server or an intermediate GW/GK/SIP server but won't
  be the terminating GW/GK/SIP server because it may be too late to perform
  LNP query to find out that it does not reach the serving switch identified
  by the LRN.  There are certainly many issues if the originating GW/GK/SIP
is
  to perform the LNP query.  For example, several protocols can be used
  between a switch and a NPDB.  In Europe, I heard that there are
  country-specific variations to the switch-NPDB interface protocol.  For
the
  originating GW/GK/SIP server to query all the NPDBs worldwide would be a
big
  burden.

  country-specific NPDB query to reach the existing NPDBs.  Another
potential

   |I'll also

  Of course.

  Actually, last I heard the Europeans were still considering Release to
  Pivot, which might be a plausible model for SIP.  Initiate to the default
  code owner first, and allow for a "refuse with redirection" or something.
  It's got its weaknesses, which include putting a burden on the donor of
the
  ported number and relying on an uninvolved third party to set up a call,
but
  it does keep the supporting infrastructure simple.

  ******* Release to Pivot will not work in the U.S. because the FCC has
ruled
  out any solution that relies on the donor network to complete the call.
  Also, the "donor" switch and the "pivot" switch at least must be upgraded
to
  support this solution.  If the switch does not store the new LRN/routing
  prefix information for a ported-out number, a database dip must be
performed
  in order to provide the LRN/routing prefix in the ISUP Release message.
If
  a "donor" switch stores the information, the provisioning/administration
of
  the information is not a simple process. **********

  Another interesting working model is wireless roaming.  It is capable of
  dynamically redirecting you anywhere (at least within a continent or so)
and
  it works at the level of individual telephone numbers.  Of course a single
  wireless operating company owns all the numbers in an NPA NXX, which
avoids
  the major problem LNP was designed to create.  (No, that's not a typo,
it's
  editorial comment.)

  Probably it's more of an administrative problem than a technical one.
It's
  so easy to fall into the trap of thinking there are technical solutions to
  administrative problems, although technical solutions can certainly help
  perpetuate administrative problems.

  ******** FCC has granted a delay for the wireless carriers in the U.S. to
  support local number portability (LNP) because the new entrants - PCS
  carriers are too busy in deploying their networks.  LNP is intended to
help
  the new entrants to compete with the incumbent carriers.  So if the new
  entrants ask for a delay, FCC certainly has no reason to push wireless
LNP.
  Also there are issues on roaming where the roaming markets may not be
  required to support LNP (LNP is to be supported in the top 100 major
  Statistical Trading Areas in phases).  But I believe that the delay is
  temporary because FCC's goal may be nation-wide number portability which
  allows the subscriber to switch from wireline service provider to a
wireless
  service provider and move from one location to another location.  The LRN
  method will allow that with minimum system upgrades.  The major issue
about
  location portability is the call charing/rating.  If flat rate is used for
  all toll calls (e.g., 10 cents per minute regardless of the distance
between
  the calling party and called party), location portability can be supported
  easily.

              Wireles is a similar model if we view the "donor switch" as
the
  is used between the visited and home systems to register the "roamer" and
to

   John Mainwaring
  Nortel Networks

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Dec 1999 01:07:28 -0500

Mark Foster wrote:
> That at least some forms of Iptel must comply with the non-reliance requirement in at least some countries suggests that the
> SIP, TRIP, enum, etc., must be flexible enough to allow implementations that will satisfy these requirements, and still be
> interoperable with those that don't.
>  
> In the US and Canada, the key to this was the N-1 trigger placement policy.  This was simply a guideline on which networks
> should be prepared to dip calls placed to which areas in order to not force calls to be re-routed at the donor network
> (termination routing).  Key to having flexibility on where triggers are placed, resulting in NPDB queries, is having a form of
> post-query signaling that makes the query results available to all downstream networks.

I'm not really sure that the N-1 concept works that well in an IP
environment:

1. If you look at DNS as a similar service to LNP on the IP side, the
originating host does a name to address translation right away. This
happens even if the name thats being translated is "far away". This
avoids triangle routing, as has been discussed.

2. The interconnection of SIP servers and providers within the IP world
is not that rigid. I'm not sure how a SIP proxy would indeed determine
that it is the N-1th server in the chain.

In any case, determination of where the NPDB query is done is something
I don't think is within the scope of iptel to determine. All we need to
figure out is what kind of numbers are distributed in TRIP. Near as I
can tell, since LRNs still refer to the prefix of numbers served by a
switch, doing what we were doing all along works just fine. 

>  
> The key data elements in ANSI ISUP are: the LNP-query-done indicator (bit in the FCI); placing a routing number returned
> from the NPDB in the CdPN (LRN or whatever), and moving the original dialed number to a GAP.  Subsequent call routing is
> done on the routing number, while not loosing the dialed portable subscriber number.  Given the need for SIP to interoperate
> with ANSI ISUP, there should be some consideration of implementing these semantics.
>  
> If SIP captured these fields, so as to provide a post-dip form of downstream signaling, and TRIP were designed to build route
> tables based on administratively assigned number ranges (which, by definition would make calls to routing numbers [LRN]
> routable) , and enum did not require DNS queries to be answered by donor networks, then the existing regulatory

First off, SIP has two fields that identify the destination party. The
To field represents the original number that the caller called, and the
request URI represents the address translated at each hop. Thus, the To
field carries the original dialed number, and the request URI would
carrying the routing number. Now, do we need to somehow indicate that
the LNP dip has been done? I'm still unsure about that. I believe
Henning had suggested that the use of a sip URL (as opposed to a tel
URL) in the request URI would effectively be an indicator of such. That
aside, I think there is a possible confusion if one were to assume an
LRN looked like a normal SIP URL:

INVITE sip:1212344 SIP/2.0
To: sip:14081234567

The problem is related to past discussions on the SIP mailing list
regarding overlap dialing. A terminating gateway would look at
sip:1212344, and know how to route it, but might not know whether this
was a dialed number with more digits coming, or an LRN. Does it matter?
Not being an ISUP expert, I'm not sure. If it does matter, something
like user=lrn within the SIP URL would fix that.

But anyway, thats also not a problem for iptel, although I've cc'd the
sip list on this message.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

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

---

From: "Hussein F. Salama" <[email-masked]>
Date: Thu, 09 Dec 1999 10:46:52 -0800

> switch, doing what we were doing all along works just fine.

Yes what we're doing is OK, because the LRN is part of an office's
NPA-NXX prefix. But we may have to add a new field to the
ReachableRoutes attribute to mark a prefix as portable. A prefix is
marked as portable if at lease one number has been ported out of this
prefix. 

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 09 Dec 1999 20:47:16 -0500

Btw, 
http://www.fcc.gov/Bureaus/Common_Carrier/Orders/1997/fcc97074pdf.html
has the gory details.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---------

---

From: "Mark D. Foster" <[email-masked]>
Date: Thu, 09 Dec 1999 17:36:40 -0500

> I'm not really sure that the N-1 concept works that well in an IP

Totally agree.  N-1 is relevant as an example of the need for flexibility on
where NPDB dips are done.  By varying trigger (dip) placement, one can
implement a wide range of call routing scenarios.  Again, key to trigger
flexibility is a positive query-done indicator so any downstream network
element will behave accordingly.

> avoids triangle routing, as has been discussed.

Source routing is the most efficient, but at the expense of having a global
DB mapping service available to originating networks.

N-1 was used in the US to allow local exchange providers to only worry about
hosting that local area's NPDB, because if the call is long-distance it's
expected to be dipped by the IXC.  Frankly, this is all that N-1 was all
about, was relieving the RBOCs of the need to host the entire US NPDB, given
that for regulatory reasons their wireline networks are still LATA-specific.

> that it is the N-1th server in the chain.

Even in the PSTN, a network has no way of knowing they are N-1 prior to
doing a dip.  However, as a heuristic, RBOC switches only load LNP triggers
to dip calls to number prefixes in the same LATA.  And, IXC switches are
expected to dip any non-dipped calls, hence the importance of a positive
query-done indicator.

There could be applications in the IP arena, for example a purely local ITSP
could opt to only dip calls in the NPDB via enum for the local area they
serve, and rely on a downstream transport network to dip everything else.

> switch, doing what we were doing all along works just fine.

Agree.  I think both TRIP's and SIP's role should be to provide the needed
flexibility to allow NPDB queries to occur wherever in the call path
business and regulatory decisions dictate.

> like user=lrn within the SIP URL would fix that.

I think it does matter, if for no other reason than to ensure complete
interoperation with ISUP, which could theoretically occur anywhere in the
call path.  For example, if a dip is done but the number is not ported, then
the query-done indicator is still set to suppress downstream triggers even
though the CdPN is left alone.   As long as there's a way to recover each of
the three LNP fields in SIP (query-done, dialed number, and routing number),
gateways should be able to do their thing (e.g. interoperate with ISUP,
TRIP, or NPDB).

> sip list on this message.

Yup.

-------------------------------------------------------------
Mark D. Foster                  | EMAIL: [email-masked]
CTO                             | NeuStar, Inc.
TEL: +1 202 533 2800/2702       | FAX: +1 202 533 2975
1120 Vermont Ave NW, Suite 550  | Washington, DC 20005

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Dec 1999 10:43:10 -0500

> marked as portable if at lease one number has been ported out of this

Hmm, why is that? Are you basically saying that if a prefix is marked as
portable, an LS must do an LNP query before routing to numbers in that
prefix? Then, if marked as not portable, there is no need for queries?
If so, its an interesting idea. It solves the problem of N-1, which,
from what I understand, was done in part because only carriers near the
destination would need to install triggers to perform queries on
numbers. However, if information on what prefixes are ported is
distributed in TRIP, this information is effectively dynamically
distributed. This means its equally easy for the query to be done at the
first LS as the last.

-Jonathan R.

---------