Subject: RE: TRIP

From: James Yu <[email-masked]>
Date: Tue, 14 Dec 1999 10:58:31 -0600

For overlap signaling, a GW or LS that receives a call with partial address
information may not know that the address info. is complete.  If it launches
a query (DNS or NPDB), the entity that has the "number portability" info.
won't be able to find the info. because the address info. is incomplete.  It
seems that either this LS or GW may wait a little while to see whether there
are subsequent address info. before launching the query, or it can launch a
query (DNS or NPDB-like), receives an error (hope that it is specific such
as incomplete address instead of something ambiguous), and then wait for
additional address info. before timing out.

James
-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, December 14, 1999 11:04 AM
To: John Mainwaring
Cc: Mark D. Foster; [email-masked]; 'James Yu';
[email-masked]
Subject: Re: TRIP

> John Mainwaring wrote:
> 
> |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.

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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Dec 1999 16:33:17 -0500

> additional address info. before timing out.

I think Dean had sent out some pseudo-code some time back on how trip
and enum and overlap interact, and this was more or less what the code
suggested. I believe he thought it was a bad thing, and so do I.

Overlap dialing seems fundamentally in conflict with LNP or enum queries
at the local outbound proxy.

To do LNP, the local outbound proxy needs to have the entire string of
digits before it can perform the query. But, overlap seems to imply that
it won't ever know the entire string of digits, as it doesn't have
knowledge of those numbering plans. It just forwards the request to some
other proxy or gateway that does.

Sooo, it would seem that a proxy should only use enum or LNP for numbers
it knows to be complete. This means that for overlap dialing, the LNP
query will happen close to the destination (possibly even in the PSTN),
not unlike the N-1 case we've been discussing. However, for en-bloc, it
can happen anywhere. This does seem to imply that a proxy needs to know
whether the number in the request URI of an incoming request is en-bloc
or overlap. It could make this determination if it knew the structure of
the numbering plans, but thats unlikely. Might we need a parameter
somewhere (ugh)? I really hate to crowd SIP with things to support old
legacy technologies like overlap, so if we can avoid this, I'd be very
happy.

-Jonathan R.

---------