Subject: [IPTEL] Re: TRIP

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:25 +0530

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

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

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel