先般のお約束通り現行のAnnexCのITU-T非準拠の箇所についての情報の開示です。原文は英文であり、メーカー名は特定できないようにX社とY社にしました。チップのバージョン名は「A」と「B」にしました。
ITU-Tの規格に合わせて作ると以下のポイントで互換性を持たないという内容です。規格通り作るとつながらないから最初から話にならないわけです。

これだけ規格品外製品をばら撒いてどう決着つけるかというのが
今後の大きな問題です。昔、ICの足の長さが国際規格で決まっていたがそれとは別の規格外の長さで大量に製造したメーカーの長さに
あわせてしまったということもあるようです。国際規格（ITU−T)を
日本風に変えてしまうということが取りうる方法かも。

そうすると一体、ITU-Tとは何なのか？という疑問。ITU-T準拠を基本としてきたTTCとはなーに？ということか。
何故国際規格準拠と日本風AnnexCが接続できないかご一読ください。




Maker “x” G.lite and G.dmt Annex C modem non-compliances:

Observation on version “A” and “B”.

1. X’ CO deliberately fails at the beginning of handshake messaging (probably when they enter HSTU-C initial transaction state) and restarts expecting the RT will do the same. The second link follows more or less the G.994.1 standard (see the item below).
If RT doesn’t restart immediately, then X’ CO fails again at the same place.
2. In handshake messaging X’ modems (CO and RT) send both R-ACK1 and R-ACK2 bits set to zero (although G.994.1 recommendation requires that at least one of those bits is set to one). Also, their RT starts immediately with the MR message without prior exchange of CLR - CL pair.
3. During the first messaging (R-RATES1 to R-CRC2) X’ RT sends REVERB signal during NEXT symbols (according to spec, it should be quiet during those symbols). Note that this is not crucial since on the CO we decode the messages only in FEXT frames.
4. The CRC calculation for RATES1 message (C-CRC1 and R-CRC1) includes the 4-byte prefix as well as the message itself. (fixed in G.DMT)
5. X’ R-SEGUE1 is 16 frames long (although the maximum length specified in G.lite is 14 frames), and their CO expects such length, otherwise it fails.
6. X’ code does not reset the pseudo-random sequence pointer on first MEDLEY frame so their first MEDLEY symbol is NOT equal to REVERB (i.e., their MEDLEY is shifted by one frame).
7. In FEXT Bitmap mode, X’ modems do not increment the pseudo-random sequence pointer during NEXT MEDLEY symbols when nothing is transmitted.
8. Variable length REVERBs are not supported (X’ CO and RT both require the minimum REVERB lengths (n = 0), otherwise they fail).
9. C-CRC5 is calculated only on the NEXT B&G message (i.e., on the second half of the C-B&G message).
10. X’ RT begins R-B&G message with FEXT bits and gains for tone 32, and the complete transmitted R-B&G table is thus shifted by 31 16-bit words. Also, their modems calculate upstream CRC5 only on 96 FEXT (tones 32-127) and 96 NEXT concatenated B&G table entries! (fixed in G.DMT)
11. A double train: X’ DMT RT drops the link immediately after reception of C-CRC5, and then CO has to restart the link immediately, and the second link becomes stable.

X’ G.dmt Annex C DSLAM specific issues:

1. It requires double training to achieve the good data rate. The first training has to be G.lite and then CPE gets the good data rate from the second G.dmt training. The first link can be forced to be G.lite by forcing G.lite mode at CPE or by sending X’s Vendor ID during the G.hs.

Y’s G.dmt Annex C modem non-compliances:

1. Y’s CO doesn’t transmit the PILOT tone during the NEXT frame in FBM mode.
2. Y’s CPE expects C_QUIET5 instead of C_PILOT3 white CPE does echo canceller training, while it doesn’t send R_ACK1. If CO transmits C_PILOT3, then the downstream data rate becomes very low.


小林博昭

> 先般のお約束通り現行のAnnexCのITU-T非準拠の箇所についての情報の開示です。

初めて書き込みます。
日本国内の掲示板に書き込むのにあえて英文で書き込んだ意図は何でしょうか？
ソースが海外であるためそのまま持ってきたってことですか？
以下の非準拠を指摘しているのがどこの誰なのかもわからないので私には
この情報をもって何かを判断することはできません。
せめてこの情報をもっと公の場で公表するなどして、きちんと決着をつける
ことが必要だと思います。

けいさん

おっしゃるとおりです。日本語の内容についての発表は正確な翻訳を
行ってからしたいと思います。数日の確認の時間が必要です。
やはり、この内容については公の場できちんと決着をつけるということは必要だと思います。AnnexCの日本風風味に醤油味、味噌味など唐辛子をかけて好みでどうぞなどというわけにはいかないでしょうから。
このITU-Tの標準外についてはチップメーカーも当事者になりたがらないのは外れていてもチップが売れればよいというビジネス上の思惑が
あり、敢えて問題にしたくないという態度にもあるのです。編集長の
言にもあったようにあるチップメーカーからのタレコミがあったということをおっしゃっていましたが、その意図するところはそのような仕様のチップでも購入して使ってくれればそれでよしとする態度が見え見えです。
ITU-Tの標準という面からすれば、標準は斯くあるべしで罰則はないわけですからメーカーがどのように作ろうが勝手な面もあります。監督官庁がその事実を知れば指導ぐらいはあるでしょうが製造中止にはならないでしょう。
数が少なければ取るに足らない話が膨大な数になったとき、どう決着をつけるかということで大きな問題です。
公的な機関であるNTTが国際調達によりAnnexCの装置を調達するとき、ITU-TのAnnexC規格に合致しない製品であること、などと記述できないでしょう、また過去に購入した機材と互換性のない由緒正しい、正式なAnnexCを買うと機材の展開に困るでしょうから。
利害の相反するTTCで議論することは必要でしょう。私はTTCのメンバーでもなんでもないのでTTCメンバーであるメーカーにこの話を持ち出させたいと思います。監督官庁である総務省に持っていっても頭を抱える問題で、TTCで議論してくれ、ぐらいではないでしょうか？





> > 先般のお約束通り現行のAnnexCのITU-T非準拠の箇所についての情報の開示です。
>
> 初めて書き込みます。
> 日本国内の掲示板に書き込むのにあえて英文で書き込んだ意図は何でしょうか？
> ソースが海外であるためそのまま持ってきたってことですか？
> 以下の非準拠を指摘しているのがどこの誰なのかもわからないので私には
> この情報をもって何かを判断することはできません。
> せめてこの情報をもっと公の場で公表するなどして、きちんと決着をつける
> ことが必要だと思います。

私が期待をしたオープンな議論とは方向性が違っていて残念に思います。
せめてSonetのHPで意見を表明するとか、よりフォーマルな手法でお願い致します。
でないと結局、それぞれの利害だけで意見を出しているに過ぎないと思われてしまいます。
Annex A陣営もY!BBが加わって、今では決してマイナーな存在ではないと思います。
工夫次第でより社会的な効果を期待出来る意見発表の場があるのではないでしょうか？

忘れて頂きたきたくないのは利用者の存在です。

そういえば東京めたりっく通信でも住友電工かNECのAnnexCモデムを一部利用していました。まだご利用していただいているお客様も居られるかもしれませんが、あの当時は１．５Mbps の製品だけですから実際にはもう市場にはないかもしれません。すでにヤフーBBでAnnexCのサービスを受けておられるお客様はいらっしゃるのでしょうか？CO装置もAnnexCのクロックを取れるようになっているのでAnnexCで動かすこともできます。端末は両方のソフトが乗っているかどうかはよくしりません。

いずれにしてもAnnexCは基本はISDNのピンポンと逆の動きをしますから送る、受けるの動作を繰り返すわけで、この点からすると常時送受信をしているAnnexAの方が論理的には単位時間当たり2倍の情報を送ることが出来るわけです。

最近のチップはAnnexAもCも動くようになってきていますから、このあたりの問題はすくないと思います。

小林博昭