Skip to Content.
Sympa Menu

isn-discuss - Re: [isn-discuss] Testing ISNs with FreePBX

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

List archive

Re: [isn-discuss] Testing ISNs with FreePBX


Chronological Thread 
  • From: James Cloos <>
  • To:
  • Subject: Re: [isn-discuss] Testing ISNs with FreePBX
  • Date: Thu, 29 Oct 2009 19:52:23 -0400
  • Copyright: Copyright 2009 James Cloos
  • Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
  • Openpgp: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
  • Openpgp-fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6

>>>>> "John" == John Todd
>>>>> <>
>>>>> writes:

John> I can completely understand the desire to have "0" as the main
John> number of an organization, though maybe it shouldn't be the "main
John> number", but should be "human operator". This still makes for
John> very difficult dialplan interpretation for those who are not using
John> a fully SIP-compliant system (a "dial-as-you-go" interface like an
John> older ESS, which still runs the majority of the phones in the world.)

That is one of the bugs with choosing endian-little rather than big-endian
strings for the ISN format.

I know that the idea was to emulate the format of email addresses (perhaps
indirectly, via the format of sip: urls?), but one can argue that that is
also a bug for email addresses. And it never felt quite right to me.

Emulating for big-endian format of most other urls would make for (or would
have made for) easier dialplans and also provide the conceptual advantage,
when phoning an organization, of thinking "this org" and then "this person"
or "this role".

The ENUM lookup would be the same as now, only the advertising and dialing
order(s) of the number would be (or would have been) different.

That is not to say that there would be no bugs with choosing the big-endian
order. (Although I cannot think of any off-the-cuff. :)

-JimC
--
James Cloos
<>
OpenPGP: 1024D/ED7DAEA6



Archive powered by MHonArc 2.6.16.

Top of Page