Subject: Re: [dispatch] Thoughts on SIP routing, TRIP, and ENUM (Long!)

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Apr 2010 13:30:21 -0600

There probably any number of reasons that TRIP and others were never deployed but I think one of the largest reasons is the questions about authorization of identities. There are any number of protocols where organization A can tell organization B that calls to phone number X should be routed to server Y. Some examples are TRIP, DUNI, flavors of ENUM, VIPR, and so on. The issue is you need a reason that B should trust what A told them.

Without a good answer that question, it's hard to see how one would use the resulting solution. 

Cullen <as an individual contributor> 

On Mar 5, 2010, at 1:04 PM, Dean Willis wrote:

> 
> Fundamental routing problem:
> 
> The fundamental SIP routing problem is this: I've been given a message that is addressed either to a telephone number or to a user@domain name. Where do I send this SIP request to next?
> 
> For "really stupid nodes", the question is easily answered: if the destination isn't "me", I send the request to my default proxy and let it deal with the problem. The default proxy might route the message itself, or it might send back a 302 informing the me as to where to send the request. It is important to note that in general, this "next hop" decision represents a singular hop. We have no way to 302-respond with a vector that specifies a sequence of relays to be used.
> 
> For a smarter host on "the open Internet", the answer is also easy. If the target identifier is a "user@domain" URI, then I look up the domain part in DNS and send the request there.  If the target identifier is a phone number, I use ENUM to look up an associated SIP URI, and I send the request to that URI. Local routing tables that have much the same effect may also be used, but are not specified in the governing RFCs.
> 
> But the "real world" (at least as we have allowed it to become perverted) doesn't work that way. In this unhappy place, we don't have direct end-to-end SIP routability. Instead, for many reasons good, bad, and mostly practical, we must transit a set of relay nodes to get from point A to B.  Further complicating matters, we may not even know what the whole set of nodes are, as various portions of the vector may be "topology hidden."
> 
> So in practice, a "really stupid node" like a phone-gateway or PBX sends its request to a routing proxy, which then uses a combination of ENUM, DNS, and local policy to select a next-hop relay. Note that this decision-making process tends to repeat at each relay node, since 1) we don't have away to represent a multi-hop vector in a 302 response, and 2) each node has limited view of the end-to-end visibility, in part due to topology hiding. There's no good exchange mechanism for this information, and no standard way to inform SIP nodes about how to use it. We've seen proposals for source-context-sensitive private ENUM solutions, mutagenic SIP proxy servers that return 302s, various web-service approaches, and others.
> 
> 
> 
> TRIP: A solution?
> 
> TRIP proposes one model, wherein the "smart" nodes (called LS, or Location Servers) exchange reachability information with each other using a variant of BGP. This provides us a rich fabric for advertising routes, control peering policy, deciding what parts of stuff to "topology hide", and so on. Where BGP uses IP addresses (or the prefixes thereof) as routing targets, TRIP uses telephone numbers (or the prefixes thereof). Like BGP, it allows for "internal" routing using a flood model, and "external" routing using more controlled policy.
> 
> In shortest essence, TRIP allows a first LS to say to an external LS  "For the following phone numbers and phone number ranges, I suggest you use this other node or set of nodes (by IP or DNS name) as your next hop(s). And  I heard this from node X, who heard it from node Y, who heard it from node Z."  It allows allows a first LS to say to its internal peer "Here are all the routes I know; feel free to use them and please tell me about any you know that I don't."
> 
> But TRIP has not caught on. I've heard mixed answers, which boil down to 1) its aggregation model for routes is broken, meaning Too Many Routes (as a product of LNP which makes phone numbers messy), 2) it's too complicated, and 3) Cisco owns the IPR, and I'm not sure they want to share. I'm not sure I believe this is all there is to it.
> 
> The REAL problem with TRIP may be its fundamental routing model. It assumes that the routing of a phone number is a property of a given phone number (or aggregation range), and doesn't capitalize on the actual peering relationships. Further, it doesn't really allows us to talk about "routes to domains". just "routes to phone numbers", so it doesn't help with a call to "sip:[email-masked]" at all. And as we know,  given the peering models, RFC 3263 is also inadequate for "sip@[email-masked]". We can't go from here to there using "example.com"'s SIP SRV record. Instead, we need to find the right peering partner who can get us there, and we don't have a good way to do that.
> 
> 
> 
> Another model: Inter-ITAD routing:
> 
> If we assume that each SIP Service Provider (SSP)  is essentially the same thing as an ITAD (Internet Telephony Administrative Domain), and that ITADs peer with each other along well-defined channels (using Session Border Elements, SBEs, known by other acronyms including Little Spawns of Satan etc.), then this gives us another routing topology to consider.
> 
> Assume a routing protocol that tells ITAD A that to reach ITAD Z, the request should be sent to ITAD Q (or perhaps to a vector of Q and T) who will act as an intermediary. If ITAD A can directly reach Q, then A knows how to route the request. A can send the request to A's SBE that is adjacent to Q, which then hands it to Q's SBE (adjacent to A), which then consults its own routing tables to figure out how to move the request on, either to Z, to the previously declared secondary route T, or to some other ITAD known to Q that will serve as a relay.
> 
> With this model, we don't need to know the route for a given E.164 number (or @domain part). All we need to know is which ITAD that target is associated with. We then consult the ITAD routing table to send the request. This means that the largest dynamic routing table required is the inter-ITAD map, which is exponentially smaller than the number of telephone routes.
> 
> So, given a dynamic inter/intra ITAD routing protocol that can tell us what SBE to use to move towards a given ITAD, all we need to know is a way to translate a phone number or a domain-part into an ITAD.
> 
> This is the easy part. ENUM gives us an excellent mechanism for turning phone numbers into either numeric or domain-style ITAD identifiers. The mapping of phone number (or phone number range) to ITAD is relatively static, globally valid, and well-suited to the recursive-lookup and cache model that ENUM inherited from DNS.
> 
> This gives us a new simple model for call routing at the LS for phone-number targeted calls
> 
> 1) If the number isn't locally known, look up its ITAD in ENUM. This might be range-matched or fully qualified; it's just a standard ENUM lookup.
> 2) Consult the ITAD routing table to select an SBE (and possibly additional transit ITADs) to find the routing vector consisting of one or more SBEs and zero or more transit ITADs.
> 3) Canonicalize the request URI and add the SBEs/ITADs as loose route hops
> 4) Send the request.
> 
> For domain-targeted calls, we might also get to add in "Check to see if the destination is reachable via RFC 3263, and if so, use that" somewhere in the process.
> 
> The short form of this model is 1) Find the ITAD of the destination. 2) Find a route to that ITAD (which might be one or more intermediaries. 3) Send the request there.
> 
> 
> 
> Conclusion:
> 
> So, other than a dynamic routing protocol that meets inter/intra-ITAD routing requirements and could be derived from TRIP (or built using some other model, such as a SIP event package), what are we missing?
> 
> 
> --
> Dean
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 30 Apr 2010 16:22:13 -0500

> Without a good answer that question, it's hard to see how one would use the resulting solution. 

And as I experienced years ago when using DUNDi, the solution needs to
allow for the entire chain of trust that resulted in A sending the call
to B to be able to recorded somewhere along with the call records, in
case there were quality/routing/etc. problems associated with the call.
Most systems are really not prepared to handle truly dynamic call
routing, and have no means in place for administrators to be able to
troubleshoot problems post-mortem.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org