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”.
- “retargeting” is done, whenever a proxy decides that this call should be directed towards a new destination. Consequently, the Request-URI changes.
- “routing” happens, when a proxy forwards the SIP message to the next hop, but does not change the identification of the target.
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.