{"id":220,"date":"2008-05-03T07:31:56","date_gmt":"2008-05-03T06:31:56","guid":{"rendered":"http:\/\/lendl.priv.at\/blog\/2008\/05\/03\/new-i-d-on-enum-for-loose-route-sip\/"},"modified":"2026-01-26T12:16:55","modified_gmt":"2026-01-26T11:16:55","slug":"new-i-d-on-enum-for-loose-route-sip","status":"publish","type":"post","link":"https:\/\/lendl.priv.at\/blog\/2008\/05\/03\/new-i-d-on-enum-for-loose-route-sip\/","title":{"rendered":"New I-D on ENUM for loose-route SIP"},"content":{"rendered":"<p>I&#8217;ve submitted a new <a href=\"http:\/\/www.ietf.org\/internet-drafts\/draft-lendl-enum-sip-lr-00.txt\">I-D<\/a> defining an enumservices subtype for loose-route SIP according to J. Rosenberg&#8217;s <a href=\"http:\/\/tools.ietf.org\/id\/draft-rosenberg-sip-ua-loose-route-02.txt\">UA loose route<\/a> (which right now is one of multiple proposals to address one problem).<\/p>\n<p>The basic idea is the following: SIP proxy should distinguish between &#8220;retargeting&#8221; and &#8220;routing&#8221;. <\/p>\n<ul>\n<li><strong>&#8220;retargeting&#8221;<\/strong> is done, whenever a proxy decides that this call should be directed towards a new destination. Consequently, the Request-URI changes.\n<\/li>\n<li><strong>&#8220;routing&#8221;<\/strong> happens, when a proxy forwards the SIP message to the next hop, but does not change the identification of the target. <\/li>\n<\/ul>\n<p>In the context of ENUM, the destination of the call is identified by a E.164 phone number (whether that number is encoded in the user-part of a sip: URI or a in a tel: URI doesn&#8217;t really matter).  That number is the key for the ENUM &#8211; lookup which returns (in most cases) a SIP-URI. <\/p>\n<p>The current RFCs define this as a retargeting operation: the phone number is mapped to a SIP AoR, and from now on the call is towards that URI and the original phone number is no longer relevant.<\/p>\n<p>If you look at what currently done in private\/carrier-ENUM settings, then this is not how ENUM is used: In most cases there, ENUM returns the next-hop for this call towards the phone number. That next hop re-extracts the phone number from the Request-URI and applies his own number\/prefix based routing to the call. In other words, this is &#8220;routing&#8221; operation.<\/p>\n<p>My draft makes this explicit: if the service field in the NAPTR is &#8220;sip:lr&#8221;, then this records contains a next hop and does not rewrite the destination of the call. Here is the example from the I-D:<\/p>\n<pre>\n   To visualize the difference between how \"sip\" and \"sip:lf\" entries\n   are interpreted, consider the following entries:\n\n             $ORIGIN 6.9.4.0.6.9.4.5.1.1.4.4.e164.arpa.\n             @  IN NAPTR  ( 100 10 \"u\"\n                            \"E2U+sip\"\n                            \"!^.*$!sip:alice@example.com!\" .\n                          )\n             @  IN NAPTR  ( 100 10 \"u\"\n                            \"E2U+sip:lr\"\n                            \"!^.*$!sip:p1.example.com;lr!\" .\n                          )\n\n   A SIP proxy dealing with a call to tel:+441154960496 can select\n   either record.  The first leads to\n\n           INVITE sip:alice@example.com SIP\/2.0\n\n   being sent to the proxy responsible for example.com.  If the sip:lr\n   record is used, then\n\n           INVITE tel:+441154960496 SIP\/2.0\n           Route: &lt;sip:p1.example.com;lr&gt;\n\n   is sent to p1.example.com.\n<\/pre>\n","protected":false},"excerpt":{"rendered":"<p>I&#8217;ve submitted a new I-D defining an enumservices subtype for loose-route SIP according to J. Rosenberg&#8217;s UA loose route (which right now is one of multiple proposals to address one problem). The basic idea is the following: SIP proxy should distinguish between &#8220;retargeting&#8221; and &#8220;routing&#8221;. &#8220;retargeting&#8221; is done, whenever a proxy decides that this call [&hellip;]<\/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-220","post","type-post","status-publish","format-standard","hentry","category-ietf"],"_links":{"self":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/220","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=220"}],"version-history":[{"count":1,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/220\/revisions"}],"predecessor-version":[{"id":1049,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/posts\/220\/revisions\/1049"}],"wp:attachment":[{"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/media?parent=220"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/categories?post=220"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lendl.priv.at\/blog\/wp-json\/wp\/v2\/tags?post=220"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}