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

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

---

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: Dean Willis <[email-masked]>
Date: Tue, 14 Dec 1999 23:56:32 -0600

Adam wrote:
> Dean blurted
> >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)?

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: Tue, 14 Dec 1999 16:24:06 -0600 (CST)

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

---------