On 09.03.2010 18:27, Dean Willis wrote on the IETF dispatch list:<\/p>\n
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.\n<\/p><\/blockquote>\n
Yes, there is.<\/p>\n
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.\n<\/p><\/blockquote>\n
As I see the problem space, we’re conflating two independent problems:<\/p>\n
a) how is routing-information exchanged between SSPs?<\/p>\n
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).<\/p>\n
b) how is this routing-information conferred to the proxies\/SBCs\/… which do the actual SIP message processing \/ forwarding?<\/p>\n
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.<\/p>\n
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.<\/p>\n
It seems to me that this is what ENUM is increasingly used for within SSPs.<\/p>\n
IMHO this is the wrong protocol choice for this task.<\/p>\n
Why?<\/p>\n
* 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)<\/p>\n
* 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.<\/p>\n
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.<\/p>\n
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
\nsupposed to do now.<\/p>\nTrying to expand ENUM into doing just that is bound to fail.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-194","post","type-post","status-publish","format-standard","hentry","category-ietf"],"_links":{"self":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/194","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/comments?post=194"}],"version-history":[{"count":1,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/194\/revisions"}],"predecessor-version":[{"id":940,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/194\/revisions\/940"}],"wp:attachment":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/media?parent=194"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/categories?post=194"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/tags?post=194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}