Subject: RE: TRIP

From: "John Mainwaring" <[email-masked]>
Date: Thu, 9 Dec 1999 17:02:09 -0500

|-----Original Message-----
|From: Jonathan Rosenberg [mailto:[email-masked]]
|
|Mark Foster wrote:
|> 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:

I thinks you're right, and what follows is that a concept that does work
will have to be found.

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

It isn't really the n-1 server that has to do the NP query, it's the n-1
network, typically an IEC for calls originating ouside a zone of
portability.  The IEC can do the query anywhere in their network that makes
sense.

A server doesn't know it is the n-1th server in any arbitrary chain.  At
most, it knows that it is aware of the portability status of some numbers
and not others.  You have to make sure that you don't try to route directly
to numbers whose portability status you do not know; you should route
through a transit server that does know, or query a database that will give
you the portability status.

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

I agree.  If you have done an NP query, you should use the LRN to query the
TRIP and the result should give you the right proxy.  The LRN is the
surrogate Directory Number for routing purposes.

However, the question of where the NP query can/should be done certainly
affects the overall architecture that TRIP has to fit into.  I think the
discussion below points in a workable direction.
 
|> 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.

user=lrn is almost right.  If you have queried a portable number and found
that it is not ported, then the DN has the same status as an LRN would have
if the number were ported (i.e. it should be treated as authoritative for
routing).  user=np-queried might be closer to the mark.

It's also necessary to define what the TRIP should do differently depending
on whether the np-queried indication is present.  I must admit I came into
this discussion mainly because I have worked on LNP.  I assume the objective
is not to route unqueried calls to the donor proxy.  I have noted that
originator query may not be practical for nationwide calling and that donor
proxy is too late unless you're prepared to consider RTP.  One answer might
be for the TRIP to provide a response on unqueried numbers that routes to an
intermediate server that does know how to do NP queries for the destination
DN.  No doubt there are other possibilities.  I'm curious to know which
forum would regard this problem as being in scope.

|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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Dec 1999 11:04:10 -0500

> John Mainwaring wrote:
> user=lrn is almost right.  If you have queried a portable number and
> found that it is not ported, then the DN has the same status as an LRN
> would have if the number were ported (i.e. it should be treated as
> authoritative for routing).  user=np-queried might be closer to the
> mark.

I wonder if we can't think about this problem in more general terms.

In the SIP model, each proxy owns some piece of the namespace
(engineering.dynamicsoft.com, for example), and is therefore responsible
for the definition of the user space (jdrosen@) within that domain.
Thats why each proxy can, an usually will, perform some kind of URI
translation independent from other proxies. Our underlying assumption
was that usernames only have meaning within their domain. For example,
with sip:[email-masked], only a dynamicsoft.com proxy knows how
to handle jdrosen. There might be jdrosen's in other domains that aren't
me. However, in the case of telephone numbers, the proxy that owns the
domain does not necessarily own the user space. sip:[email-masked],
for example, uses a user name that is not "owned" by gateway.com, in the
sense that this name has valid semantics outside of gateway.com. Other
domains, like wcom.com, would know how to handle this number as well.
Its possible that we might even see things besides phone numbers as user
names that are valid across multiple domains. An example is (heaven
forbid), social security numbers (in the US, at least):

sip:[email-masked];user=ssn

Now, I might imagine that some kind of mobility services might be
supplied for these names, so they might need to be translated also.

I'll call these type of user names "cross domain user names".

With cross domain user names, this is where we run into issues like "has
the number been queried yet". However, I think we might see other
translation mechanisms besides LNP. Soooo, might it not be useful to
define URI parameters that indicate what global translation services
have been applied to a cross domain user name?

As an example:

sip:[email-masked];user=phone;trans="lnp,gdbs"

where lnp and gdbs are some kind of global translation services that
apply to names of the type phone.

For cross domain user names, we will always need a URI parameter to
indicate the global namespace from which these names are drawn. In the
case of phone numbers, thats user=phone. Our original intent with the
user=phone parameter was to specify only the type of BNF used for the
user part of the URI. But, the more general operation of specifying both
the format and the namespace seems useful.

> 
> It's also necessary to define what the TRIP should do differently
> depending on whether the np-queried indication is present.  I must
> admit I came into this discussion mainly because I have worked on
> LNP.  I assume the objective is not to route unqueried calls to the
> donor proxy. 

Hmm. This is something thats also different from the PSTN. The cost of
routing to the donor proxy in SIP is much less, since proxies can be
stateless. Thus, if a proxy receives a call for some number that is
ported, it stateless proxies the call towards the next destination. The
result is that there is no triangle routing for media (there generally
isn't), nor for subsequent signaling. There is only marginal cost for
the donor provider. There are obviously polticial and business issues;
one may not want to trust or rely upon the donor proxy at all, as is the
case of LNP in the US. But, the general SIP model is that we assume
proxies do route calls; no security measures can prevent a proxy from
dropping messages. Why, in the case of LNP, do we now need to assume
these proxies won't route calls?

 I have noted that originator query may not be practical
> for nationwide calling and that donor proxy is too late unless you're
> prepared to consider RTP. 

The assumption of the impractability of originator queries has
everything to do with the existing structure of LNP. Its mainly because,
AFAIK, the systems are different all over the world. However, if we use
the IP model, with a DNS solution, its no harder to query for a number
on the other side of the planet as it would be for a number next door.

Also, pardon my ignorance, but what is RTP? Many of us on this list know
RTP as the Real Time Transport Protocol (rfc1889) but I don't think
thats what you mean.

 One answer might be for the TRIP to provide
> a response on unqueried numbers that routes to an intermediate server
> that does know how to do NP queries for the destination DN.

TRIP is not a query protocol. Its a routing protocol. This would be a
SIP function, and is already possible. "408 Not Found".

-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: Dean Willis <[email-masked]>
Date: Tue, 14 Dec 1999 13:55:48 -0600

> I wonder if we can't think about this problem in more general terms.

yes, please!

> forbid), social security numbers (in the US, at least):

The underlying problem here is differentiating between a phone-number and a
service-name-which-looks-like-a-number. Yes, the user=phone gives a hint on
nature od address, the "+" encodding gives a hint on the scope of address,
but it is still muddy.

There was some discussion of this problem wrt DCS during the November
interim meeting. It was suggested that a cross-domain destination which is a
phone number could be better represented by a tel: URL than by confusing the
scope of the user part of a sip: URL. This simplilifies life greatly.

Something like

	INVITE [email-masked]
	To: tel:5551212;trans=lnp?gdbs

could be used to indicate to gateway.carrier.com that premium gateway
service is requested towards the PSTN location identified by telephone
number 5551212, that LNP and GDBS translation have been applied, and that
the phone number is of local scope for the gateway. Incidentally, I think I
just noticed a minor anomaly in the tel-url grammar -- don't see how to
encode more than one future-extension field . . .

--
Dean

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 14 Dec 1999 16:24:06 -0600 (CST)

>the phone number is of local scope for the gateway.

Since the To: field isn't allowed to change during the transaction,
aren't you going to run into problems if some service along the way
determines that the called number needs to change (as the result of
LNP, 800/900 lookup, etc)?

For example; let's say that one of the services that I have out in the
network is a "reachable from anywhere" speed dialing list. It maps,
for example, "4" as a telephone number to "2145551212". So I launch
an invite to my local proxy:

  INVITE sip:[email-masked] SIP/2.0
  To: tel:4

It goes through my service node:

  INVITE sip:[email-masked] SIP/2.0
  To: tel:4

And he wants to send it on to your gateway for premium service, after
translating the 4 into "2145551212."

It's my interpretation that, under the model you're proposing,
I'd need to send along

  INVITE sip:[email-masked] SIP/2.0
  To: tel:2145551212

But that would break the transaction, since the To: field has changed.

I understand the distinction between destination and service
activation that you're trying to make, but your example seems
unworkable. What am I missing?

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Dec 1999 23:56:32 -0600

Adam wrote:
> Dean blurted

Right you are. That should teach me not to come up with examples while
squatting on one of those interminable telco conference calls.

But I still think using a tel: url gives a cleaner semantic than
sip:number@gateway;user=phone.

I was talking with some guys today about scope and context, and I'm inclined
to think we need the nature of address and numbering plan indicator fields
out of some ISUP variants. Scope appears to be global, local, or private,
with some need to represent local and private within some context like area
code or private numbering plan.

So, for example

tel:+19727294162 is a global number with unspecified context,
tel:9727294162 is a local number
tel:7724162;phone-context=mcivnet34 is a private number with context in the
MCI private numbering plan #34
tel:4512345687724162;phone-context=mciswtrunk is a private number, in
numbering plan 45, relative to switch 123 and trunk group 45678
. . . and whatever other sick private variants one might come up with

--
Dean

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 15 Dec 1999 09:29:14 -0600 (CST)

>. . . and whatever other sick private variants one might come up with

If we proceed with the idea of scoping numbers "like ISUP," could we 
align it with ISUP a little more closely? It would make interoperation
*much* easier.

ISUP defines four scopes; the list of them follows, along with
suggestions for representing them.

1) Subscriber number (significant within an area/city code)
   tel:5555555;phone-context=local

2) Unknown (usually a private numbering plan)
   tel:7724162;phone-context=mcivnet34
   or
   tel:4512345687724162;phone-context=mciswtrunk
   or
   tel:34251;phone-context=unknown
   or
   tel:23456;phone-context=private
   or
   ...

3) National number (sigificant within a country)
   tel:2145555555;phone-context=national

4) International number (globally significant)
   tel:12145555555;phone-context=global
   or
   tel:+12145555555

---

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

Jonathan Rosenberg wrote:

> ...snip...

As long as the "To" field is E.164 (local to E.164 translation presumed to
have occured before egressing the originating network) and is always
preserved, I think this could work.

> ...snip...

I don't think there's a need to change this assumption.  Actually, ensuring
the donor's proxy will re-route is critical, as they are considered the
default route for ported numbers.  Again, for regulatory and business
reasons we shouldn't force networks to ping the donor's proxy, lest it snack
of the deprecated (at least in the US & Canada) QoR/RTP approach.

> RTP as the Real Time Transport Protocol (rfc1889) but I don't think

I think RTP was meant to refer to "release to pivot", one of the LNP call
routing scenarios that requires the donor remain in the signaling loop, and
therefore disqualified by the FCC.

-------------------------------------------------------------
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: Dean Willis <[email-masked]>
Date: Wed, 15 Dec 1999 21:20:04 -0600

> >code or private numbering plan.
 . . .
>    tel:12145555555;phone-context=global

Adam, this initially sounds good to me, at least for accounting for "nature
of address". How would you account for "numbering plan indicator?"

--
dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Dec 1999 22:34:44 -0500

Dean Willis wrote:

> > forbid), social security numbers (in the US, at least):

In a few years, Microsoft will assign every human being a GUID :-)

> nature od address, the "+" encodding gives a hint on the scope of address,

A phone number in a SIP URL is indeed of local significance, within the
scope of the proxy or gateway. Thus,

INVITE [email-masked] SIP/2.0
To: tel:+12015554012

might be used when dialing a number that turns out to be a "tie line" or
voice VPN.

> encode more than one future-extension field . . .

Is somebody talking to the author of the tel: URL Internet Draft to make
sure this discussion doesn't get lost?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 16 Dec 1999 10:34:50 -0600 (CST)

>of address". How would you account for "numbering plan indicator?"

Very similar, I would assume. I have to admit I know very little about
X.121 or F.69 numbering plans, or even if there would be sufficient
demand for them. I beleive we'd need to fix the tel: url syntax to
allow multiple extensions to make this work; then, we could use
something like:

1) E.164
   tel:12145555555;phone-context=global
   or
   tel:12145555555;phone-context=global;numbering-plan=isdn

2) X.121
   tel:234987598;phone-context=global;numbering-plan=data

3) F.69
   tel:98724591;phone-context=global;numbering-plan=telex

Do you really think this is necessary, though?

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 16 Dec 1999 15:54:32 -0500

All,

Re: Tel URL grammar stuff like ...
>>         To: tel:5551212;trans=lnp?gdbs

I've been waiting for some discussion about the accuracy
of the time period in which the translation has been performed
to come up.

Virtually all of these telephony-centric LNP-type issues revolve
about databases which get updated on the order of once a day.

If LNP dips cost the service provider money (and external LNP
queries do) .... the service provider has a strong economic
incentive to cache the resolved numbers for use in subsequent
calls. [There is also a performance benefit for using cached data].

Shouldn't we provide a mechanism to at least give us a hint
that we are using potentially stale information (some mechanism
to deal with the soft-state issues from a variety of governmental
and/or service provider administered portability data bases).

Perhaps a tag that says when the "originally cached dip" was
performed to give a hint to a subsequent proxy how stale the
information may be. Any subsequent proxy could do what it
wished (i.e, do another database dip, if desired).

An evil service provider could forward an Invite with quite old
information instead of doing the remote dip itself .... but in the
case of frequently updated databases .... subsequent proxies
may have more accurate access to the current translation
(perhaps in it's cache, because it is more likely to service
more calls to this particular user).

This will surely kick off a discussion of how DNS solves this
issue vs. the GSTN ... but for the LNP issue ... we should
recognize the economic incentive for cashing information from
LNP databases that are updated relatively infrequently
AND that requirements for these updates are likely to change
in the future AND that it is highly likely that each database
administrator may have different policies regarding the frequency
and timing of database updates.

Does anyone know if such GSTN mobility/portability databases
are mandated (by ITU-T edict or defacto standard) to have a
globally understood update period (e.g., something like +x hours
from midnight GMT for a particular originating country code)?

Darn these legacy issues ... could we get the ITU-T to mandate
LNP/Mobility updates for ALL service providers to be accessed
through a DNS-like mechanism? I would doubt it, as it ruins the
present model of charging other service providers for such information.
The present charging model will die soon anyway ... perhaps we can
help accelerate the change?

Lastly, does anyone know if TIPHON has useful thoughts on
this issue?

I apologize in advance for the subsequent discussion thread,

Michael Ramalho

>sure this discussion doesn't get lost?

Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578

---

From: "Albert Manfredi" <[email-masked]>
Date: Thu, 16 Dec 1999 16:24:21 -0500

On update time periods, my reading is that the DNS and the NPDB
(number portability database) have update periods on the order of
several hours. Maybe 8 hours or more. And that mobility databases
are updated in minute(s). Which is another indication that the DNS
could fill the role of the NPDB, if it comes to that, or certainly
that the DNS could provide that role for IP users wanting to access
portable telephone numbers.

I've seen studies that address the rapid synchronization of huge
database systems (D. Lam, Y. Cui, D. Cox, J. Widom, "A Location
Management Technique to Support Lifelong Numbering in Personal
Communications Services," Proceedings of 1997 IEEE Global
Telecommunications Conference, Volume 3, pp. 704-710, 1997), and I
suppose ultimately the DNS could migrate to that sort of structure.
But for now, the speed required for mobility updates is handled by
keeping those tables in very few servers (distributed according to
service provider).

Bert
[email-masked]

Michael A. Ramalho wrote:

> Incidentally, I think I
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/enum
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 01:10:24 -0500

> of address". How would you account for "numbering plan indicator?"

One thing at a time. We have several issues here, and I think they are
orthogonal:

1. When does one use a tel URL, and when does one use a SIP URL with a
user=phone?

2. How does one convey the numbering plan a number goes by? Does one
need to indicate this in the URL?

3. How does one indicate the context the number is valid in? Does one
need to indicate this in the URL?

4. How does one indicate what translations have been applied to the
number?

I want to focus on (1) first. My thinking in my previous post was that
one uses a tel URL when one doesn't care what gateway provider handles
the number, and the SIP URL when there is a gateway provider being used.
I think Dean's and Hennings idea is that one uses a tel URL when a
number has a scope that is beyond a single domain. Use a SIP URL when
the number has scope only within a domain, and that domain in a domain
name or host name.

This definition blends somewhat with the notion of contexts. So, if a
phone context were for wcom.com, one could use:

tel:5551212;phone-context=wcom.com

or

sip:[email-masked];user=phone

in this case, its not at all clear to me which one is better than
another. 

Regarding (2) and (3), its not clear to me at all how a proxy would
behave differently based upon knowing the context and/or numbering plan.
If the proxy has longest prefix match routing tables, isn't that
sufficient to correctly route numbers without knowing specific numbering
plans? I really don't want to have to program my proxy with all these
different numbering plans.

So, before we start running away with all this stuff, we need to answer:
what problems are they solving?

-Jonathan R.

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 17 Dec 1999 14:58:09 -0600 (CST)

>in this case, its not at all clear to me which one is better than

I'd say the tel: version, since the *context* won't always be
unique to a domain. For example, the number tel:5551212;phone-context=local
would be useful to all of the service providers in my area code --
not just wcom.com.

>plans?

Not by a long shot. For example, you could provision your network
so that you generally set up your number analysis for national routing;
e.g. most of your numbers would come in in the form
"tel:9725830000;phone-context=national". However, if one
of your proxies is receiveing an international call, it would
get a URI like "tel:+19725830000". Since your number analysis
is based on the national variation of this, you'll need to strip
off the "+1" before analysing the number.

In general, the contexts will be prefix based, so you'll be able
to do some simple string manipulation instead of maintaining
parallel number analysis trees.

The same argument holds in the reverse direction (e.g. if you do your
routing based on international numbers, you'll need to add a "+1"
to any incoming URI tagged national context).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 17:13:09 -0500

"Adam B. Roach" wrote:

> off the "+1" before analysing the number.

I see. I had forgotten the case of a proxy receiving requests from
multiple different dial/number plans.

I'm honestly queasy about this. One of things IP did right was to make
its addresses and domain names always well defined independent of where
you are located. With IP addresses, we never send just the last byte,
assuming that the router fills in the rest. In SIP, we did the same. We
pass around URLs, which are interpretable independent of the context.

I understand that people like to stick with the traditional models, but
I see a slippery slope here of problems that will arise with the
possibility of locally defined numbers placed in all these different
fields. Rick has pointed out a very serious one with BYE/Also. I note
that redirect responses have a similar problem when record-routing is
not used. Furthermore, forcing record routes for everything, and having
proxies rewrite Contact, To, Also and From headers will break end to end
authentication, which is very bad. 

I fully agree that users should not need to know about dial and number
plans. I also agree that users should be able to dial extensions and
local numbers as they do today in a PBX. I'd like to understand the
costs involved in having internationalization of numbers done within the
UA. Obtaining a dial plan automatically through a REGISTER response
would still allow an administrator to control it, and to modify it
(registrations get refreshed, so you can send updated versions in the
responses of refreshes). So, my questions are: how complex can a dial
plan be? How many entries in a dial plan table are there usually? How
much processing power does it take to compare a number against a dial
plan and internationalize it?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 21:08:10 -0500

> wished (i.e, do another database dip, if desired).

This merely seems to be passing the buck. If there are issues with data
staleness,
ought we not solve them at the database (i.e., DNS) level, rather than
within SIP?

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Sat, 18 Dec 1999 14:20:22 -0600

> what problems are they solving?

That depends on what you mean by a numbering plan. A lot of carrier business
is around supporting private numbering plans, which we call "VNETs". Some
people call them VPNs or VPDNs, which results in no end of confusion. In any
case, it is producing no end of confusion on how to manage this inside a
gateway's configuration without requiring dialing-plan knowledge in the
gateway.

A given local (or private, using ISUP NOA semantics) number like 7724162 is
unresolvable by a proxy without more information -- namely, which numbering
(VNET) plan is being referred to.

Note that I think the NOA from ISUP is insufficient -- "unknown" is not the
same as "private", because there can be many different "private" contexts.

If a UA has a fixed context, a routing proxy could simply look the UA up in
a table in order to find the default VNET for the UA. We could add a
gateway-specific VNET code which indicates the default VNET of the gateway.
We could add an originating trunk-specific field to allow for multiple
trunks, each of which is potentially associated with a different VNET.

There are some questions about when the UA should supply the context
variable. Our first though has been that the UA (actually, a gateway) should
ALWAYS append the unkown phone-context, and we'd figure out whether the call
really was global, local, or private through number analysis in the proxy.
So, if a proxy knows a particular gateway is US-based, has a 7-digit private
numbering plan, and receives leading 9s for public calls and leading 8s for
private calls, then number analysis could determine that:
	<tel:99727724162;phone-context=unknown;vnet=00000026>
		Is a call to "+19727724162",
		Rewritten as <tel:+19727724162> or
		  <tel:19727724162;phone-context=global>
	<tel:97724162;phone-context=unknown;vnet=00000026>
		Is a call to local public number 772-4162 in the default area code.
		Rewritten as <tel:9727724162> or
	        <tel:9727724162;phone-context=local>
	<tel:87724162;phone-context=unknown;vnet=00000026>
		Is a call to number 7724162 in the private numbering plan "00000026".
		Rewritten as <tel:7724162;phone-context=private;vnet=00000026>
		Where the presence of a "private" context indicates that vnet translation
has occurred.

This works just dandy as long as a gateway is associated with a single VNET,
or as long as individual PSTN ports on the gateway (associated with trunks
into that gateway) are associated with a single VNET. Of course, it isn't
all that semantically clear, as the input digits are considered "private"
context until treated by the proxy.

But when a trunk into a gateway becomes "shared" and has multiple associated
VNETs, things get weird. This of course would be the case for very large
"central office" gateway complexes. This was solved in the switch world by
adding some extra stuff into a proprietary ISUP. I'd rather not have to
promulgate propietary SUP into SIP gateways, as it adds a certain element of
expense and complexity.

The question is -- how does a gateway which accepts multiple VNETs into the
same port figure out which VNET applies, or how does it include enough
information to allow

One proposal has been to overload the phone number by prepending (at the
originating switch) a 2 digit class code (usually 45) and another 8 digits
of VNET info to the dialed digits.  This of course assumes a
non-shared-trunk into the originating switch, which is apparently
reasonable. This extra data bebops along in the called-number field of ISUP
until it hits the gateway, whereon it is copied into the request-URI and
sent to a proxy which routes the call. One inverts the approach if needed
for an egress gateway.

So, in the case of GSTN into a shared gateway, the cases might look like:
	Call to +19727724162
	  ISUP digits 9727724162, noa=public, npi=e.164 produces request
	  <tel:9727294162;phone-context=public>
	  which can be routed without rewrite
	Call to 7724162 in vnet 26
	  ISUP digits 45000000267724162, noa=private, npi=e.164
	  <tel:7724162;phone-context=private,vnet=00000026>
	  which might be rewritten by the proxy to
	  <tel:7724162;phone-context=private;vnet=00000026>

The resulting approach then would be:

On GSTN->IP, a switch-facing shared ISUP gateway constructs the request URI
by:
1) Start with the string "tel:"
2) If the NOA is private then:
     copy from the 11th digit through the last digit into the request-URI
   else
     Append all destination digits into the request URI.
3) Append the string ";phone-context"
4) Append a string of "public" or "private" to the request based on the NOA
indicator.
5) If the NOA is "private", append the string ";vnet=" followed by 3rd thru
10th digits

On IP->GSTN, a switch-facing shared ISUP gateway constructs the dialed
number by
1) If the phone context is "private" and there is a vnet field,
   append the configured class code, like "45" to dialed-num
   copy all digits from the vnet=parameter to dialed-num
2) copy all digits between "tel: and (EOL or ";") into the dialed number
field
2) is there is no phone-context, set the NOA to public
3) if there is a phone-context, set the NOA accordingly

On GSTN->IP, a non-shared-trunk non-isup gateway constructs the request URI
by:
1) Start with the string "tel:"
2) Append the dialed digits
3) Append "user=phone;phone-context=unknown;trunk="
5) Append the configured gateway, trunk or port name or number string.

On IP->GSTN, a non-shared-trunk non-isup gateway constructs the dialed
number by:
1) Copy the digits from request-URI after "tel:" up until the first ";", if
any
2) if the is a "trunk=" parameter and the gateway supports named trunks,
       outpulse on the matching trunk
   else
	 outpulse on any tunk

You know, this is starting to get tedious. The phone network really makes my
head hurt.

--
Dean

---

From: "Mark D. Foster" <[email-masked]>
Date: Mon, 20 Dec 1999 01:11:49 -0500

> > about databases which get updated on the order of once a day.

This may be true in some countries today, but not in those with IN-based
LNP.  In the US and Canada, updates to the LNP database are broadcast in
real-time to service provider systems, with contractually mandated broadcast
and transaction response times (e.g. 3 seconds max) for example.  Part of
the reason for this type of quick turnaround is that stale LNP data can
cause looping of SS7 messages, and therefore de-stablize carrier's signaling
backbones, to say nothing of customer's not having any inbound telephony
service until database updates are propagated and calls properly routed.
Neither of these factors will change with iptel.  For example, the LNP
database will be needed to route SS7 TCAP messages using telephone
number-based GTTs, regardless of whether the lower layers are MTP or
M3UA+RTSP+IP.

> > calls. [There is also a performance benefit for using cached data].

Caching is not an effective answer, because unlike domain name lookups, the
lookup frequency of geographic numbers by value is uniformly flat and
uncorrelated, and the TTLs must be set to relatively short intervals to keep
looping probabilities managably low.

Consequently, telcos today either host a copy of the entire database
associated with their service area (by subscribing to the NPAC database
update feeds), or buy query transactions from someone else who does.

> ought we not solve them at the database (i.e., DNS) level, rather than

I agree with Jonathan here.  Fortunately, there is no staleness problem with
the databases today, nor do we have to introduce one where it doesn't exist.
Avoiding stale data is also consistent with the FCC requirement of not
relying on the donor network for call-related (in this case, database query)
processing.  Service providers must be free to choose who will host the
database their resolvers will consult.

R, Mark

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 20 Dec 1999 14:05:40 -0500

> number-based GTTs, regardless of whether the lower layers

Maybe then this LNP database is comparable to IP routing tables
distributed throughout routers. At least, functionally, since it is
required for routing of telephone calls. (By the way, I didn't know
that the LNP database entries are broadcast. Interesting. This
compares with the propagation of info in schemes like OSPF or RIP,
which is asynchronous, and only between neighbors.)

> looping probabilities managably low.

Just as long-term caching of routing tables is not effective in the
Internet. I don't think this is comparable to the DNS, though,
because the DNS does not have information that is used in routing.
The DNS does not need to respond, for example, to any temporary
breaks in the infrastructure. The DNS is more like a telephone
_directory_.

> Fortunately, there is no
> staleness problem with

The staleness issue is not an issue in what I thought we were
discussing, unless I missed something.

The DNS used in the role of number portability database or in the
role of IP-to-E.164 number translation database is not used in a
time-critical role at all, as far as I can see. For real-time
routing roles, such as tracking of _mobile_ stations or the
maintaining of routing tables, I think everyone agrees that the DNS
is not the correct solution.

Bert