On 09.03.2010 18:27, Dean Willis wrote on the IETF dispatch list:
I definitely see the need for defining a method by which to inform nodes inside an ITAD of egress routes from that ITAD to other domains. I think that most of the people who have responded on this thread agree that there is such a need.
Yes, there is.
Where we have a disagreement is on mechanism. While your proposed use of ITAD-specific private ENUM servers is not completely inconsistent with recent trends in ENUM, I have to say we’ve done a lot of things in ENUM that I don’t like, and this is pushing the envelope further in that direction.
As I see the problem space, we’re conflating two independent problems:
a) how is routing-information exchanged between SSPs?
Here we have one approach which favors registries which digest routing-information and spit out suitable database dumps for provisioning the SSPs boxes. The other approach is to get some real routing-protocol up and running between SSPs (like BGP4 for IP layer 3 routing).
b) how is this routing-information conferred to the proxies/SBCs/… which do the actual SIP message processing / forwarding?
Now, if these proxies are actually participating in a dynamic routing protocol (or receive full dumps from a routing registry), then b) is internal to the proxy. Just as there is no protocol for moving routes from the BGP table of a router to the actual packet forwarding engine, this is purely internal to the box.
If, on the other hand, some entity distinct from the actual SIP devices handles the routing information (either by talking to a registry, or by running a dynamic routing protocol), then the SIP device needs a protocol to query that routing-oracle on what to do with a given call.
It seems to me that this is what ENUM is increasingly used for within SSPs.
IMHO this is the wrong protocol choice for this task.
Why?
* ENUM is a very simple DNS application. The only key to the lookup is the destination number, the only return value is an URL. (more or less)
* If you look at a good number of recent drafts you notice that people feel that this is not enough: they need “ID of the SIP device” or “caller-ID” in the query, and a sh*tload of URI-parameters (trunk-id, …) in the answer. See draft-mayrhofer-drinks-sed-elements for further data that might need to get stuffed into an ENUM response.
ENUM was never intended as call-control protocol where a proxy outsources its complete routing intelligence to an external party. It’s a simple key->URI directory lookup. The LRF (RFC 3263) and the intelligence was supposed to be within the SIP proxy.
Now, what we need here is something closer to RADIUS than to ENUM: a protocol where the SIP device can pack up all the information it has about the SIP INVITE into one request to the routing-oracle which then answers with a details set of parameters (the SED) on what the stupid proxy is
supposed to do now.
Trying to expand ENUM into doing just that is bound to fail.
