View Single Post
Unread 02-02-2008, 03:00 PM   #2
Join Date: Mar 2006
Posts: 96
Thanks: 8
Thanked 26 Times in 19 Posts
v164 is a jewel in the roughv164 is a jewel in the rough
Default using these ATAs

Consider how VoIP users could use ENUM / peering with the three different types of ATAs -

Originally Posted by v164 View Post
Summing up the three different types of ATA hardware used:

1. Softbank's "BBPhone" ATA, using MGCP (not SIP). Earlier types were a separate ATA with built-in bridge, that would connect to the ADSL modem. Most types these days are combined with the ADSL modem, which has router / bridge mode. (In the case of bridge mode, the ATA part has it's own separate public IP address).
As I explained here,
Eikaiwa--Discussing Japan in English: VOIP, SIP, MGCP

Between the MGCP protocol, and their own VoIP adapters... the "BB Phone" service is locked down.

Outside of reverse engineering and emulation measures, the only option would be for the subscriber to...

... buy an unlocked SIP-compliant analog telephone adapter (ATA), and put that between your analog telephone and your (locked) Yahoo BB modem.

Originally Posted by v164 View Post
2. Locked SIP ATAs (mostly Cable Internet providers reselling a white label VoIP service). Typically, the ATA includes a bridge, and so goes between the cable modem and the customer's PC / router. The ATA has it's own public IP address. The ATA uses the SIP protocol, but it's locked.
These ATAs accept incoming SIP calls direct from anywhere on the Internet, so if you can determine a SIP URI that the ATA will answer to (typically 050xxxxxxxx@ipaddress), incoming ENUM can be enabled by simply mapping the PSTN and/or 050 number to that SIP URI at (and watching out for IP address changes). The ATA is typically a bridge (not a router), and hence has a separate public IP address (it may be necessary to capture packets between the ATA and modem find the ATA's IP address).

Incoming ENUM can be set up conveniently, with no changes to hardare or equipment settings. For outgoing ENUM calls, I suppose you could have a transparent proxy intercept the outgoing SIP INVITE packet and re-route if there's an ENUM match, but short of doing that, the purchase of an unlocked ATA would be in order.

(It should also be noted that, in most if not all of the above cases (1) and (2), the ATA is owned by the ISP).

Originally Posted by v164 View Post
3. "Unlocked" SIP ATAs for use with ISP's accessed via NTT "Flets" ADSL / Fibre. The ISP supplies a list of "approved" NTT-branded ATAs (which are not locked (they can be set to use any SIP server) but are specifically designed for the "IP Phone" service (eg dial plan, etc is hard coded)), which the subscriber can either rent or purchase from NTT.

This is the type of ATA written about in this post:
These ATAs offer the greatest promise for facilitating ENUM and VoIP peering, because they are SIP "RFC 3261" compliant, can be set to use any SIP provider (NTT keeps on pushing the fact that with their "Flets" service you have a choice of providers), and the ATA is not provided by the VoIP provider, but is procured separately (from NTT or elsewhere (Internet auction, etc)), so the subscriber is free to configure that ATA however they wish.

These are the ATAs of which I wrote,
Originally Posted by v164
The SVIII modem is representative of the most widely used unlocked SIP ATA in Japan - those provided for use with the bundled "IP Phone" services provided by Japanese ISPs using NTT-West / NTT-East "Flets" ADSL connection. I intend to write in more detail about this at a later date, because supporting these SIP devices would be, at this point in time, the most effective way to drive adoption of ENUM and VoIP peering among Japanese VoIP users.

All that's needed to use ENUM and peering, incoming and outgoing, in this situation, is a suitable SIP server for these ATAs to use. A SIP server like VoXaLot would be suitable, except for three issues that would need to be resolved:

Enable sending a "380 Alternative Service" message back to the ATA for calls that should go via the PSTN, as described here:

Filter out the "=on" part of the ";lr" parameter, to prevent the problem described here:

For incoming / outgoing calls that don't match ENUM: In some cases, the ISP blocks SIP messages to their server from outside their network, so INVITE and REGISTER messages from VoXaLot on behalf of the subscriber would be blocked. This problem would have to be resolved, perhaps by:
- sending a "redirect" message back to the ATA, to get the to ATA send the INVITE or REGISTER message to the ISP direct (ala
- establishing a SIP proxy for VoXaLot within the ISP's address space
- finding alternative providers for outgoing (and/or incoming) PSTN calls
v164 is offline   Reply With Quote