Discussion List for Freenum/ITAD Subscriber Number (ISN) Project

[John Todd <>]

At 8:22 PM -0500 2007/11/30, 

 wrote:
>    From: 
>
>  (John R Covert)
>
>    2. the standard that the "0" extension always gets you to some
>       sort of informational message about what to dial, or to an
>       IVR of some sort, or to a human attendant.
>
> Interestingly, assuming that the "real" extensions are at least 2
> digits, it's not hard to use another NAPTR record to map extension 0
> to an arbitrary SIP user-part.  Copying from someone else's example:
>
> *.765               IN  NAPTR 100      10      "u"     "E2U+sip" \
>                 
> "!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
>  .
> *.765               IN  NAPTR 100      10      "u"     "E2U+sip" \
>                 
> "!^0$!sip:!"
>  .
>
> Dale


Dale -
  I'm not entirely sure that would work correctly, but it's close. 
While I can't say for certain, I believe that wildcards will 
interfere with specific records, so if you wanted to have "0" point 
to a specific URL (which you can do) then you'd have to put in a new 
set of wildcards for every other possible iteration of that zone if 
you wanted other subscriber number patterns to find their way to the 
SIP proxy correctly.  Once you shatter the wildcard with a specific 
call-out, I think you'll need to enter in every other possible entry 
for that level of the DNS hierarchy.  I've skipped all but the 
regexps in the examples below for what I think you'd need to do:

0.765    
"!^0$!sip:!"
*.0.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
1.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.1.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
2.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.2.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
3.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.3.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
4.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.4.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
5.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.5.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
6.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.6.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
7.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.7.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
8.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.8.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
9.765    
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"
*.9.765  
"!^\\+*([^\\*][^\\*][^\\*]*)!sip:\\!"

As an aside: one could have each subscriber in an organization have 
their own re-mapping, so if user "" had a 
subscriber number of 5805 (and a fully qualified ISN of 5805*404) 
then, if the administrator chose, this could be the remapping in 
their delegated DNS for 404.freenum.org:

5.0.8.5.404  
"!^0$!sip:!"

(note: this is not a valid example, as TalkPlus does not have a 
delegated zone for their ITAD)

You could make such a re-mapping for every subscriber number, 
pointing to a totally new SIP URI in some other SIP domain.  That's 
up to how the administrator or whoever has authority over the 
subscriber portion of the number within the ITAD, and that's what 
makes this a very flexible system when moving up to larger scales - 
it uses some of the flexibility of ENUM but doesn't get bogged down 
in the political/legacy issues of E.164.

JT