SIPって知ってるかい？ [Part 3]

SIPって知ってるかい� ..

60:自律増殖するオブジェクト
06/09/06 22:14:24 34++i37h.net
>>54
> > 呼制御プロトコルを直接拡張する箇所はソフトウェア技術者の手
> > による実装になることは間違いない。
> と、これ...
> > バイナリフォーマットで十分でしょと。
> の関連が全然わからん。ソフトだろうがハードだろうが関係ないと
> 思うし、バイナリフォーマットの必要性の説明になってないし。
テキストフォーマットの必然性も本来無かった、と考える。バイナリ
フォーマットかテキストフォーマットか、確かに些細な論点ではあるが。
SIPプロトコルをバイナリフォーマットでコンパクト化すれば、固定長
化（←できるだけ、ね）が実現できて、暗復号処理が早くなって、対応
デバイスの開発が促進されて、ソフトウェア実装の脆弱性の発生率の
低下に寄与しまっせ？、と。
> > PCやPDAを前提に考えすぎでは？
>
> 感覚が古すぎるんでは？
インターネットバブル時の感覚に侵されているのでは？
> そりゃ自分仕様以外の仕様は大概面倒なもんだよ。嫌なら、ライブ
> ラリ (スタックの方が普通かな) 買ってくるとかとかすればいいん
> じゃね？
短いプロトコルと短いプログラムは無条件に正しい。と思う。
ということで、日本発、SIPプロトコル、ちゃぶ台返しという方向でどうよと。

61:自律増殖するオブジェクト
06/09/06 22:17:02 34++i37h.net
>>56
sometimes, 誤発信しそう。

62:...
06/09/06 23:07:20 .net
>>60
そういえばNTTはH.323を推してたっけなぁ...
組み込みやってる人には同情するけど、テキスト化の流れは止まらんだろうね。
デバッグ時にパッと見で分かるって言う利点は大きいよ。

63:anonymous@ softbank218140119105.bbtec.net
06/09/07 00:58:22 .net
>>58
> そうだよ、その通りだよ。
で、それと HTTP がテキストの方がいいというのかなんか関係あるのか？
"http" って入力してるだけの人が、HTTP がテキストベースのプロトコル
だからこりゃ楽だとか思ってるの？ (w

64:anonymous@ softbank218140119105.bbtec.net
06/09/07 00:59:41 .net
>>59
> インターネットプロトコルの多くは、電文の交換手続きと電文書式を
> 規定している。
多くって…、そもそもプロトコルって電文の交換手順とフォーマットを
規定したもんだろ。
> 中央官庁の書類手続きと書類書式が、政治交渉の進捗を遅らせる要因
> になっていなら、改善を検討しましょう、ということになる。
何を言いたいのかさっぱりわからん。ごまかしモードですか？
> 全く知らんことはないが。
RTP は君の大好きなバイナリフォーマットだから、>>47 の後半で熱く
語ってくれたことって、傍からみてるとちょっと痛いと思う。
> SIPプロトコルをバイナリフォーマットでコンパクト化すれば、
> 固定長化（←できるだけ、ね）が実現できて
まさかテキストでも固定長にできるし、バイナリでも可変長にできる
ことぐらいは知ってるよね？
> インターネットバブル時の感覚に侵されているのでは？
でももう戻れないんだけど、ついて来れないの？
> 短いプロトコルと短いプログラムは無条件に正しい。と思う。
無条件？きちきちに詰め込んだ拡張性のないフォーマットの末路が
Y2K なんだけど、もう忘れたの？

65:近視眼的すぎ
06/09/08 22:44:49 .net
>短いプロトコルと短いプログラムは無条件に正しい。と思う。
この手の知ったかぶりのヴォケ老人って
うちの子会社にすげーいそうなんだよな…
迷惑だから窓際でじっとして何もしないでくれ。

66:自律増殖するオブジェクト
06/09/08 23:06:25 x0f4zlcj.net
あれ？？ドラフトは？
IETFのSIPメーリングリストに出して。貼って。
SIPのバイナリフォーマット化、よろしくｗ
HTTPは、頂戴、貰った、でオワリ。SIPの場合はブン投げてから、
電話切るまで、内部的に状態を保持しつづけにゃナラン。SIPの
バイナリフォーマットのあるエリアをそのままレジスタかRAMに
配置できるフォーマットにすれば状態遷移部の実装も楽になる
でしょ。

> > 中央官庁の書類手続きと書類書式が、政治交渉の進捗を遅ら
> > せる要因になっていなら、改善を検討しましょう、という
> > ことになる。何を言いたいのかさっぱりわからん。ごまかし
> > モードですか？
インターネットプロトコルは電文の交換手順と書式の規定をするもの。
メジャーデビューしたHTTPプロトコルに似せて設計すれば良いという
発想は、「役人が隣の国の役所の書式を真似ると楽だったのでこうし
ました」と言っているようなものではないのかと。
インターネットバブルの影響で、インターネットプロトコル屋は技術
屋としての本質を忘れて技能屋を化しているのではなかろーかと。

67:自律増殖するオブジェクト
06/09/08 23:07:25 x0f4zlcj.net
> > インターネットバブル時の感覚に侵されているのでは？
>
> でももう戻れないんだけど、ついて来れないの？
大丈夫。今なら、日本中のIP電話器が一斉に機能しなくなっても、
そうは困らないと思う。みんな携帯電話持ってるから。
間に合う。SIPプロトコルはは正しい設計方針で修正や。

> > 短いプロトコルと短いプログラムは無条件に正しい。と思う。
>
> 無条件？きちきちに詰め込んだ拡張性のないフォーマットの
> 末路が Y2K なんだけど、もう忘れたの？
SIPプロトコルの合理化をしませう、と云っているだけで、何
もキチキチに切り詰めることはないかと。

68:anonymous@ softbank218140119105.bbtec.net
06/09/09 10:32:51 .net
> あれ？？ドラフトは？
当然あんたが書くんだろ？まともなものが書けるかどうかは知らんが。
> HTTPは、頂戴、貰った、でオワリ。SIPの場合はブン投げてから、
> 電話切るまで、内部的に状態を保持しつづけにゃナラン。
テキストかバイナリかに全然関係ない話だと思うが。
> SIPのバイナリフォーマットのあるエリアをそのままレジスタか
> RAMに配置できるフォーマットにすれば状態遷移部の実装も楽に
> なるでしょ。
状態遷移のプログラム書いたことないだろ。送受信データに状態なん
て入ってないよ。
> 「役人が隣の国の役所の書式を真似ると楽だったのでこうしました」
> と言っているようなものではないのかと。
で、それが政治交渉の進捗の遅れとなんか関係があるのか？相変わら
ず言いたいことはさっぱりわからん。
> インターネットバブルの影響で
FTP も SMTP もインターネットバブル以前からあるテキストベースプロ
トコルですが何か？

69:anonymous@ softbank218140119105.bbtec.net
06/09/09 10:33:33 .net
>> でももう戻れないんだけど、ついて来れないの？
> 大丈夫。今なら、日本中のIP電話器が一斉に機能しなくなっても、
ついて来れないなら、一人で勝手に戻ってれば？
> SIPプロトコルの合理化をしませう、と云っているだけで、
念のために言っとくけど、Y2K 問題起こしたフォーマットだって「当時
としては」最適設計されてたわけ。今、合理的でも将来まで合理的かど
うかは誰にも保証できないから (性能とかに問題なければ) 柔軟性の
あるプロトコルの方が有利だろって言うだけのこと。

70:自律増殖するオブジェクト
06/09/09 12:52:18 Efn8fXQV.net
インターネットプロトコル屋は、電文の交換手順と書式に時間を
使いすぎじゃないのか？その発想というかマインドには、技術開
発屋というより行政書士的なものを感じる。
あれ？この書式と手順はこうあるべきなのですよ？　と、くる。
技術開発の本質的でない箇所に異様に拘る。
　　
>>68
> > あれ？？ドラフトは？
>
> 当然あんたが書くんだろ？まともなものが書けるかどうかは
> 知らんが。
折れなら、その気になれば書けるかもね。
でもまずキミが書いてくれｗ　
インターネットプロトコル屋なんでしょ？
どうせｵﾚｵﾚプロトコルで標準じゃないって言うんでしょ？

71:自律増殖するオブジェクト
06/09/09 12:54:33 Efn8fXQV.net
> > HTTPは、頂戴、貰った、でオワリ。SIPの場合はブン投げてから、
> > 電話切るまで、内部的に状態を保持しつづけにゃナラン。
>
> テキストかバイナリかに全然関係ない話だと思うが。
こういうツッコミセンスに行政書士というか書類役人気質を
感じるのだが。インターネットプロトコル屋でよく勉強して
る人に限ってそう。

> > SIPのバイナリフォーマットのあるエリアをそのままレジスタか
> > RAMに配置できるフォーマットにすれば状態遷移部の実装も楽に
> > なるでしょ。
>
> 状態遷移のプログラム書いたことないだろ。
ほう・・・ｗ
> 送受信データに状態なんて入ってないよ。
状態を表すビット列もプロトコルパケットに入れるべきではｗ
実装も楽になってスタック小さくなるさね。

72:自律増殖するオブジェクト
06/09/09 12:56:02 Efn8fXQV.net
> > インターネットバブルの影響で
>
> FTP も SMTP もインターネットバブル以前からあるテキスト
> ベースプロトコルですが何か？
FTPもSMTPもね、コンピューター同士のデータ交換のための電文交
換手順だからええと思うんよ。
SIPはね、通話機同士、受話器同士の電文交換手順だから、駄目なんよ。
受話器（マイクとスピーカ）はね、人間の耳と口に近づけるものなの。
小さくて身体にフィットしてナンボなのよ。
そんなところに使われるような通信規約仕様に、　
HTTPもどき？？　XML？？　技術屋としてのセンスを疑う。

73:自律増殖するオブジェクト
06/09/09 12:56:39 Efn8fXQV.net
>>69
> >> でももう戻れないんだけど、ついて来れないの？
> > 大丈夫。今なら、日本中のIP電話器が一斉に機能しなくなっても、
>
> ついて来れないなら、一人で勝手に戻ってれば？
何を言ってるんだい？
SIP。トチ狂った技術開発センスで、通話機器の通信規約の標準が
決まっている、と言わざるを得ない。センスを疑う。
そのせいでたくさんのプロジェクトが往生して、IP電話機本体の
開発が遅れてるでしょ？パッとしないでしょ？だから修正しよう
よって、言ってんじゃん。
パッとしたのは独自プロトコルのSkypeだけ。
いやだってみんなSIPって言ってるし、HTTPだってそうだし・・。
と言ってる場合じゃないでしょと。

74:自律増殖するオブジェクト
06/09/09 12:57:15 Efn8fXQV.net
> > SIPプロトコルの合理化をしませう、と云っているだけで、
>
> 念のために言っとくけど、Y2K 問題起こしたフォーマットだって
> 「当時としては」最適設計されてたわけ。今、合理的でも将来
> まで合理的かどうかは誰にも保証できないから (性能とかに問
> 題なければ) 柔軟性のあるプロトコルの方が有利だろって言うだ
> けのこと。
拡張性とか柔軟性とかコンピューターの上のアプリケーション
のことばかり考えちゃ駄目でしょと。
SIPはね、コンピューター同士が繋がるというケースも多いけど、
基本は通話機器間のプロトコルであるべきで、受話器のこと考え
てないでしょと。

75:anonymous@ softbank218140119105.bbtec.net
06/09/09 13:32:17 .net
> 技術開発の本質的でない箇所に異様に拘る。
バイナリに拘ってるのはあんたの方では？
俺は、あんたが優秀なプロトコル提案して広めてくれればすぐにでも乗り換えるよ。
ただ、バイナリにするのが技術的に優秀とはとても思えないし、広まるとも思えな
いけど、これは俺の主観だから、ぜひとも俺の目から鱗を落としてみてくれ。
> でもまずキミが書いてくれｗ　
なんで？
おれは細かいところは別にして大枠は SIP で十分と思ってるよ。
不満がある奴が改善する。それが普通だろ。
> どうせｵﾚｵﾚプロトコルで標準じゃないって言うんでしょ？
新規のプロトコルは全てオレオレで非標準だよ。
そんなあたりまえのことに突っ込んでどうする。
何でそんな心配するのかよくわからん。
俺のレスにそれを感じさせるところがあるなら指摘してみれ。
それとも印象操作のつもり？

76:anonymous@ 202x210x243x26.ap202.ftth.ucom.ne.jp
06/09/09 13:56:34 .net
>何を言いたいのかさっぱりわからん。
いい加減スルーしてやれよ...

77:anonymous@ softbank218140119105.bbtec.net
06/09/09 14:03:03 .net
>> テキストかバイナリかに全然関係ない話だと思うが。
> こういうツッコミセンスに行政書士というか書類役人気質を
そう言われたくなければ、「技術的に」関連を示せばすむだけの話。
> 状態を表すビット列もプロトコルパケットに入れるべきではｗ
> 実装も楽になってスタック小さくなるさね。
例えば受信待ちと言う状態をサーバーに送っても、送ってる最中に
ユーザーが受話器を上げて発信中になるかもしれない。
だから、状態なんかをパケットに入れてもしょうがない。
悪いけど基本中の基本だよ。
> SIPはね、通話機同士、受話器同士の電文交換手順だから、駄目なんよ。
> 受話器（マイクとスピーカ）はね、人間の耳と口に近づけるものなの。
> 小さくて身体にフィットしてナンボなのよ。
> そんなところに使われるような通信規約仕様に、　
> HTTPもどき？？　XML？？　技術屋としてのセンスを疑う。
携帯電話の制御ソフトウェアの規模が 500万行を超える時代に何を言ってるの？
プロトコル関連のソフトなんて 1% にも満たないよ。

78:anonymous@ softbank218140119105.bbtec.net
06/09/09 14:05:36 .net
> そのせいでたくさんのプロジェクトが往生して、IP電話機本体の
> 開発が遅れてるでしょ？パッとしないでしょ？
別にテキストかバイナリ化の問題で遅れてるわけじゃない。
主に相互接続と SIP の機能不足と言うと語弊があるかもしれないけど、日本の
使い方をプロトコルがサポートしきれていないところが多い。
それもここ一年ぐらいでかなり解消されてるし。
Skype はすごいと思う。だからお前もこんなところでグタグタ言ってないでがん
ばってオレオレプロトコルを広めろよ。その気になればドラフト書けるんだろ？
> いやだってみんなSIPって言ってるし、
これは重要なこと、プロトコルは相手があって何ぼのもんだから。
どんな優れたプロトコルでも広まっていないプロトコルは使えない。
> 受話器のこと考えてないでしょと。
いったい受話器ってどんなもんを想定してるんだ？
8bit CPU + 2K ROM + 512B RAM あたりか？(w

79:anonymous@ softbank218140119105.bbtec.net
06/09/09 14:07:24 .net
>>76
まあ、暇だし他に話題もなさげだし、スレタイから大きく外れてるわけ
でもないから大目に見てくれ。
話題あるなら引っ込むけど、なんかある？

80:sage
06/09/09 14:52:53 .net
>79
いや、勘違いオヤヂの模範解答みたいで笑えるんで
暇なら続けてください :-)
バイナリにすれば良くなるっていう発想はある意味新鮮だった
何が解決するんだろう…
# リアルに俺の前に来たら鉄拳制裁必至だけど

81:PG
06/09/09 15:28:01 d/wImiOl.net
このスレというか、この業界が過疎ってたので、
この盛り上がりは素直にうれしい。
もっとやってくれ（笑

82:SF
06/09/09 15:56:27 .net
Sigcompでいいじゃん。

83:自律増殖するオブジェクト
06/09/10 00:51:50 s+kdVTdl.net
電文書式と交換手順は技術的な議論では収束しないときがある。
行政の書類と同じで。
> 例えば受信待ちと言う状態をサーバーに送っても、送ってる最中に
> ユーザーが受話器を上げて発信中になるかもしれない。
> だから、状態なんかをパケットに入れてもしょうがない。
> 悪いけど基本中の基本だよ。
このパケット受信したらこういう状態に遷移してね？っつーフィール
ドなら意味アルやろ？。悪いけど常識中の常識だよ
SIPプロトコルは出来るだけ固定長ヘッダブロックの塊バイナリフォ
ーマット、最後にcrcかチェックサムや。テキストのライン・ストリ
ーム処理じゃ脆弱になりやすくない？

84:自律増殖するオブジェクト
06/09/10 00:55:05 s+kdVTdl.net
秋葉原駅前の自民党総裁候補演説逝った？　折れ、逝ってきたｗ
通話技術の基本は、　「　受　話　器　」。
もう一度いいたい。　「　受　話　器　」。
技術立国たる日本の科学者・技術者としての本質的な問題解決の
視点を忘れ、
- 通話技術を進歩させる受話器とは何か？
- 製品開発を促進する安全で美しくて効率的なパケットフォーマ
ットとシーケンスとは何か？
何故、この問題を解決するために真摯に知恵を絞ろうとしないのか？
海外製の手順と書式に囚われ、技術屋としての本分を忘れ行政書士
と化し、些細の書式(しかも海外製)の正誤に一喜一憂した結果、ど
うなってしまったのか？
ここはだな、襟を正して、決意を新たに、IETFに、SIPプロトコル
のコンパクト化、やりなおしを提案すべきではないのかと。ここは
日本発のμSIPのドラフトを出すべきではないのかと。
SIP1.0、すなわち日本のIP電話の夜明けを気象衛星ひまわりに例え
ると、だ。
衛星軌道に乗る前に爆発炎上だ。
しかもひまわりとおおすみは相互に通信できなかった。
最後にもう一度、言いたい。通話技術の基本は「受話器」。
この原点に立ち返って、IP通話技術の未来を再考すべき時に来て
いるのではないのかと

85:自律増殖するオブジェクト
06/09/10 00:55:51 s+kdVTdl.net
あれ？　ドラフト貼ってくれた？
IETFのSIPのMLに送ってくれた？
届いてないんだけど？
μSip ブロックバイナリ形式コンパクト化でしょ？
役所への届出書類でもそうだけど、本人が自分で書けても作成はまず
行政書士に依頼するのが基本。

86:anonymous@ 219-100-232-237.denkosekka.ne.jp
06/09/10 01:49:23 .net
台湾のヤフオクなんだが、関連機器大杉。
URLﾘﾝｸ(tw.bid.yahoo.com)
ある意味うらやましいな。

87:anonymous@ softbank218140119105.bbtec.net
06/09/10 02:48:47 .net
>>83
> このパケット受信したらこういう状態に遷移してね？っつーフィール
> ドなら意味アルやろ？。
それは、イベント
ある特定のバケットを受信しても遷移する状態は受信側が自分の現在の
状態を見て決める、決してパケットの中身に遷移先の状態を書いてある
わけじゃない。
> 悪いけど常識中の常識だよ
オレオレ常識語られてもね。(w
> SIPプロトコルは出来るだけ固定長ヘッダブロックの塊バイナリフォ
> ーマット、最後にcrcかチェックサムや。テキストのライン・ストリ
> ーム処理じゃ脆弱になりやすくない？
TCP/IP の勉強からやり直すことを薦める。
>>84
技術的な話をしない / できないなら板違いなので、政治板にでも逝って
思う存分語ってください。
>>85
> だからお前もこんなところでグタグタ言ってないでがんばってオレオレ
> プロトコルを広めろよ。
> その気になればドラフト書けるんだろ？

88:anonymous@ p92e769.sitmnt01.ap.so-net.ne.jp
06/09/14 00:00:20 .net
ちょｗ SIPスレなんてあったのｗ
H.323、MGCP、SIP、全部分かる俺がきましたよ。
テキストVSバイナリですか。マイナーなMGCPは置いておくと、、、
テキストのSIPの方が簡単で開発がしやすいです。
テキストのSIPの方がネットと親和性が高いです。
そんだけ。RFC関係者でもない俺にはそれ以上のことは意味がないです。
SIPがバイナリだったら、何かと面倒くさいな。まずアホSEじゃ問題の切り分けができなくなる。
>>87
関係者だね。

89:anonymous@ softbank218140119105.bbtec.net
06/09/14 00:53:56 .net
> SIPがバイナリだったら、何かと面倒くさいな。
> まずアホSEじゃ問題の切り分けができなくなる。
問題の切り分けとかの時はどうせ Ethereal とか使うから
プロトコルがバイナリだろうがテキストだろうがたいして
変わらんよ。

90:01010101
06/09/14 01:02:38 .net
>>89
Etherealで見たってバイナリはバイナリでしょ。

91:@_@
06/09/14 08:05:11 .net
受け取ったパケットの一部を、そのままメモリにのせる方が、
テキストのストリーム処理より、明らかに脆弱だと思うが。。
どうせ、メモリにのせる前にチェックするんだから、大して変わらん。
だったら、通信のチェックとかがしやすい方が良い。

92:91
06/09/14 08:07:14 .net
脆弱だと思う -> 脆弱性をはらみやすいと思う

93:PG
06/09/14 15:22:39 XY6Grotg.net
EtherealからWiresharkに乗り換えた

94:anonymous@ softbank220021184096.bbtec.net
06/09/15 09:39:06 .net
はらみやすい。。。ﾊｧﾊｧ

95:ほげほげ
06/09/15 09:46:15 .net
ざっと読んでみたけどバイナリの利点がわからん
受話器側がしょぼいとバイナリの方がいいかもって程度？

96:PG
06/09/15 10:34:00 bqbXjK5g.net
バイナリだと仕様がガチガチになる
その代わり開発が楽だ

97:sage
06/09/15 11:17:45 .net
だったら H.323 使えと…

98:_____
06/09/15 23:42:12 .net
>>96
バイナリだからガチガチにしなきゃいけないというワケじゃないんだけどね。
融通効くようにするとテキストよりも大変そうだけど。

99:anonymous@ softbank218140119105.bbtec.net
06/09/16 00:53:16 .net
>>90
バイナリでも見えるけど、Ethereal 使う意味が半分以上ないと思うぞ。
>>93
Ethereal が商標登録されてるとは知らんかった。

100:あのねます
06/09/16 10:08:48 .net
もうskypeでいいよ

101:anonymous@ PPPa646.e27.eacc.dti.ne.jp
06/09/17 09:57:39 .net
漏れはG.711でいいよ

102:sage
06/09/17 12:05:19 .net
それじゃしぐなりんぐじゃないYO

103:　
06/09/18 08:19:11 .net
ssipになると中身はバイナリになるんじゃない？

104:0000
06/09/18 23:52:38 .net
>>103
あんた、ズレてますよぉ！

105:sipping
06/09/22 00:44:19 aETY1hnm.net
ｽﾚﾘﾝｸ(newsplus板:175番)
＞原因はN社製鯖(ハード自体はh社製IA鯖)のCPUかメモリ故障。
＞ベンダーで交換したボードを回収して原因を解析中

106:anonymous@ 05001012215829_ma
06/09/22 22:16:45 NRaXKjJ6.net
大分SIPも浸透してきたよね
って最近感ずる

107:anonymouse
06/09/23 01:07:31 7rYfNUWd.net
で、アスタリスクつかってたの？

108:z9hG4bK
06/09/23 04:52:48 MKpamkgT.net
>>105
N社製ってのはNECだよね、たぶん。
>>107
NECがどっかにつくらせたやつじゃねえ？
って、asteriskベースだったりして。

109:総務
06/09/23 09:49:45 .net
Asteriskを導入してる大手企業ってあるのか？
零細企業なら導入しても問題なさそうだが

110:anonymous@ pl045.nas922.p-fukushima.nttpc.ne.jp
06/09/23 09:59:59 .net
>>109
米国ではそこそこ人気あるらしいけどねぇ
*9で保留とか慣れないんだよなぁ

111:anonymous
06/09/23 10:46:22 .net
>>110
asteriskって、保留指示の方法すら自分で設定できないの？？

112:anonymous@ pl1021.nas923.p-fukushima.nttpc.ne.jp
06/09/23 11:02:49 .net
>>111
普通のビジネスホンて保留ボタンがあるでしょ？
VoIPゲートウェイ使って普通の電話機をつないでるから使えないの
ちょっとでも安くしようと思ったら・・・あきらめてる

113:PSTN網最強
06/09/23 11:33:44 .net
URLﾘﾝｸ(voip-info.jp)
Asterisk+snomで出来る

114:Afterisk
06/09/25 17:45:12 .net
ＮＴＴ東のＩＰ電話不具合、ソフトのバグが原因
URLﾘﾝｸ(www.asahi.com)
ＩＰ電話はＳＩＰサーバという専門のサーバをプログラムで制御する発展途上の技術を使う。

115:やれやれ
06/09/26 00:34:10 .net
>>114
さすが朝日、技術音痴丸出しな記事だ。

116:IETF
06/09/26 01:53:13 .net
>>115
いや、まだまだSIPはこれから技術発展して途上だよ。
SIP/SIPPING WGに来ればわかる。

117:ISDN
06/09/26 07:44:26 .net
>>116
日本語の問題をいってるのでは？

118:anonymous
06/09/26 15:42:42 Ru+vivNZ.net
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
> もう一つは各呼制御サーバーを束ねる中継系呼制御サーバーの不具合。
> ビジネスタイプ用の呼制御サーバーで輻輳が頻繁に起こった結果，
> サーバーのメモリー上にデータが溜まり，処理領域を圧迫。
> 中継系呼制御サーバーで所定の性能が発揮できず，輻輳が生じたという。
> 「19日の輻輳でメモリー上にゴミが堆積。
> 19日にはアプリケーションを再起動したが，
> OSを再起動しなかったためゴミが残ったままになってしまった」。
> この結果，20日も輻輳が起こったという。
> そこで，20日午後にOSごと中継系呼制御サーバーの再起動を実施。
> メモリーからゴミが消えたため，現在は正常に稼働しているという。
輻輳でメモリー上にゴミが堆積するSIPサーバ？
サーバを再起動してもゴミが残ったままになるSIPサーバ？

119:119
06/09/27 00:27:36 .net
＞現在は毎秒100コール程度の処理をこなせるようになったという。
性能こんなもんでいいのか??

120:sage
06/09/27 11:14:36 .net
外の世界を知らないから。

121:proxy
06/09/27 17:30:40 D+pDlm1o.net
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
>> 「ひかり電話のビジネス向けの各サーバーで、毎秒10以上の通話が発生すると遅延が生じる状況だった。毎秒100通話まで改善させた」
>> 100通話を想定してシステムを構築したが、「実際の処理能力は10通話の性能だった」という。
毎秒10通話の性能しかでなければ、
いくらひかり電話ユーザ数がまだ少ないからといっても破綻するわな。
しかし、どう下手に作ると毎秒10通話しかさばけないSIPサーバが出来上がるんだろ。

122:名無しさん
06/09/28 01:05:28 4xZinSUB.net
ひかり電話は終わってるね
NTTはSIPの自主開発すらできないってことか
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
＞電話交換機はNTT自身が設計・開発しているから，何かあってもすぐに原因がわかる。
＞ところがIP電話の機器は，メーカーが開発した装置を買ってくるから，
＞ある意味ブラックボックス」（NTTのある幹部）という事情もある。

123:_
06/09/30 11:11:43 MOL5kPqs.net
>>122
ブラックボックス状態も問題だが、
そもそも、いろんなレベルにおけるNTTの設計ミスではないか？
例えば、輻輳なり障害なりバグを踏んだりしたとしても、
東日本全域で崩壊してダウンという運用設計は、素人レベルの設計ミスに見える。
| 加入電話では何日にもわたって，東日本全域でつながりにくくなることはない。
| 加入電話で通話制限をする場合は，障害が起こった電話交換機あての
| 発信だけを制限するという具合に，かなり細かく設定するからである。
| 一方，今回のひかり電話のネットワークでは，
| 技術的には特定の呼制御サーバーだけへの発信を制限するといったことは可能だが，
| そうした設定を施していなかったため，全域で制限せざるを得なかった。

124:_____
06/09/30 11:38:46 .net
>>123
細かくサーバ分けるほどの加入者がまだいないだけだろ。
ロードバランシングぐらいしておいて欲しいけど。

125:anonymous
06/09/30 12:22:19 .net
>>124
現に輻輳から始まるトラブルが起きたわけでその判断はおかしい
どちらにせよ東日本が全滅するような構成をとっていた時点でDQN確定

126:横から失礼
06/09/30 17:48:58 .net
>>125
輻輳の原因はバグだろ？

127:127
06/09/30 18:02:07 .net
>>126
バグがあろうとなかろうと、それと関係なく以下の点はおかしい。
・買ってきたものなのでブラックボックスであるという言い訳
・東日本全体が何日も通信障害に陥るという構成にした設計と運用
・OSレベルでの再起動をしなかったため更に1日解決が延びたなどの対応ミス
もちろん、それに加えてバグが原因があるわけだが、
耐久テストなどでのバグ出しができていなかったわけなので、弁解の余地なしではないか。

128:anonymous@ usr043.bb154-03.udk.im.wakwak.ne.jp
06/10/01 05:18:50 .net
>>127
>東日本全体が何日も通信障害に陥るという構成にした設計
違う違う。
どこからでもかけてこられないように全部をとめたわけさ。
構成の問題じゃない。
どんな構成にしたって同じ。
127は実際、どういう構成にすればいいってわけ？
122をよく読め。フィルタリングする設定をしてなかっただけとある。
単なる怠慢。

129:anonymous
06/10/01 07:01:35 .net
どこからでもかけてこられないように全部をとめる、って、社会的影響が大きすぎる。
障害が出ている部分だけに限定して停止できるべきであろう。明らかに構成の問題。
まともなシステムならば、範囲限定で停止あるいは制限することができる。
フィルタリングする設定をしてなかっただけ、って、恥ずかしい弁明。
まともな対応ならば、フィルタリングする設定をすればいい。
あるいは、それすらできない構成をとっていたならば、設計ミスだろうな。

130:anonymous
06/10/01 11:02:11 .net
>>129
>明らかに構成の問題
構成って意味、間違って使ってるな。
それともCAやサーバーの台数のことか？
どんな構成にしたって同じだろ。
IP電話の構成って知ってるの？

131:グループ外までマッチング探索かけてた
06/10/01 11:15:23 .net
どうでもいいが、「かからない」じゃなくて「かかりにくい」な。落ちてないから。落ちたの西だから。

132:0120
06/10/02 00:33:35 .net
もうBIG-IPでも入れてサーバ台数増やして何とかしろよ。

133:anonymous
06/10/02 10:09:29 .net
BIG-IPなんて初期のころから入れてるよ。サーバーの台数も有り余るほど。

134:sage
06/10/03 11:22:56 .net
> ＩＰ電話、通話分散策を検討　ＮＴＴ東社長
> URLﾘﾝｸ(www.asahi.com)
>
> 「今回の経験を生かしたい。通話が集中しても別のサーバーに通信量を分散させるソフトなどを開発したい」と述べた。
> 改良ソフトの導入時期は、光回線とインターネット技術を使った次世代ネットワークの本格サービスが始まる来年度後半に間に合わせたい考えを示した。

135:00000
06/10/03 23:08:31 .net
>>133
ひかり電話でBIG-IP？
え？ほんと？

136:_
06/10/08 13:32:34 .net
BIG-IPってSIPにも対応しているの？

137:////
06/10/08 21:05:07 .net
>>136
v9からOK。実績は知らん。

138:anonymous@ 150.44.215.220.ap.yournet.ne.jp
06/10/09 10:10:19 b16Lty7T.net
URLﾘﾝｸ(www.f5networks.co.jp)

139:anonymous
06/10/09 23:54:23 .net
いまどきの性能の良いSIPサーバは、どれくらいの量こなせる??

140:anonymous@ itinoe.tsp.ne.jp
06/10/12 09:42:32 .net
宣伝ぽく聞こえるかもしれんが3CXのIP-PBXってどうなのかね？

141:_
06/10/12 19:01:05 .net
>>140
宣伝でもいいので、いろいろ情報書いて。

142:興味本位
06/10/13 00:29:36 .net
>>140
面白いISPだね。バックボーン1.5Mbps？

143:anonymous
06/10/16 00:59:59 .net
>>134
NTTはさっさとENUMを導入しないから。
SIPドメインも分散すればいいのに何故しない。

144:電電
06/10/16 01:17:30 .net
>>135
ひかり電話では使ってないだろ。
今頃、必死になって自前ロードバランサ作ってるでしょ。無駄だねぇ...

145:＿＿
06/10/17 00:17:49 .net
>>144
また何億もかけて無駄な物を作るんか？
BIG-IP買ってくりゃいいのに。

146:_
06/10/17 01:53:03 .net
DNS設定でロード分散すればいいだけなのに

147:lr=
06/10/17 23:32:48 .net
>>146
SIPだよ？さすがにそれじゃまずいでしょ。

148:sage
06/10/18 20:08:25 .net
なんか久々に盛り上がってますね

149:iminasu
06/10/20 00:13:51 .net
今回は誰もSIPit参加してないのか
てゆーか前回の日本開催でどれだけ日本のベンダがいたのやら

150:やれやれ
06/10/24 00:23:34 .net
おい、f5！さっさとNTTにBIG-IP入れろよ。
ひかり電話がまた輻輳だぞ。

151:anonymous
06/10/24 22:14:57 NRTtHQzJ.net
しかし、こんな初歩的ミス犯すかね？
NTT東はバグだと弁明し、NTT西はサーバの能力不足と弁明し、ありえない。
サーバーの能力不足が原因　ＮＴＴ西のＩＰ電話障害
ｽﾚﾘﾝｸ(newsplus板)

152:_
06/10/24 22:33:47 .net
> URLﾘﾝｸ(www.asahi.com)
>
> ＮＴＴ西日本のＩＰ電話サービス「ひかり電話」がつながりにくくなっている問題で、
> かかってきた電話を振り分けるサーバーの処理能力が不足していたと発表した。
>
> 処理能力（１秒間平均１２０件程度）を超える電話がかかり、処理できなくなった。
>
> 処理能力を向上させるため、１１月中旬にサーバー１台を増やす予定だった。
>
> ネットワークサービス部長は「まだ処理できる余裕があると思っていたが甘かった」と陳謝した。

153:anonymous
06/10/25 13:11:23 WJtmr8Y8.net
| ひかり電話にはSIPサーバーが何台ある？
| URLﾘﾝｸ(itpro.nikkeibp.co.jp)
|
| 正解は，「20～30台程度」です。
| NTT東西地域会社のIP電話サービス「ひかり電話」は，
| SIPを使うIP電話サービスです。
| ユーザーの電話番号やIPアドレスなどを管理する「SIPサーバー」を運用して，
| サービスを提供しています。
|
| SIPサーバーは，エリアごとに置かれています。
| このエリアとは，都道府県のことではなく，もっと広い範囲です。
| SIPサーバーの台数は，ユーザー数とともに変わってきますが，
| 現在は全国で20台程度が運用されています。
| たとえば，東日本では，法人向けに3台，
| 一般家庭向けに10台のSIPサーバーがあります。
| ひかり電話のユーザーが電話をかけると，
| まず，自分に最も近いSIPサーバーにSIPのリクエストが届きます。
| そのリクエストが，相手側のSIP サーバーまで渡っていきます。
|
| 東日本といっても，北海道から山梨，長野まで全17都道県があります。
| その中で法人向けが3台しかないので，
| ざっくり言って，6県に1 台しかないという計算になります。
| 少ないように思えますが，IP電話でやり取りされるSIPパケットの量は，
| 音声パケットの量に比べてはるかに少ないので問題ありません。
| SIPパケットは，電話番号などの管理情報をやり取りするだけなので，
| 通話中はほとんど利用しないからです。
| SIPサーバー1台ずつの処理能力を考えれば，
| この程度の数で十分というのがNTTの考えです。

154:anonymous
06/10/25 13:15:04 WJtmr8Y8.net
(つづき) URLﾘﾝｸ(itpro.nikkeibp.co.jp)
| ただ，それだけ1台のカバー範囲が広くなるので，
| どれかのサーバーに何か障害が発生したときに，
| 影響範囲が大きくなってしまいそうです。
| もっとSIPサーバーの数を増やすべきと思いますか？
|
| ここで，一般の固定電話（加入電話）の場合と比べて見ましょう。
| 加入電話では，電話をかけるときにやり取りする電話番号などの
| 制御情報（共通線信号）を，電話交換機同士が「共通線信号網」という
| データ通信ネットワークを使って送っています。
| これはIP電話で言うと，
| SIPのやり取りをするための専用のネットワークに相当します。
| 共通線信号網で使われているSTP（信号中継交換機）と呼ぶ交換機は，
| 全国で20台程度です。たった20台で日本全国をまかなっています。
| つまりSTPの台数はSIPサーバーの台数と同程度です。
| STPはSIPサーバーと同じように，
| 1台でかなり多くの共通線信号を集めて処理しています。
| これでも，十分に障害が発生せずに運用できています。
つまり、処理能力が不足するようなことはありえません。

155:まさか
06/10/25 18:24:04 .net
SIPサーバーの性能検証試験をサボって
STP と同じ台数でいいだろ、っていうことで設計した
なんてことはないだろうな?

156:sage
06/10/25 18:51:08 .net
ＮＴＴ西のＩＰ電話、３日連続で規制実施
URLﾘﾝｸ(headlines.yahoo.co.jp)
規制は３日連続となり、静岡県から沖縄県まで２府２８県の全８３万３０００回線で、
発信の２５％、着信の５０～９５％がつながらない状態となっている。
２３日朝に発生した通信障害は、２４日午後１０時２０分過ぎにいったん復旧。
２５日午前６時までに通信処理サーバーを１台増設したが、
その後、通話が集中して新サーバーに負荷がかかりすぎたとしている。
規制解除のメドは立っていない。

157:_
06/10/25 21:40:56 .net
これ、ほんと？
ｽﾚﾘﾝｸ(newsplus板:201番)
そもそも今回の障害ってのはCASのSIPサーバって大前提があるわけよ。
NTT西日本の光電話ってのはファミリータイプのSIPサーバにはOnDOを使ってる。
ビジネスタイプのはアスタリスク使ってるんだけどまーこっちはいいわ。
んで、SIPサーバってのはBHCAが重要なんだわ。
ファミリータイプの場合は1SIPサーバあたり5.3万世帯のBHCAなんだわ。
これはOnDOの仕様で決まってるのな。
86万世帯に影響ってあるから
86/5.3=16.2
つまり、OnDO16.2万ライセンスが必要なんだけどもNTTがケチってライセンス足りてなかっただけ。
SIPサーバ増やすよりもまずライセンス買えってことなんだわｗ

158:昔Cla(ry
06/10/25 23:43:09 .net
そもそもClass4ってかMGCはあれ？Nと通研のやつじゃなかったっけ…

159:anonymous
06/10/25 23:55:44 .net
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
＞「電話交換機はNTT自身が設計・開発しているから，何かあってもすぐに原因がわかる。
＞ところがIP電話の機器は，メーカーが開発した装置を買ってくるから，
＞ある意味ブラックボックス」（NTTのある幹部）という事情もある。
と、あるので、少なくともNTT自社開発ではないことは確実。

160:.
06/10/26 08:52:14 KVk1u5vC.net
ｽﾚﾘﾝｸ(newsplus板:219番)
>>呼出し用の SIP ソフトウェアは CISCO の Call Manajer 臭いな。
>>保守があって日本で馴染みの深い SIP ソフトウェアと言うとそのくらいしか思い付かん。
>>と仮定すると、サーバーのOSは、Windows 2000 Server か 2003 Server だな。
>>あんな糞 OS をミッションクリティカルなシステムに採用していたとしたら、
>>NTT もダメダメだな。

161:.....
06/10/26 23:32:22 .net
>>160
あまりのアホさに呆れました...

162:_
06/10/27 00:43:04 .net
URLﾘﾝｸ(www.nikkei.co.jp)
＞ＮＴＴ西の森下俊三社長はこの日の記者会見で、
＞通信処理サーバーの処理能力が
＞仕様書の記載内容より低かったことも障害の一因と強調。
いったいどこのSIPサーバを使っているんだろう？

163:_
06/10/27 11:27:27 .net
re-INVITE時にSDP内のConnection-InformationのIPアドレスを変更してRTP送出先を変更させるのって、
どっかのRFCに書いてあったっけ？

164:anonymous
06/10/27 18:46:16 KerfSZsD.net
>>163
During the session, either Alice or Bob may decide to change the characteristics of the media session.
This is accomplished by sending a re-INVITE containing a new media description.

165:NTT
06/10/27 19:02:41 .net
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
NTT西日本は10月27日，10月23～25日の三日間続いたひかり電話の障害について会見を行い，謝罪した。
なお，NTT西日本幹部の責任については「今回の障害は人知を超える範囲だと考えている」（NTT西日本の森下俊三社長）と突っぱねた。
「これだけ大規模のIP電話網をIPv6で設計・運用するのは最先端の取り組み。何が起こるか分からない」（森下社長）と強調。

166:++++
06/10/27 19:40:26 .net
何が起こるかわからないもの売るなよ。

167:バグだらけ
06/10/27 19:50:12 .net
「人知を超える範囲」
これ割と稀代の名言じゃね？

168:anonymous
06/10/27 21:36:22 .net
>>167
社会インフラに対して、「最先端の取り組み。何が起こるか分からない」と言うのも恐ろしい名言だ。

169:sage
06/10/27 22:03:23 .net
＞ URLﾘﾝｸ(itpro.nikkeibp.co.jp)
＞障害の原因は，毎秒140程度の同時通話に耐えられるよう設計していたはずが，
＞実際には毎秒120程度までしか耐えられなかったこと。
＞同時通話が120以上発生した時点で呼処理サーバーがふくそう。
＞次いで中継系呼制御サーバーにも影響が波及した。
しょぼいSIPサーバだな

170:anonymous
06/10/27 23:38:40 .net
URLﾘﾝｸ(headlines.yahoo.co.jp)
>> 「呼処理サーバ」（SIP連携サーバ）に
>> 処理能力を超えるトラフィックが流れ込んだことにより、輻輳が発生したのが原因。
>> この呼処理サーバは、ひかり電話とそれ以外のネットワークとの通信を制御する「中継系呼処理サーバ」（CAサーバ）または、
>> 加入者データを元に通信を制御する「呼制御サーバ」（SIPサーバ）を連携させるものだ。
予測ミス、設計ミス、運用ミスで、必然的に失敗しただけに見える。

171:SIP
06/10/28 00:16:07 F5DesElQ.net
きれいに整理把握して設計できないまま運用しているようにみえる
URLﾘﾝｸ(headlines.yahoo.co.jp)
発着信規制時に一定のトラフィックが加わった時点で
一部の中継系呼制御サーバーと相互接続用関門交換機との間で
想定外の「制御信号の衝突」が異常発生したことが原因。
これまでNTT西日本が経験したことのない事象だった

172:hage
06/10/28 01:35:18 .net
> なお，NTT西日本幹部の責任については「今回の障害は人知を超える範囲だと考えている」（NTT西日本の森下俊三社長）と突っぱねた。
> 「これだけ大規模のIP電話網をIPv6で設計・運用するのは最先端の取り組み。何が起こるか分からない」（森下社長）と強調。
「何が起こるか分からない」代物を固定電話を解約までさせて使わせるなんてキチガイにも程がある。
　普通クビだろ。

173:anonymous@ rocn177-238.rnac.ne.jp
06/10/28 02:36:18 .net
>>172
「何が起こるか分からない」代物を固定電話を解約までさせて使わせるなんてキチガイにも程がある。
これは禿同せざるを得ないな。
NTT東もトラブル中に売り込みに来たけどすげぇ調子の良いこと言ってたよ。
まぁ障害発生してんの知ってて乗り換える俺も相当だと思うけどさ。

174:anonymous
06/10/28 02:37:49 .net
あれ。半角スペースだとフシアナ解除できなくなったのか…。orz

175:anonymous
06/10/28 06:56:16 .net
>>173
しかし、このままでは、PSTNからSIPベースへの置き換えは数年遅れるかもしれんな。
SkypeやP2Pなどインターネット電話が覇権を取るかもしれん。

176:GONZOU-R ◆nno7wradFU
06/10/28 09:40:41 .net
今のIP固定電話の利用体系ってIPto固定って流れが大抵をしめているから
既存固定網からの元々のNo7（ACM、ANM、REL）の遅延と、処理系の負荷が
きつくなって、その影響がIP電話のrａce conditionという形で表現したんだよ。
つまり収容設計のミスだ。
まずはCA/MGW～STP/GSの接続点を増やして信号輻輳を散らせ。
そもそも極端に処理スピードの早いシステム（IP電話）のDB代わりとして処理
スピードの遅いシステム（固定電話）を単純につなげる発想が、電話屋らしくてお粗末。

177:GONZOU-R ◆nno7wradFU
06/10/28 09:54:56 .net
って資料を見る限りやつらもそこまでばかじゃないな。
URLﾘﾝｸ(www.ntt-west.co.jp)

178:anonymous@ 170.61.205.61.west.global.alpha-net.ne.jp
06/10/28 15:19:21 .net
電話というシステム上、2重ぐらいに出来んのかね。
何があるかわからない　ということは、結局見積もりが甘すぎたって事だな。

179:anonymous
06/10/28 15:29:12 .net
>>178
見積もりが甘いにしても、度が過ぎていると思う。
余裕係数とかの取り方がNTTの場合は非常識。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
＞障害の原因は，毎秒140程度の同時通話に耐えられるよう設計していたはずが，
＞実際には毎秒120程度までしか耐えられなかったこと。

180:anonymous？
06/10/28 16:08:47 .net
>>179
おいおい・・・・・・・・だめだめじゃん・・・・・・・・
たとえ140　まともに動いたとしてもすぐ一杯一杯になりそうだが。
IP電話はその性質上、一般家庭ですら複数電話番号持てる　とか歌って、
性能足りませんでした　っていうのはどうなんだろうね。

181:saga
06/10/28 16:12:34 .net
>>143
まともなキャリアなら、ENUMなんか導入するわけがない。
何のメリットもないもの。

182:anonymous
06/10/28 16:18:03 .net
>>181
ENUM導入でメールのように完全分散してしまえば、
今回のような西日本全体で通信障害とかはなくなる。
キャリアによる一極集中型のほうが今回のトラブルを引き起こしやすくて不利なのは明らか。

183:s
06/10/28 18:11:32 .net
全然区切ってないから規制→再起動も一括でやらないといけなくなる。
結局設計できる人間が社内にいないんだろうな。買い物で構築も丸投げ。

184:うほ
06/10/28 23:30:21 rvpgpYLG.net
一極集中の方が管理が楽だし責任の所在も明らかなのだ

185:h
06/10/29 01:36:30 .net
管理のための一極集中と区切るかどうかは全く関係ないけどな。

186:anonymous
06/10/29 17:17:36 fwE+E/oV.net
>>184
ドメインを区切ったほうが責任の所在はさらに明確になるし、
トラブルが起きたときも最小限の範囲に抑えられる。
NTTのような一極集中型のほうが圧倒的に不利なのは明らか。

187:..
06/10/29 21:23:21 .net
>>157
16.2万ライセンスってすごいな。サーバーマシンも１万台は必要じゃね？

188:anonymous@ softbank219001188003.bbtec.net
06/10/30 09:35:00 hgPeGZ6T.net
>>184
「「ＩＰの世界は何が起きるか分からない。人知を超える範囲だ」と述べ、トラブルは避けら
れなかったとの認識を示した。」って、責任逃れの言い訳だよね？

189:へへ
06/10/30 12:35:50 .net
そふとばんくなハゲ電波にも
「顧客対応・管理の世界は何が起きるか分からない。人知を…」
とか言って欲しいな

190:anonymous？
06/10/30 15:09:52 .net
>>188
うん。たとえ言ってることが本当だとしても、今度は、リスク管理を問われる。

191:.
06/10/31 13:19:59 .net
地域IP網も最初の数ヶ月は毎日のようにトラブルあったなぁ
あれも丸投げやっつけ仕事だった

192:h
06/10/31 20:07:22 .net
ただのイソターネットと電話じゃ事の重大性が違いすぎるぜ。

193:_
06/10/31 20:36:34 .net
たしかに、NTT東西それぞれの三日間のトラブルでは、
電話が通じないために商売上の信用を失ったところが多発したのが大きいね。
まだインターネットのトラブルよりも深刻かな。

194:i
06/10/31 21:55:12 .net
メールなんかダイヤルアップで十分用が足りるからな。

195:anonymous
06/11/02 20:06:29 .net
>>114
>ＩＰ電話はＳＩＰサーバという専門のサーバをプログラムで制御する発展途上の技術を使う。
SIPサーバが専門のサーバなのはいいとして、
発展途上の技術というのはいかがなものか？
もう十分に枯れているのではないか？

196:0990
06/11/03 00:56:54 .net
>>195
あの社長、技術系じゃないからな。あんな事を言わせる技術系の部下も酷いが。

197:s
06/11/03 01:26:10 .net
どうせ全部丸投げでしょ。
誰一人実態を把握できていない。

198:anonymous？
06/11/03 01:33:55 .net
ま、部下の話を聞く奴なら、こんなことは言わんだろ

199:.
06/11/03 10:14:07 .net
これって、SIP関係ある？
URLﾘﾝｸ(www.mainichi-msn.co.jp)
ＮＴＴ東日本と西日本は２日、光ファイバー回線を利用したＩＰ電話サービス
「ひかり電話」の通信制御機器のソフトウエアにプログラムミスが見つかったと発表した。
約１２万２０００台の利用者に、ソフトの更新を呼びかけている。
不具合が見つかったのは、通信制御機器の電源が誤って切れた時に自動的に再起動させるソフト。
プログラムミスが原因で、このソフトを導入すると、電話の発着信やインターネット接続ができなくなる恐れがあるという。
ソフトは両社のホームページで無料で更新できる。

200:あ
06/11/03 13:46:32 .net
全く関係ない

201:anonymous？
06/11/03 14:01:19 .net
ゲートウェアに使ってたら関係あるんじゃマイカ？

202:anonymous@ itinoe.tsp.ne.jp
06/11/04 19:48:20 .net
このスレで「関係ない」というのはSIPのプロトコルと関係ないということ
機器を使っているとかお客に入れているというのなら別板の話だよな。

ところで「ゲートウェア」ってナニ？「ゲートウェイ」なら知っているが

203:-
06/11/05 05:21:23 .net
ゲートウェイに搭載してるファームウェアだからゲートウェア

204:sage
06/11/08 00:32:11 .net
久しぶりに訪問したらなんかすごい盛り上がってるねー
>>157
ワロタ。座布団３枚

205:anonymous
06/11/08 00:39:23 xzCxDndP.net
ローゼンバーグおじさん

206:anonymous
06/11/15 05:18:54 .net
| URLﾘﾝｸ(www.asahi.com)
| システムに余力を持たせるため、３種類のサーバー計１５台を増やす。
| 装置の性能を検証し、ＩＰ技術者の育成も強化する。
やっぱり交換機技術者ばかりでIP/SIP技術者はいないのか

207:anonymous
06/11/15 14:37:31 .net
早くノウハウがたまるといいんだけど。でも、まぁ、この手はなぁ

208:anonymous
06/11/15 15:41:39 .net
>>207
NTTからRFC4715 (ISDN Subaddress Encoding Type for tel URI) 出たぜ

次ページ