Subject: [iptel] draft-walker-iptel-trip-tns-00.txt

From: James Yu <[email-masked]>
Date: Fri, 3 Nov 2000 13:29:53 -0600

Dave,

In your draft, you proposed to add an attribute to the existing "routing
number (I assume that it is what we agreed through previous discussions)"
address family instead of a new address family in TRIP for the "transit
network selection."  Your reason was that this "transit network selection"
must be associated with the E.164 number because the receiving carrier may
not be able to terminate the call to an E.164 number (e.g., only handle IP
devices). 

IMHO we need a new address family in TRIP for the "transit network
selection" because it contains distinctive routing information.  If a call
is to be routed to a particular carrier (identified by the "transit network
selection") to handle a call to a called party address, which can be an
E.164 number or something else  (e.g., called party's E.164 number or sip
URL), the call should be passed to that carrier regardless of the callled
party's address type.  How that carrier uses the called party's address is
that carrier's business.  For example, even if that carrier does not
terminate the E.164 number directly, it can route the call to the PSTN or
perform an ENUM query to retrieve URLs and others for that E.164 number.
Therefore, if a switch has the "transit network selection," it should route
the call using it regardless of the called party's address or routing
number.  So the suggestion is to use a new address family for "transit
network selection."   We'll have a distinctive address family that make the
TRIP information exchange much easier and the TRIP routing simpler and
straightforward.

In draft-yu-tel-url-np-00, I proposed two extensions to the "tel" URL to
support number portability, "rn" and "npdi".  "rn" carries the routing
number, and "npdi" is to indicate whether number portability database dip
has been performed.  I'm revising that I-D to support 800 service.  One new
parameter for 800 support is the "cic" or Carrier Identification Code that
identifies the carrier and is equivalent to the "transit network selection"
(at least in the U.S.).   That same parameter can be used to carry the
"transit network selection" if it needs to be carried in the SIP message.
The "cic" or "transit network selection"  can be received in the incoming
ISUP or SIP message or resulted from a service trigger such as 800 number
translation.

I have an example where a tel or SIP URL contains the telephone number,
routing number (e.g., rn) and cic.  The example is

  tel:+1-202-533-1234;rn=+1-202-544-0000;cic=+1-5678     or
  sip:+1-202-533-1234;rn=+1-202-544-0000;cic=[email-masked]

Although the example represents a rare case, it is used to show how call
routing can be done when the three numbers/addresses are all present. The
procedure would be: 

- When all three numbers/addresses are present, "cic" is used first until
the signaling message reaches the carrier identified by the "cic" and that
carrier needs to remove the cic.  

- If only "rn" and telephone number are present, "rn" is used.  

- If only the telephone number is available, it is used as the "routing
number" to route (check against the TRIP "routing number" address family
table).  Hopefully, somewhere down the road, a switch/server will perform a
NP dip to get the "rn" in the NP environment.
  
The first step requires a new address family for the "transit network
selection" or "carrier ID code."  The second and third steps uses the
existing "routing number" address family.

For "cic" to appear in a sip URL that does not contain a telephone number
(e.g., sip:[email-masked]), a new parameter may need to be added.

James Yu
Principal Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue, NW,
Suite 550
Washington, D.C. 20005
USA
+1-202-533-2814 (B)
+1-202-533-2976 (Fax)
[email-masked]
http://www.neustar.com

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