sip.edu - Fwd: Re: [sip.edu] Numeric identifiers for sip.edu telephony
Subject: SIP in higher education
List archive
- From: John Todd <>
- To:
- Subject: Fwd: Re: [sip.edu] Numeric identifiers for sip.edu telephony
- Date: Thu, 7 Jul 2005 14:48:39 -0700
I think this might get some decent comments if more widely distributed, so I'm sending to the larger list. The following is not a replacement for either e164.arpa ENUM trees, nor is it a proposal to avoid using SIP URIs, but is a middle-ground. It also describes the method for distribution of actual endpoint identification via a hybrid of ENUM.
Date: Mon, 4 Jul 2005 15:28:45 -0700
To:
,
,
From: John Todd
<>
Subject: Fwd: Re: [sip.edu] Numeric identifiers for sip.edu telephony
Date: Thu, 30 Jun 2005 14:02:01 -0400
From: bob bownes
<>
To:
CC:
,
Subject: Re: [sip.edu] Notes from SIP.edu Conference Call June 23, 2005
Art Gaylord wrote:
Hi,
I generally like Ben's Domain Redirect idea, but am concerned about dealing with prefix collisions and the complexities of parsing variable length prefixes coupled with variable length local extensions. It also seems unlikely that campuses with long names will really want to use that as a prefix.
An alternative that I just thought of might be to use the Autonomous System number associated with each campus. This has the advantage of being globally unique, relatively short, and decimal based to start with. The obvious disadvantage is that AS numbers something that many people know. On the other hand people don't inherently a campuses area code and exchange prefix either. Some campuses may have multiple AS numbers but this isn't really a problem as they could either pick one as their SIP.edu prefix or use multiple the prefer. Since there won't be collisions either way it isn't an architectural problem.
Just an idea and one I've not carefully thought about, but figured it might worth others considering as well.
Art
One of the other folks here and I spent some time tossing the AS number about as an idea. We came up with the following 'issues'
1) as you say, it isn't something everyone knows. Easily remedied.
2) There are some locations that may not have an AS number (few, but possible)
3) AS numbers are one to five digits long. Do you parse variable length, or pad them?
4) Does not extend well outside the sip.edu community (see #2, above)
5) Some locations have more than one AS. - Pick one and use it.
However, it is an interesting idea.
Bob
----------------------------
(I'm the person Bob was talking with about ASN's as prefix-style identifiers)
The concept of using prefixes is strewn with "gotchas" no matter what identifiers are used. The traditional model has been to use geography as the element associated with a prefix, so some location information could be inferred from a fixed-length prefix (country codes, area codes, etc.) However, this model of geographic dependence is going away rapidly, as many of you already can understand. Not only is there growing social disconnection between numbers and geography ("Is that the new area code for this region? I can't keep track.") but there is also rapid technological drift away from geographic numbering due to LNP and VoIP (I have a "Maryland" area code on my cell phone, but I live in Oregon.)
It is apparent (to me, at least) that numbering for telephony needs to become geographically independent. The ENUM initiatives for e164.arpa are useful in mapping traditional phone numbers to a namespace, but I think that is step one of a three-step process. The second step is to start using numbers which have no geography. The third step is to move to "pure" SIP URI dialing methods which use email-address style pointers, but until the majority of phones have easy-to-use alphanumeric keypads, this will not be the primary method of pointer reference and it will be many years before this is in use on the majority of telephony-capable endpoints.
That leaves us looking at step 1 and step 2 as immediate possibilities, and waiting a long time for step 3.
Step (1) is already in progress, within the SIP.edu forum (via the Pulver sipeduenum.pulver.com zone) and also in the global push for ENUM adoption. However, it is still a geographically-tied numbering space, which in my opinion isn't the ideal method of identification. The local political issues of obtaining e164.arpa ranges from local telephony providers combined with the decreasing importance of geographic identity makes the e164.arpa ENUM path useful, yet not practical and probably not worth the struggle over the long run.
Step (2) of conversion would mean the usage of one of two types of numbering: first, the use of non-geographic numbers could be encouraged, such as the +878 country code. However, my experiences with the current administrators of these number ranges leave me less than impressed, as they have clearly indicated that they have a commercial interest in administering the space. This commercial interest I believe is contradictory to the desired low complexity and low policy overhead threshhold for initial adopters. There are other non-geographic ranges of numbers (such as in North America, where 1-500 and other prefixes exist) but their use and scalability is in question for large deployment across hundreds or thousands of small entities. Their administration still lies with traditionally slow and (IMHO) uncooperative PSTN infrastructures, since only PSTN people needed to get PSTN numbers, even if the numbers are non-geographic. I don't believe we should wait for this mindset to change. As a final nail in the coffin of using "real" e164.arpa numbers, the political baggage of emergency services, taxation, universal service fees, local tariffing issues, and legal usage questions are enough to make one's head spin.
If non-geographic e164 numbers offer a less-than-suitable method, what else exists? Step (3) already answers that question for us, and fairly elegantly: Use "entity" identifiers, and get away from e164. In the end-game of SIP URIs, the email-address style identifier is sufficient. The domain name is the entity identifier (everything to the right of the "@" sign) and the subscriber is everything to the left of the "@" side. Easy enough, right? With SIP URIs, the concept of geographic placement is removed (though we can, if desired, create geographic linkage through various country/city code domain names) and we greatly clarify the responsibility of call completion. If your call to "" doesn't work, then the administrator of "bar.com" needs to be notified about the problem. (Corner cases exist where forwarding may be in place to nullify this example, but fairly quick and publicly-accessible lookups will ultimately point to the culprit.) This is in direct contradiction to telephone numbering, where only the white-robed acolytes can figure out where a number actually "goes". (LNP, anyone?)
So... back on track - how do we apply those lessons to VoIP dialing in the SIP.edu environment and perhaps come up with a workable dialing method? As a community, we're out of luck on step #3, since SIP URI's can't be easily entered on most phones, and we're stuck with the digits 0-9, #, and *. Even worse, SIP identifiers are "backwards" - from left to right, they go from most-specific to least-specific (subscriber first, entity second) while phone numbers go from least-specific to most specific (country, area, subscriber.) I could suggest reversing dialing habits to match SIP URIs, but I suspect this will be outside the scope of any of our abilities to change user habits, though anything is possible. We also have very few options for separating an entity identifier from a subscriber in the keypad-only world. With a URI, it's the "@" that separates an arbitrary-length subscriber identifier from a set of arbitrary-length entity identifiers, which are in turn separated by "." at arbitrary points. It is clear that the use of arbitrary length identifiers is a very strong advantage of URI's, so a dialing system that utilizes some of the same methods I think would be ideal. A fixed length prefix is unworkable - witness the area code crunch that the United States is undergoing today. Imagine if there were 1,000,000 telephone companies instead of 7,000 and you can see that having a buffer digit makes more sense instead of having a fixed length prefix for entity identifier. If we have arbitrary entity identifiers, then we cannot rely on number of digits to separate the entity from the subscriber - some user-entered separator is required. We're fairly restricted in our use of separators: the "#" key is often used for local purposes on iPBX platforms, or even on desksets (witness Cisco and Grandstream's use of "#" as a key to signifiy "end-of-dialing" on some of their hardphones.) However, the "*" key is relatively unused, and has already been identified in several IP dialing systems as a separator, so it seems the obvious candidate to replace the analogous SIP "@" for within a numbers-only telephony keypad environment. It would also perhaps be ideal to have a single instance of "*" within a dialstring, to keep user confusion to a minimum. I resolve that we should use variable-length numeric entity identifiers, separated by a "*", followed by a variable length subscriber numbers.
A number of the style "<entity>*<subscriber>" would perhaps be the shortest and most concise, which I believe is reasonable and in line with existing behaviors. The three things that are different from existing dialing are:
1) variable length strings, both subscriber and entity
2) separation of the entity and subscriber with "*"
3) lack of geographic information of phone number
These differences are I believe offset by the widespread user acceptance of email addresses, which follow similar (though inverted) patterns and are also typically non-geographic. I am opposed to any type of "subdomain" that the user has to dial, with separations using multiple "*" characters. I think this is prone to error, and not easily remembered. I would suggest that the goal here is to be as easy to present and remember as possible, so each entity can be identified by a single identifier. Within the subscriber number there may be divisional references in an ENUM-style numeric format (i.e.: "all undergraduate subscriber numbers start with 1, all faculty start with 2 (and all science faculty start with 29), all administraive starts with 3") but the entity number should be a single integer. This also lends itself to commonly-used numbers which are valid across the entire entity, but does not try to duplicate the namespace created by the DNS in total, as that I believe is too complex for a numbering plan that will be adopted and used widely.
(Note: I am not 100% convinced on having the entity first, and subscriber second. To mimic email more clearly, maybe it's subscriber first, entity second? This is really throwing telephony-style dialing out the window, but perhaps it's more reasonably explained to the non-technical as "a numeric email address that rings your phone - usernumber, the * sign, then domain number.")
We're now left with the discussion about the values that get filled into the entity and subscriber numbers, and where those numbers come from.
The original genesis of this thread was the suggestion to use Autonomous System Numbers (ASN's) for dialed entity identification. This method is already in use by the INOC-DBA (Inter-NOC Dial-By-ASN) telephone system, used by several hundred network infrastructure and other organizations for problem resolution. See http://www.pch.net/inoc-dba/ for more details. The INOC-DBA system uses the fact that ASNs are synonymous with routing entities - dial the ASN, and you reach the person(s) managing that ASN. I disagree that ASNs should be used as numeric identifiers for a larger effort that is not part of the INOC-DBA network. ASNs are allocated for the explicit purpose of identifying IP routing entities (typically BGP.) They have a set of use requirements that are not in harmony with the uses of Internet Telephony, and should not be used for anything other than their original purpose. The allocation requirements for ASNs do not speak to any use other than for IP routing. While I expect that all Internet2 organizations have an ASN, we should not be so short-sighted in our thinking. If a numeric identifier is aggressively used within Internet2, then it will be the case (as seems to be the case with all Internet standards) that the usage will creep outside of the limited domain in which it was developed. This means that other organizations (commercial, government, etc.) will start using their ASNs as dialing prefixes. Soon, organizations which do NOT have an ASN will find that in order to accept calls, they will need to get an ASN. Here is where the conflict arises with dual-use: why should it be necessary for an organization to get an IP routing identifier to make phone calls? This is clearly outside the charter of ASN's. Changing the identifier in order to convert to some other identification model after launch will be excruciatingly painful to all involved, so I believe that another more scaleable method must be devised as a VoIP entity identifier, and which is specific to that purpose.
To that end: I propose that we re-purpose some of the intent of RFC3219 (TRIP) and use it for entity management. RFC3219 describes a BGP-like method for routing e164 telephony numbers. I really like TRIP; it would be a great method to use for carriers. However, very few implementations exist or are being used, so it's been mostly dead as an active technology for some time. There was, however, a brilliant part of the specification that created a new IANA-recognized number: the ITAD. ITAD stands for "Internet Telephony Administrative Domain", which is simply an incrementing integer which associates an organization with that number for the purposes of routing within Voice over IP. This is very similar to an ASN which is used in IP routing, but without hitting the entangling problems of dual-use of a single identifier. Here is the section from RFC3219 dealing with what is required for ITAD numbers:
- start of RFC quote -
13.5. ITAD Numbers
This document reserves the ITAD number 0. ITAD numbers in the range
1-255 are designated for Private Use. ITAD numbers in the range from
256 to (2**32)-1 are allocated by IANA on a First-Come-First-Serve
basis. Requests for ITAD numbers must be submitted to
.
The requests MUST include the following:
- Information about the organization that will administer the
ITAD.
- Contact information (postal and email address)
- end of RFC quote -
The use of the ITAD as a dialing prefix is not addressed by RFC3219, though it is clearly in line with the intent of the RFC: to improve IP-only interconnection of telephony-like communications. If TRIP becomes more widely adopted, then the pre-built number of entities with ITADs will only improve TRIP's chances, so I see no downside for this use of the RFC's specifications. There is no cost for registering for an ITAD. There are no restrictions on who can register for an ITAD - it is an open registration. There are no pre-requisites for registering for an ITAD.
The concept of overlaying existing ASNs into ITAD space is possible, but is probably not viable due to what will arise quickly as "digit length envy" where non-ASN holding entities will claim unfair treatment due to their numbering starting at strange and many-digit locations. Plus, that's not the way IANA hands out numbers. I believe it is best to distribute numbers on a first-come, first-serve basis.
I would describe the combination of entity number, *, and subscriber number as an "ISN" - ITAD/Subscriber Number. Other acronyms are welcome, but for the sake of this message I'll use that as a reference term.
Next up: subscriber numbers. I would suspect that most of the world's universities have less than 100,000 phone numbers that are managed by the campus IT staff. This means that most universities can be enveloped in a five digit dialing plan, which may even overlay to some degree their existing xxx-yyyy allocations they have from their PSTN providers. This would mean, as an example, that an extension at Enormous University might become 284*23342, where "284" is their ITAD, and "23342" is the subscriber. This same subscriber has a PSTN phone number of 293-222-3342. In a five digit extension world, this will not always be so clean - there will be places that have first-digit overlap (where 123-xxxx and 333-xxxx might be existing from the PSTN) but I suspect that more than 60% of a campus number pool will be able to simply take the last five digits of the phone number and create a new identifier from those digits.
The issue of PSTN/ISN number suffix overlap may be completely moot, depending on how the local administrator chooses to deploy the numbering scheme. I talk about a 5-digit dialplan for convenience - it can just as easily be a seven digit dialplan. Or eight. Or more. Everything to the right of the "*" separator is under the control of the local administrator, and is not constrained to an e164-style number. In fact, the truly bludgeon-wielding admin may simply put the full (national) e164 number to the left of the "*", like so: "284*2932223342". An enlightened administrator would hopefully trim the area code from the number, but local policy is best left up to the local policy-makers. I'd hope that the final number is the same or fewer digits than an e164 number (10 digits here in the US.) It may be the case that a completely new numbering sequence is created for IP-only communications, which might be the best solution. The desk phone would ring on the old e164 number, or on the "new" ISN number.
The summary for subscriber numbers is that they are whatever the local administrator wants them to be - it is _totally_ up to the local admin as to how those numbers should be parsed and distributed. Using the DNS or using SIP proxies to point calls is delegated to the adminsitrator of the ITAD, and the format (save the reserved status of "*" and "#") is up to the local admin.
This leaves the problem of how to actually get the dialing to go where it's supposed to go. This actually is not a tough problem: it's a modification of ENUM - a hybrid. The ITAD becomes a zone identifier, and the subscriber number gets converted in the "normal" ENUM reversal method. This allows for zone-wide (ITAD-wide) allocation of NS pointers, since the splits in authority are exactly corresponding to splits in the number space, and the * separator also splits the entity/subscriber at exactly the same place. If we used full ENUM-compliant numbering, there would be no way to distingish between subscriber and entity, so zone names of the full numeric entity string are used instead to provide that distinction. The numeric zone identifier needs to be prepended onto a "normal" zone of some type for convenience and feasible implementation. (i.e.: 4.3.2.1.256.example.com) Any top level domain/secondary level domain may be chosen, so long as all participants are aware of the zone and the administrative process to have their ITAD added to the zone in the form of NS pointers. Each entity then can control their own ENUM-style suffixes as they wish, on their own nameservers. See the example below for a more clear description; it's easier to demonstrate than to describe.
Policy changes/Follow the money:
1) IANA
IANA may wish to charge a nominal fee ($35? $50?) for handling registration of ITADs instead of handing them out for for no cost as they do now, to offset the load and to create an auto-expiration table. There may be some desire to moderately or strongly authenticate ITAD submissions after some "critical mass" of applications, so that in the future some variant of reverse-path authentication could be used to prevent SPIT issues. (Think SPF for phones; this has been discussed previously in other ENUM forums.) However, the initial few hundred (or few thousand?) applications may simply be submitted without fee to get the number plan into wide use.
2) Domain
It also may be the case that the second-level domain registrar may _eventually_ require some nominal payment for service updates. Again, this would probably be freely managed until such time as it became a measurable percentage of an administrator's day to manage, or a significant load on existing nameservers (doubtful for some time.) The domain would only contain NS pointers, and not any NAPTR data at all (with one exception, read on.) The NS pointers would point back towards a nameserver(s) located in the control of the ITAD administrator. If there was one NAPTR for the entire zone, then perhaps it would be reasonable to permit a single wildcard NAPTR list to exist in the "top-level" ITAD identification zone for ease of deployment in beta environments or in environments where there was no frequent change of NAPTR data.
The domain administrator would ensure that there existed an ITAD for each submission to the second-level domain NS tree.
Who administers this domain? Good question. DNS is actually pretty easy to admin, and costs almost nothing from a system perspective as long as you have an infrastructure already in place. There are several places off the top of my head that could administer such a domain: PCH (Packet Clearing House - disclaimer: I used to admin some of the DNS there), Pulver.com, Tello (disclaimer: I work there), or even one of my shell companies. I'm sure there are many other options, but the end organization needs to have some basic legal protection as an entity, and a basic charter that makes it responsible to the "member" organizations (where "member" may simply be participating in a low-volume mailing list or something along those lines.)
What domain to use? Well, good question again. I have "freenum.[org,net,com]" which I've been using for toll-free ENUM presentation - I'd be willing to let that be used as a test or permament home if traction can be developed. I'd suggest e164.arpa but there are PSTN dragons in that cave... This would be well suited for a .int suffix, but I'm afraid that the NS lookups on that TLD might be slow (though surprisingly not according to my quick tests) and the politics surrounding getting such a domain are mired in paperwork and committes. Discussion?
Technical changes:
1) SIP proxy changes
Each participant will need to modify their SIP proxy/iPBX to perform ENUM lookups in this new ISN format. The telephony proxy will need to match on <num>*<num> and split apart the string in the appropriate format, and then do an ENUM lookup in the style required. SER and Asterisk can parse ISN format without much difficulty due to their string manipulation applications, but commercial vendors may have significant problems with this type of lookup due to their inability to handle zone lookups created with parts of the ENUM query. However, there is an option: using an external DNS re-writer with some internal rules as a forwarding resolver can provide the functionality to _any_ ENUM-capable device. (Bob: mods to shotgund for this option would be trivial.)
Other that the lookup mechanisms, nothing would need to change for existing users of SIP.edu. Any location that has existing NAPTR records would be able to use the ISN style pointers immediately. It may be the case that the ISN format would shorten the number of digits required for dialing into a proxy/gateway (a full e164 address is not required) so that perhaps would have to be locally managed, but that might be seen by most as an advantage and not a disadvantage.
Technical Example/Nuts and bolts:
As an example, let's say Tommy wants to talk to Buckaroo at Enormous State University, and Buckaroo's ISN is 1234*2203. Tommy's PBX/SIP proxy would see that an ISN-style number was dialed, and it would perform some process on the number in a way that looks like this:
if the number dialed is three or more numbers and
followed by a * and
followed by one or more numbers
then process the query in the following way:
$domain=take digits to the left of the * and append "freenum.net"
$subscriber=invert the numbers to the right of * and separate each with "."
perform a NAPTR lookup on $subscriber.$domain and act on the result (dial/INVITE or play error message).
else
pass call to normal outbound SIP/trunk processing.
So, the NAPTR from Tommy's request looks like this:
NAPTR request for 3.0.2.2.1234.freenum.net.
After TLD/SLD lookup, the "freenum.net" nameservers would reply back with the NS pointers for zone 1234.freenum.net, which is ns1.enormous.edu. Tommy's PBX/SIP proxy then would ask ns1.enormous.edu for the NAPTR, and since ns1.enormous.edu is authoritative for 1234.freenum.net, it would reply with:
IN NAPTR 100 10 "u" "E2U+sip"
"!^\\+*(\*.*)$!sip:\\!"
.
At this point the lookup turns into a NAPTR lookup with which we're (hopefully) all familiar, and which only needs basic review. The returned regexp translates roughly into: Ignoring any leading "+" characters, take all the digits to the right of the "*" character in the dialed number and put them between "sip:" and "@voip.enormous.edu". (Someone please check my regexp - I'm terrible with NAPTRs. I'm not sure if this re-writing would occur on the original number, or on the number that was sent via ENUM...) So this results in:
sip:
Then, the SRV records are looked up for voip.enormous.edu, then the A records for those SRV records, and then the INVITE is transmitted. As usual, using IP addresses instead of names shortens the post-dial-delay due to lack of DNS requests past the NAPTR lookup.
Alternately, a DNS re-writing proxy would perform all these lookups transparently, and without any logic on the iPBX or SIP proxy. More on this in a short while, hopefully.
THE CONCEPT SUMMARY:
Geographic phone numbers are old technology. Entity-based phone numbers make more sense, and map more clearly to the uses that VoIP encourages. Despite being a new concept for keypad entry, it is familiar enough to anyone who uses email such that they will not be confused by the concept.
ASNs are a good entity identifier which can be used as a dial prefix, but will run into problems in larger use environments because ASNs were not designed for telephony use, and may conflict with current policy of allocations and exhaustion of number resources.
ITADs are a better choice of entity identifier, since their intent was specifically for VoIP usage. While the RFC does not speak directly to using ITADs within the dialing string, I believe it is certainly not an unreasonable or out-of-charter usage of the identifier. They are a "blank slate" for usage of this type, and seem ideal.
Regardless of if ASNs or ITADs are used for numeric dialed prefixes, I believe the concept of prefix breaks (the "*" separator) will somehow need to exist. A fixed length telephony dialing prefix in an "entity-based" dialing world is unfair and unworkable if the goal is to encourage small entities (schools, small businesses) to use VoIP. This means arbitrary-length prefix identifiers, which means a separator between entity and subscriber is required to correctly route calls. Call routing platforms and iPBX systems need to have the intelligence to create meaningful queries, but there are multiple ways to solve this technical challenge.
Using ITADs and a simple modified ENUM tree will result in a globally scalable, (more) easily managed, and understandable VoIP network while providing local control to administrators. The cost for implementation is extremely low (zero?) and can easily be integrated into any telephony system that supports ENUM. It can work side-by-side with existing ENUM implementations with no contention.
The End.
JT
Comments since the original message:
1) Ben, Art, and Bob all agreed that <subscriber>*<entity> is a better format, and I agree after some thought on it. Make it look more like a URI.
2) I've not yet been able to get comments by IANA that specifically describe the registration process - to date, ITADs have been "ad hoc". I hopefully will have some more clear descriptions of the registration process and requirements (if there is anything special) shortly.
3) There has been some confirmation that PBX's or other dialing systems will pass the "*" key. I don't know of any that won't, but I'm sure there are some exotics...
4) A "local" prefix for getting to the ISN dialing network is probably going to be required at each individual location. This can vary, depending on operational requirements of that telephony network. As an example, one may have to dial a leading "022" before entering an ISN dial. This is not two stage-dialing; it's simply a local prefix to tell the PBX that the next numbers it sees are ISN numbers. (think about when you have subscribers whose subscriber number starts with the totally valid string of "911", and you'll see why a local dialing prefix may be required.)
JT
- Fwd: Re: [sip.edu] Numeric identifiers for sip.edu telephony, John Todd, 07/07/2005
Archive powered by MHonArc 2.6.16.