Subject: Re: TRIP

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
> requirements for LNP could be met.

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

---

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