On Jan. 30th, 2008, I sent the following to the sipping list. It is a good summary of some of my thoughts on the RUCUS problem statement and on which basic premises need to be sorted out first.
…
On Jan. 30th, 2008, I sent the following to the sipping list. It is a good summary of some of my thoughts on the RUCUS problem statement and on which basic premises need to be sorted out first.
…
I’ve submitted a new I-D defining an enumservices subtype for loose-route SIP according to J. Rosenberg’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 “retargeting” and “routing”.
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’t really matter). That number is the key for the ENUM – lookup which returns (in most cases) a SIP-URI.
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.
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 “routing” operation.
My draft makes this explicit: if the service field in the NAPTR is “sip:lr”, then this records contains a next hop and does not rewrite the destination of the call. Here is the example from the I-D:
To visualize the difference between how "sip" and "sip:lf" entries are interpreted, consider the following entries: $ORIGIN 6.9.4.0.6.9.4.5.1.1.4.4.e164.arpa. @ IN NAPTR ( 100 10 "u" "E2U+sip" "!^.*$!sip:alice@example.com!" . ) @ IN NAPTR ( 100 10 "u" "E2U+sip:lr" "!^.*$!sip:p1.example.com;lr!" . ) A SIP proxy dealing with a call to tel:+441154960496 can select either record. The first leads to INVITE sip:alice@example.com SIP/2.0 being sent to the proxy responsible for example.com. If the sip:lr record is used, then INVITE tel:+441154960496 SIP/2.0 Route: <sip:p1.example.com;lr> is sent to p1.example.com.