Support for ISN Dialing

[VaHam]

ISN allows for easy sip dialing from a 12 button keypad on a phone.  By using sip dialing the traditional phone network is not used at all to place calls between endpoints; thus all calls are free!  Entering sip addresses from a 12 button key pad would be hard to do but the ISN approach makes it a breeze.

Implementation is relatively simply and would offer an additional feature not available on any other device; just as GV support does.


From: http://freenum.org/faq.html

ISN is an outgrowth of the Internet2 SIP.edu Working Group and is still in an experimental trial phase. Several large public and private universities, including MIT and UCLA, were among the first domains to implement ISN. Other domains, including service providers, commercial enterprises, and governmental entities, are coming on-line quickly. The VoIP service provider Free World Dialup has supports ISN and it is expected that other Internet Telephony Service Providers will be joining, as the barrier to entry is very low and implementing ISN obviates the need for a confusing set of escape codes to call between VoIP service providers.

In addition to the .edu and other companies mentioned above, ISN is implemented on many Asterisk PBX systems.  If just ISN dialing were implemented OBi users could place calls to any ISN equipped destination for free.

If Obihai registered it's own ITAD then it could implement a server allowing anyone in the world to call an OBi using sip dialing by say entering an Obi number followed by an * followed by Obihai's ITAD number.  In this manner any other system which is ISN equipped could dial an OBi device for free.

It would be a powerful additional feature and not that difficult to implement.

[QBZappy]

VaHam,

This is an interesting idea. It would make the OBi ecosystem much larger and ubiquitous. OBi could not possibly hope to bump all other ATAs off the market and be the only player. A larger ecosystem would certainly invite others to the hardware platform. If a server was indeed provided by OBihai and a numbering system based on the OBi units it could certainly add value to the product. I suppose that this idea could be implemented by any other 3rd party as well.

On the downside it is distracting from the development of the hardware platform. I'm not certain that at this time of their development they should loose focus on the meat and potatoes of their business.

The OBi ecosystem could be developed around various 3rd parties willing to provide a service incorporating the OBi products. At the moment there is at least one 3rd party who is supporting the OBi in a software product. It would be nice if there were others  with the smarts who could develop other products.

Anyone else have any thoughts on this?

[lhm.]

Sort of like iNum.net and Enum.org not exactly taking the VoIP world by storm. (Free World Dial Up died about three years ago.) Interesting concepts though, with great potential, but slow to gain traction. imho

[VaHam]

I think the beauty of Obihai supporting ISN is that their infrastructure already includes most of the functionality which would be necessary and would not require an significant additional overhead for them while expanding their peer2peer (P2P) capabilities.

Implementing the ISN dialing code necessary in the OBi requires only a simple DNS type lookup to obtain the domain name/ip of the called party and reversing the first portion of the dial string and then placing a sip call.  Most of these routines are already in the OBi's code so the only addition would be the one DNS type lookup to translate the ITAD number to a domain/ip and reversing the digits before the *.  There are only something like 600 ITAD which have been issued internationally but of coarse a university only needs one ITAD for instance to make all of the phones connected to their PBX(s) also have ISN capability; but that means the lookup between ITAD numbers and domain addresses is a easy task. Freenum which is very much alive provides this DNS service for free currently. Only the domain name/ip of the top level ITAD needs to be looked up and it is the responsibility of the ITAD domain to provide routing to the extensions for that domain.

Obihai already provides routing to it's devices via the ObiTalk network so that structure is in place. The only addition needed to accept ISN calls would be a daemon which passes off the sip invite to the OBi device.  A PBX with a shared database to the OBiTalk network connection information could be used to perform this function.

If ISN were supported then any PBX could provide gateway services to the OBiTalk network.  So for instance I could open a few DIDs on my PBX and forward incoming calls to any OBi device. Of coarse DISA would allow calls to be placed to any OBi device as well via sip P2P for free.  Who knows perhaps grassroots gateways would start popping up or companies like Google would start supporting ISN dialing.

INUM is interesting but you need to have to have voip service and it is not strictly P2P or completely free.  I suppose Obihai could provide INUM's but that would entail a lot more infrastructure, routing and costs.  While it would be nice if each Obi had it's own INUM, I can see where that may not be too attractive to Obihai.  You can't simply register some where and obtain a INUM for free without paying something.

ENUM is P2P based and thus truly free but you do need to have a DID to associate with the domain/ip address and of coarse either a fixed ip or dynamic DNS inorder to use it and it requires users to setup up ENUM themselves.  The ENUM look ups have to be done on each outgoing call to see if the number has an ENUM address, which adds latency and overhead.

ISN has suffered acceptance so far, I suspect, because a PBX or the like is currently required in order to make use of the ISN P2P scheme.  If Obihia adopted ISN then it would be the first hardware device to allow it natively and I suspect that would enhance ISN's popularity greatly.

[VaHam]

I wonder if now that GV is going away Obihai might reconsider the ISN implementation? Short 12 digit keypad dialing to any Obi seems very attractive to me.

[giqcass]

Obihai could add ITAD as a "certified service provider" and have a setup wizard for it but I don't see any reason the Obi can't dial these numbers now.  You just need to set up a dialplan for them.  Most people create a prefix for ISN/ITAD dialing.  It's actually a recommended solution on the freenum webpage.  To anyone considering this I recommend you register now because it is not an instant process.  It took me quite a while to be added to the IANA database.

I would set up a sip gateway using public.freenum.org for the proxy.  No password or user name is needed.  Since I only have a couple ITAD number to dial I just went the easy route and created speed dials for them.
See http://freenum.org/cookbook/  Check out parts 5.1 and 5.1.2 on the page in particular.

[VaHam]

Yes Obihai registering an ITAD is what I was suggesting, but rather than requiring a separate setup, that the data Obhai already has be used.  Since the OBi's already register to OBiTalk network, and have unique OBitalk numbers, they handle winding thru your firewall without having to punch a hole in your security and also accommodate dynamic ip's.  So say any OBiTalk number * OBhai's ITAD would ring the OBiTalk device, without the calling device itself having to be registered to the OBiTalk network, via a redirection from the OBihai server. This would require I suspect only minor changes on Obihai servers. Dial string parsing with any number followed by * followed by any number again would be fewer key presses and make it easier for the user to dial.

To allow the OBi devices to easily use ISN to contact other non-OBiTalk ISN systems then what would be nice is for the OBi device firmware to handle native (5.1.1 from the cook book) ISN lookups itself, rather than require the setup of a proxy, to make it easier for users.  This would of coarse also mean that outgoing sip dialing be handled by the OBi device without the needing to have a sip provider enabled to place the outgoing call, again for the simplicity of the user.