[Asterisk-Dev] OT - Regulatory hurdles for Zaptel and Japanese PRI

[Steve Underwood]

Benjamin on Asterisk Mailing Lists wrote:

>Hi
>
>in a private email exchange, John Todd said I should post this to the
>Dev list. He thought it would at least have some curiosity value even
>for those who are not interested in Japanese PRI. Anyway ...
>
>Japanese PRI is derived from US PRI but the Japanese have the tendency
>to protect their turf by changing specs they borrow just enough to be
>incompatible so as to put up hurdles for foreign vendors to sell their
>gear unmodified in Japan. This allows the Japanese vendors to
>overcharge for most of the stuff they sell domestically and thereby
>subsidise dumping prices on the stuff they sell overseas.
>
>Japanese PRI, aka J1 is one of those areas where they do this rather
>successfully and seemingly with impunity.
>
>To put this into perspective ...
>
>The cheapest Japanese J1/VoIP gateway costs about 40.000 USD for a
>single span J1. The cheapest foreign manufactured J1/VoIP gateway used
>to be a box from Multitech. The T1 version of this box is available in
>the US for about 4000 USD. The J1 version is about 24.000 USD.
>Compared to Japanese products this was still to be considered cheap
>until a few months ago, when a Mainland Chinese company entered the
>market with a J1/VoIP gateway that "only" costs about 10.000 USD. By
>comparison, Dialogic J1 boards are roughly in that same price range.
>
>
>You can imagine what kind of tsunami effect a Zaptel card would have
>in this environment if it supported J1. However, the technical side of
>making this happen doesn't seem to be the biggest obstacle.
>Apparently, the differences between T1 and J1 are such that it looks
>as if it was possible to adjust for it in the driver software alone.
>The trouble is that nobody wants to sponsor this work to be carried
>out due to the regulatory situation.
>
>The Japanese type approval authority wants applicants to submit to
>their process and not do anything that puts it into jeopardy. Yet it
>looks as if the way in which the drivers are released via anonymous
>CVS is incompatible with the way the approvals process works.
>
>Strictly speaking, if Japanese type approval is to be granted, no
>driver updates should be made via anonymous CVS until the updated
>drivers have been submitted to, tested and approved by the approval
>authority. Every such release cycle will cost around 3500 USD in
>application fees plus the fees charged by an accredited testing lab
>for carrying out the compliance testing. If updates or patches to
>drivers are released into the public without going through this
>process, then - going by the book - it could invalidate the type
>approval.
>
>The trouble is that a foreign product that looks like it is going to
>whack the Japanese establishment is more likely to be checked for any
>possible ways to turn down the application than a Japanese product
>from one of the big name vendors where the authority may not be always
>as strict as their rules may imply. They don't even have to give you
>reasons why they turn down an application. They can just turn you down
>and tell you to submit another application in order to delay your
>market entry or to make it more expensive for you so you have to sell
>your product at a hefty premium, too.
>
>I have asked Digium for their opinion on this and suggested that the
>solution may lie in a forked driver which is only for J1, then somehow
>control the release process for that driver more tightly so as to not
>raise any objections. The J1 driver could initially be taken closed
>source to get things going, then gradually open it up later on once
>the initial type approval has been granted and the product is
>established in the market. I haven't had any feedback from Digium yet,
>I suppose they are still busy trying to fill domestic demand on their
>various new products they have released this year, so J1 isn't on
>their radar yet. Can't really blame them for that.
>
>Anyway, that's the story on J1 support and JATE type approval. All I
>can say at this point is that we are still hopeful that we can get
>something going sooner or later. If anybody has any questions,
>comments or suggestions, they're welcome to drop me an email.
>
>rgds
>benjk
>  
>
J1 is not an ISDN protocol. It is an interface, equivalent to T1 or E1. 
In fact it is *very* similar to T1. There are just a few minor 
differences, designed purely to make it incompatible. They just changed 
some alarm flags and CRC patterns, if I recall correctly. J1 is also 
used in Taiwan, where it is called T1M (T1 modified). Now Taiwan has 
deregulated its telecoms, most new stuff there is standard E1 or T1. I 
have seen references in Cisco documentation to a J1 which runs at 
2.048MHz and has 30 channels, like E1. I don't know if this is an error, 
or if there really is a 30 channel version of J1. The Cisco docs. are 
the only place I have seen this, so I will ignore it for now.

J1 requires hardware support from the framer, but this is no problem. 
The framer chip used on the TE405P and TE410P cards supports J1. The 
framers for the other Digium cards probably do too. The current driver 
software probably doesn't, but the necessary changes should be minor.

All countries require approval for hardware like a T1/E1/J1 card. The EU 
and US have a sort of self-certification waver scheme now, but approvals 
are essentially still required. If you change something re-approval is 
required. The self-certification thing certainly helps there, but 
self-certification might expose you to greater liabilities.

INS-1500 is the Japanese ISDN protocol spec. It is based on the Q.9xx 
specs., like everyone else's ISDN spec. It should not be hard to adapt 
libpri for it. The other ISDN protocols only differ in minor ways, which 
is why a single libpri can handle them all.

I have never been involved in Japanese approvals, but I have been 
involved in various other place's approvals. Japan sounds little 
different from the US or EU just a few years ago. Only in the last 5 
years have things really loosened up. CTI cards, like those made by 
Dialogic card, contain processors for several reasons. One of those used 
to be to simply approvals. It used to be difficult to get anything 
approved if key functions affecting the line were performed by the host 
CPU. The approvals people wanted the approved part to be a well defined 
box, so if you used the host CPU to handle, say, ISDN signalling, you 
had to get the entire computer system approved. In some countries you 
still need to approve the entire system, even when using approved 
Dialogic cards. I was once told I could not supply source code and 
hardware design information to customers for kit I was getting approved 
in the UK. Most of this has loosened up, but approvals requirements have 
not gone away.

If you look at the ISDN4Linux stuff, it is all open source code - it has 
to be to get into the kernel distribution. However, certain revisions of 
that code have been approved for use in the EU. They perform some kind 
of sumcheck operation on the code. If you modify the approved code, it 
will fail the sumcheck test when it runs, and announce that you are 
running an unapproved system. Whether this is acceptable in Japan, I 
have no idea. However, it seems like a fair and reasonable balance 
between the needs of the developers, and the needs of the approvals body 
to control what is approved.

The price you quoted for re-approving a modified version of an approved 
product, $3500, is not bad by international standards. What is more 
important, because it impacts your flexibility, is the level of 
oversight they require. For example, do they require factory inspections 
of places where the cards are made? How minor a substition of components 
on the cards will trigger re-approvals? They are rightly sensitive about 
the last point, as things like the lightning tolerance of the card can 
be greatly affected by substituting components.

Regards,
Steve