Subject: [SIP] RE: TRIP

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

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

I think the problem is a bit different.  919-555-1212 uniquely identifies a
user within the North American Numbering Plan.  It's just that with LNP it
can no longer locate the user.  If someone wants to use
[email-masked] as an email address and someone else uses
[email-masked], that's fine, but has nothing to do with
telephone numbers.  I think I want to be able to place a call when all I
know is 919-555-1212.

Without LNP, it would have been fairly easy to  discover that 919-555
implied bellsouth, so the number could have been given as
[email-masked].  Now it is possible that some numbers from
919-555 might be ported to othertel.com.  Othertel might the native owner
of
919-444-xxxx numbers and might choose to host 919-555-1313 on their 919-444
exchange.  In that case, the LRN for 919-555-1313 would be 919-444.  Once I
have done an LNP query, I might want to use something like
[email-masked] for a number that has not been ported
and
[email-masked] for a number that has been ported to
othertel.

I can't shorten the 10 digit number in the user name, because of things
like
NPA overlays and switches that host multiple office codes.  I need the full
address to select the right user as well as the LRN to route to the right
place.

If a SIP user wants to call someone who uses a PSTN phone, the system needs
to deal with certain inconvenient aspects of the PSTN. A notation like
919-555-1212@919-555 or 919-555-1313@919-444 might be useful to indicate
that an LNP query has been done, and that authoritative routing information
is now available.  Appending text-based names such as
919-555-1212@[email-masked] or 919-555-1313@[email-masked]
might
even allow subsequent routing to take place without further concessions to
PSTN quirkiness.

Of course this system could also be expanded to mobility services; routing
for 919-555-1313 could be set to [email-masked] in
the
daytime and [email-masked] in the evening if you went in
for that kind of commuting.

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

No, it's not quite as simple as that.  The system is designed around the
strengths and weaknesses of the PSTN.  The the architecture of the pstn
makes it easy to route calls on partial information, but switches in the
pstn perform better if they do as few database queries as possible.
Switches work fine if they have no idea of the portability status of most
numbers; they are only set up to query nearby numbers.  A switch doesn't
need authoritative data that a number is not portable.  It just needs to be
set up to query that (local) subset of portable numbers which it would
misroute if it didn't query them.

The LNP databases are distributed because of the geographic restrictions on
Bell Operating Companies.  Each RBOC only has to worry about its own data,
and only has to route queries within its own SS7 signalling network.

There are actually two levels of database, the SCPs that actually handle
queries and the NPAC (?) which processes administrative change requests and
downloads the SCPs.  There could be several SCPs owned by different
operating companies that contain the same data; each operating company
would
route queries to its own SCP.  The NPAC service is provided by NeuStar,
formerly Lockheed Martin, and Mark Foster of Neustar has given us some
excellent information on LNP within this thread.

It seems unlikely that IP telephony would use the existing SCPs for
queries,
or that it would be based on SS7 TCAP messaging.  I don't have a clear idea
of what databases there would be for IP telephony, but they would certainly
have to arrange to download data from the NPAC.  There are costs associated
with the databases and with keeping the LNP information up to date.

If you want to do source routing, it will certainly take a non-trivial
effort to make North American or even world wide LNP information
accessible.
There would be a case for aggregating it with whatever centralized routing
servers there are, or for arranging for the destination's proxy to return
information about ported numbers instead of simply refusing the invitation.

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

In that context, RTP = Release To Pivot; switch A routes a call to switch B
which may provide some service and then releases the call back to A (the
pivot switch) with instructions to reroute the call to destination C.
Sorry, I thought I had expanded it earlier.

Is there any TLA in our businsess that only has one expansion?  What does
TLA mean apart from Three Letter Acronym?

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

But why was it not found?  In the telephony e.164 numbering domain prior to
LNP, "not found" meant "does not exist".  LNP required switches to add
"might be somewhere else" logic.  It would be desirable for a routing agent
to say something more informative than "not found", if  it had any
additional information.