Skip to Content.
Sympa Menu

isn-discuss - Re: [isn-discuss] Dialed number routing

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

List archive

Re: [isn-discuss] Dialed number routing


Chronological Thread 
  • From: John Todd <>
  • To:
  • Subject: Re: [isn-discuss] Dialed number routing
  • Date: Sun, 21 Nov 2010 22:41:53 -0800


On Nov 21, 2010, at 5:39 PM, Ross Lindsay wrote:

> Hi all,
> Am I missing something or can you not route different calls (XXXX*YYYY)
> where the XXXX differs to a different destination than others? Ex: Route
> 1111*1111 to extension 1111 on Server A, but send 1112*1111 to extension
> 123 on server A?
> Let me know if I need to clarify.
> Thanks!
> Ross Lindsay


I see there's been some discussion on this while I was away for dinner. :-)

The answer is: YES! And not in the ways that the other folks here have
identified, though using the protocol level stuff with SIP would also work.
The more scalable way (the DNS way) is baked into the ISN dialing methods,
but almost nobody uses it because it's over on the "sophisticated" end of the
spectrum that most organizations don't require.

It is possible for each SUBSCRIBER number to have their own SIP NAPTR
records. That means you can make each subscriber number go wherever you want
- you could have this:

1112*1111 maps to
sip:
1113*1111 maps to
sip:
1114*1111 maps to
sip:

So, how does one go about this? Well, there is some pain involved. The pain
is that you'll have to give up the easy life of letting the freenum.org
servers carry a wildcard for all your subscriber numbers that does the same
thing. Almost everyone (though not quite _everyone_) simply puts a regular
expression string in the freenum.org servers for their ITAD that says (in
meta-speak): "Re-write all my ISN queries in the freenum.org domain under my
ITAD so that the subscriber portion is slapped into the front of a plain old
SIP URI that points to <subscribernumber>@mydomain.net"

For instance, when someone looks up the NAPTRs for 1234*256, they get this:

empty-zot:~ jtodd$ dig +short NAPTR 4.3.2.1.256.freenum.org.
100 10 "u" "E2U+iax2" "!^\\+*([^\\*]*)!iax2:@204.91.156.10/\\1!" .
100 10 "u" "E2U+web:http:" "!^.*$!http://www.loligo.com/!"; .
100 10 "u" "E2U+sip"
"!^\\+*([^\\*]*)!sip:\\!"
.
empty-zot:~ jtodd$

So, their server takes the SIP regular expression from that list, applies
regexp magic on it, and ends up with:


sip:

as the final answer. Presto, they attempt a connection on that SIP URI
through the regular SIP methods. The ITAD 256 has a wildcard that does this
for EVERY lookup in *.256.freenum.org. This is the lazy and normal way to
have entries in the Freenum database/DNS zone, because most organizations
only have one external SIP server (or at least, they only have one policy
that applies to all users even if they have multiple priorities and weights
in the list of NAPTR records they hand back.)

What YOU want to do is delegate your ITAD (1340) to your own nameservers and
split up the subscriber portion so that each subscriber has their OWN record
instead of using the wildcard method. This can be done via the FAAST web
interface by selecting "DNS -> Delegated" and then specifying your two
nameservers. You would then create a zone called "1340.freenum.org" on YOUR
nameservers, and populate it with a lot of records like this:


2.1.1.1 IN NAPTR 100 10 "u" "E2U+sip"
"!^\\+*([^\\*]*)!sip:!"

3.1.1.1 IN NAPTR 100 10 "u" "E2U+sip"
"!^\\+*([^\\*]*)!sip:!"

4.1.1.1 IN NAPTR 100 10 "u" "E2U+sip"
"!^\\+*([^\\*]*)!sip:!"


These say "take a ISN-style number and... well... er, ignore everything and
just use this URI I give back to you."

This method allows for darn near infinite scaling down to each individual
subscriber, and subscriber number space can be delegated on number boundaries
even further, if your organization needs that kind of administrative control
and segmentation. We require delegating the zone to your nameservers if you
aren't using the wildcard method, since the Freenum project doesn't have the
tools to do true DNS administration, plus this is not something we really
want to put ourselves in the business of managing. If you know enough about
the DNS, then you'd probably want to do this yourself anyway.

Good luck! I'm happy to answer more questions on this if it isn't clear.

JT


---
John Todd - Advocate -

ISN: 2203*256 tel: +1-301-561-1020




Archive powered by MHonArc 2.6.16.

Top of Page