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

1 ：2006/02/01 〜 最終レス ：2013/05/30

SIPってプロトコル知ってるかい？
☆インターネット上において指定した相手とコンタクトする機能
☆様々なメディア・アプリにて相手とセッションを確立する機能
☆メッセージおよび種々のイベントの非同期通知を実現する機能
などのインターネット上で不可欠な基本機能の枠組みを提供するSIPについて
そのプロトコルや相互接続ならびに各アプリやシステムの動向について語りましょう
過去スレ
SIPって知ってるかい？
http://pc.2ch.net/test/read.cgi/network/988207855/
SIPって知ってるかい？ [Part 2]
http://pc8.2ch.net/test/read.cgi/network/1059941532/

2 ：

http://www.ietf.org/
http://www.ietf.org/rfc/rfc3261.txt
http://www.softfront.co.jp/tech/sip_rfc_draft.html
http://www.softfront.co.jp/tech/ietfdoc/trans/rfc3261j.txt
http://www.sipit.net/
http://www.ciaj.or.jp/hats/
http://www.nic.ad.jp/ja/voip-sip-tf/
http://www.telesa.or.jp/committee/2005/voip/index.htm

3 ：

>>1 乙
初代スレのNo3を読むと実に感慨深いものがある。
しかしSIPそのものを語るフェーズはもう終わったかな。

4 ：

しまった。。。あららー

5 ：

拡張機能とかについても語っていこうぜ

6 ：

http://www.nic.ad.jp/en/sipit18/

7 ：

>>6
高杉、ディスカウントプリーズ

8 ：

>>6
NTTグループのロゴがうざい。1つにまとめろよ。
あと、日本語の案内ページはないのかい？

9 ：

もしかしてSIPit関係者ここみてるのか？
日本語情報ページが追加されてた。乙

10 ：

で、みんな参加するの？
参加したことあるヤシ、どんな感じなのか詳細きぼんぬ

11 ：

閑古鳥ないてるな

12 ：

・ 参加費用 一人当たり 430ドル
(4日分のランチ・ドリンク費用・ソーシャルイベントへの参加費用含む)

13 ：

VONに行くやついる？

14 ：

あげ

15 ：

RFC2543が存在した事が汚点であるプロトコル

16 ：

思ったより日本企業の参加数すくねえな＞SIPit
国内の相互接続で手いっぱいか？

17 ：

正直、
普通に接続試験やったって問題はもう出ないだろ

18 ：

VoIPなんかNTT経由で繋げばいいんだから相互接続なんか気にしなくてもいい。
自分の所で使う物は自分で検証するし。

19 ：

はじまったな
参加してるヤシいたらレポートお願い。

20 ：

http://itpro.nikkeibp.co.jp/article/NEWS/20060419/235722/

21 ：

参加してない漏れが言うのもなんだが、日本で参加した意味あったのか？

22 ：

SIP Forumのサイト、ハッキングされたのか？w

23 ：

　

24 ：

SIP技術者って全然いないのかねえ
足りない足りないって騒がれてるが
でもSIP「だけ」じゃ結局何もできないんだよな。

25 ：

SIP技術者って言うより、
自分のところの製品の技術者だから。。

26 ：

HATSの試験か、ちょっと気になるな

27 ：

age

28 ：

アズジェント製品、サービスの不買運動開始！この会社のSIP製品は正直
使い物にならん。

29 ：

アズアズは何が駄目駄目？

30 ：

過疎ってるな
なにかネタないのかあげ

31 ：

ネタ投下
SIPのカンファレンス機能で、
PolycomTV会議を巻取り鯛
互換性についてご意見を…

32 ：

SIPってさ、テキストプロトコルでしょ。
バイナリフォーマットの方が組み込みやすいし、受話器作りやすいと
思うのだが。
他のインターネット・プロトコルとの親和性というのも何だかな、と。
「パソコンで電話」なんて、そもそも不便だと思うし。

33 ：

つ　 Sigcomp

34 ：

マイクロソフトのエンジニアが考えたプロトコルなんて所詮そんなもん

35 ：

>>32
あなたは相当古い人間ですね。

36 ：

>>35
いや、んな古いってことないと思うけど・・・（タブン）。
HTTPはパソコンを使う、おじさん、おばさん、おねーさんたち
だって意識することもあるかもしれない。
技術者でなくても、ＨＴＭＬを手で書く人だっているし。
ＷＥＢ系のグラフィックアーチストさんだっているし。
でもね、ＳＩＰは電話器、通信機器、向けのプロトコルでしょ？
そのプロトコルのベース部分をテキストベースで設計して何の
メリットがあると思ったのやら・・・。

37 ：

HTTP と HTML の区別もついてないのか…。

38 ：

>>37
馬鹿にしぃないでぇよー　そっちのせいよぉー♪
さて。
あのねのね。
HTTPで運ぶHTMLはエンドユーザーが弄るでしょ。だからパソコ
ン・アプリケーションの創意の余地は多いと思う。で、あるか
らしてHTTPプロトコルがテキストベースであることのメリット
は大きいと思う。
一方SIPが運搬するのは信号処理のパラメータと通話制御の手順情報。
だから、テキストベースで設計したところで、メリットの恩恵を受け
る対象は技術屋の弄ってる機器やソフトウェア、ということになる。
技術屋にはプロトコルフォーマットはバイナリベースの方が扱いや
すい。組み込みソフトウェアのスタックサイズもその方が助かる。

39 ：

要は、SIP なんて一般人が使わんからバイナリでいいじゃん
とか思ってんだろ。
だったら、HTTP だって扱う奴は Web サーバーと Web ブラ
ウザ作ってる奴ぐらで一般人はあまり関係ないぞ。(まあ、
CGI 書いてる奴は多少は意識するだろうけど、そいつらを
一般人と言うかは微妙だな。)
そこを HTML がどうたら言うから >>37 みたいに書いてるわけ。
SIP のデータ量なんか高が知れてるし、インターネットのプロ
トコルはテキストベースの奴が多いから自然とテキストベース
になったんだろ。どうしても不満なら、RFC 書いて提案するな
り、Skype みたいに自分プロトコルを広めるなりすればいいん
じゃね？
そもそも、バイナリフォーマットだろうがテキストフォーマッ
トだろうが送受信ライブラリ作る時に多少違うだけで、あと
はたいして変わらん (ようにライブラリを作るだろうし、
仕事ならライブラリ買ってくることも多いし。)
> 組み込みソフトウェアのスタックサイズもその方が助かる。
今時ネットワークサポートしててそこまでメモリ要件が厳しい
組み込み機器なんかあんまりないだろ。

40 ：

> 要は、SIP なんて一般人が使わんからバイナリでいいじゃんとか思ってんだろ。
つか、バイナリで設計すべきじゃん？と思う。
> だったら、HTTP だって扱う奴は Web サーバーと Web ブラ ウザ作ってる奴ぐらで一般人は
> あまり関係ないぞ。(まあ、 CGI 書いてる奴は多少は意識するだろうけど、そいつらを
> 一般人と言うかは微妙だな。)
HTTPの場合はさ、運搬するHTML（とそれに付随するCGIやJavaScript）に、親しんで取り組んで
くれるアーティストやデザイナが盛り上げてくれてる。SIPにはそんな余地はないと思うわけ。
技術者が「IP電話器という製品」や「無線IP PBXという製品」を作りやすい設計にすべきでは
ないかと思うわけ。
> そもそも、バイナリフォーマットだろうがテキストフォーマットだろうが送受信ライブラリ
> 作る時に多少違うだけで、あと はたいして変わらん (ようにライブラリを作るだろうし、
> 仕事ならライブラリ買ってくることも多いし。)
> > 組み込みソフトウェアのスタックサイズもその方が助かる。
> 今時ネットワークサポートしててそこまでメモリ要件が厳しい 組み込み機器なんかあんまり
> ないだろ。
つかSIPに対応しようとするとそうなっちゃうんだって。
SIPのBODYにXML、という方向で盛り上がり出して、「これが標準です」と、きている。
仮に、標準仕様に準拠したIP電話器を、新規参入で作ろうとしたとき、ソフトウェア
の比重が異様に高く感じると思う。IP電話技術の通信プロトコルをHTTPに似せて設計
したのはどうだったかと思うけどな。

41 ：

問題なのはXMLじゃないの？
SIPだけならバイナリでもテキストでもそれほど大した差はないと思うけど。

42 ：

テキストでもバイナリでも大差ないとか、ふざけんな
どれだけテキストのせいで苦労してると思ってるんだよっと言いたいです。
SIPは現状IP電話という枠でしか使われてないかもしれないけれど
多くの拡張をしたいためにテキストベースなのだと思うのです。
バイナリで良いじゃんとか、電話だけ作ってろと言いたいです。

43 ：

君たちは余計なことを考えずに H.323 使っててくれよ

44 ：

>>40
> HTTPの場合はさ、運搬するHTML（とそれに付随するCGIやJavaScript）
> に、親しんで取り組んでくれるアーティストやデザイナが盛り上げて
> くれてる。
だ・か・ら、それは HTML だけの話で HTTP とは関係ないだろ。
FTP で、バイナリ転送しかしないから制御プロトコルもバイナリにした
方がいいとか言うのか？
>>42 が書いてる通りバイナリだと往々にして拡張性の低い設計をする
ことが多い。どうしても詰め込もうとする意識が働くからね。1980 年
代に IPv6 発表してたら、普通の技術者は何てもったいないことをする
んだ って言うと思う。
通信速度が低くプロセサの能力も低い時代にはバイナリでやるしかない
ことも多かったが、動画データがバンバン流れてリアルタイムで処理し
ている昨今わざわざバイナリにする意味がほとんどない。
テキストのせいで苦労しているという >>42 のところはなんか設計が
間違ってるか、相当厳しい要件でもの作りしてるんだろうな。

45 ：

>>42
この人は結局何が言いたいの？
前半と後半で言ってることが正反対。

46 ：

>>45
テキストプロトコル反対派なんでしょ。
その是非は別にして、一応言ってることは首尾一貫してると思うが。

47 ：

>>44
> HTTPの場合はさ、運搬するHTML（とそれに付随するCGIやJavaScript）
> に、親しんで取り組んでくれるアーティストやデザイナが盛り上げて
> くれてる。
>> だ・か・ら、それは HTML だけの話で HTTP とは関係ないだろ。

HTTPプロトコルを意識するのは技術者だけではないでしょ？
という指摘をしてるだけ。
ま・さ・か、インターネット屋さんは、成功したHTTPプロトコル
に似せればSIPもメジャーデビューだぜ？　という勘違いをして
はいないだろうねと。
> > FTP で、バイナリ転送しかしないから制御プロトコルも
> > バイナリにした方がいいとか言うのか？
SIPは通話技術を支えるプロトコル。
人と人との通話は、受話器にはじまり受話器に終わる。
将来にわたって、通話技術は、受話器すなわちマイクとスピーカと
交換機ありきであり、特に受話器が最も応用と拡張が検討されるべ
き箇所。通話を実現する機能の標準は、より低コストに、より安全
に実現できるようにケアされるべきで、だったらバイナリフォーマ
ットの方が理に適うでしょと。

48 ：

>>42 が書いてる通りバイナリだと往々にして拡張性の低い設計をする
> ことが多い。どうしても詰め込もうとする意識が働くからね。
ＰＣ上のソフトウェアやインターネットサービスで、アプリケー
ションが開発される余地が多いにあろうと、呼制御プロトコルを
直接拡張する箇所はソフトウェア技術者の手による実装になるこ
とは間違いない。バイナリフォーマットで十分でしょと。
> 通信速度が低くプロセサの能力も低い時代にはバイナリでやるし
> かない ことも多かったが、動画データがバンバン流れてリアル
> タイムで処理し ている昨今わざわざバイナリにする意味がほと
> んどない。
PCやPDAを前提に考えすぎでは？
> テキストのせいで苦労しているという >>42 のところはなんか
> 設計が 間違ってるか、相当厳しい要件でもの作りしてるんだろ
> うな。
機能は最短で実現したいだろうから、標準仕様という理由だけの
工数増は面倒に思うとか。

49 ：

UPnPよりマシ。

50 ：

テキストってバイナリのサブセットだって知ってた?

51 ：

>>45
頑張ってテキストベースにしたんだから、バイナリでも大差ないとかいうなと言いたいんじゃないの?

52 ：

>>50
text ∈ binary　て言いたいわけ？
SIPプロトコルのコンパクト化プロジェクト提案しに逝こうぜ。
日本発、ちゃぶ台返し。

53 ：

>>47
> HTTPプロトコルを意識するのは技術者だけではないでしょ？
技術屋だけだろ。
まさか普通の人もブラウザに http://〜 とか入力するから
"http" を意識してるとか言い出すわけじゃないだろうな。
> 成功したHTTPプロトコルに似せればSIPもメジャーデビューだぜ？
> という勘違いをしてはいないだろうねと。
別に勘違いじゃないだろ。既に HTTP 知ってる「技術屋」はいっぱ
いいるし、ライブラリだっていっぱいある。一から作るぐらいなら
似たようなもの手直しした方が楽だから、普及しやすいと思うのは
ごく普通だと思うけど。
> 人と人との通話は 〜 受話器すなわちマイクとスピーカと交換機
> ありきであり
まさかと思うが RTP を知らないとか言うんじゃないよね？

54 ：

>>48
これ...
> 呼制御プロトコルを直接拡張する箇所はソフトウェア技術者の手
> による実装になることは間違いない。
と、これ...
> バイナリフォーマットで十分でしょと。
の関連が全然わからん。ソフトだろうがハードだろうが関係ないと
思うし、バイナリフォーマットの必要性の説明になってないし。
> PCやPDAを前提に考えすぎでは？
感覚が古すぎるんでは？
> 機能は最短で実現したいだろうから、標準仕様という理由だけの
> 工数増は面倒に思うとか。
そりゃ自分仕様以外の仕様は大概面倒なもんだよ。嫌なら、ライブ
ラリ (スタックの方が普通かな) 買ってくるとかとかすればいいん
じゃね？

55 ：

情報処理試験(テクニカルエンジニア(ネットワーク))の午後Iの常連になったな

56 ：

日本語音声で、発呼出来るようにしよう。

57 ：

>>56
だいぶ前の携帯で音声認識で電話かけられる奴あったような気がする。
すぐ廃れたみたいだけど。

58 ：

>>53
> > HTTPプロトコルを意識するのは技術者だけではないでしょ？
> 技術屋だけだろ。
>
> まさか普通の人もブラウザに http://〜 とか入力するから
> "http" を意識してるとか言い出すわけじゃないだろうな。
そうだよ、その通りだよ。
ＷＥＢデザイナもＣＧＩでパラメータ送信したい人はある程度は
ＨＴＴＰのことを調べてるだろうね。

59 ：

>>53
> > 成功したHTTPプロトコルに似せればSIPもメジャーデビューだぜ？
> > という勘違いをしてはいないだろうねと。
>
> 別に勘違いじゃないだろ。既に HTTP 知ってる「技術屋」はいっぱ
> いいるし、ライブラリだっていっぱいある。一から作るぐらいなら
> 似たようなもの手直しした方が楽だから、普及しやすいと思うのは
> ごく普通だと思うけど。
インターネットプロトコルの多くは、電文の交換手続きと電文書式を
規定している。中央官庁の書類手続きと書類書式が、政治交渉の進捗
を遅らせる要因になっていなら、改善を検討しましょう、ということ
になる。
> > 人と人との通話は 〜 受話器すなわちマイクとスピーカと交換機
> > ありきであり
人間は、音を発して、音を聞く、そうして意思疎通を行う生き物であり、
人間同士の遠隔間意思疎通を助ける技術の最も再重要要素は、音を発す
る事、音を聞く事、この二つを助力する技術にあると考える。電文の交
換手続きと電文形式は、技術開発を容易にすべく、簡便であるべき。

> まさかと思うが RTP を知らないとか言うんじゃないよね？
全く知らんことはないが。SIPの呼制御の基本部分はRTPのようなフォー
マットにしたほうがええんちゃうの？出来るだけ固定長にできるように
設計したほうがええんちゃうの？
ま、そういうことで、SIPプロトコルのコンパクト化プロジェクト提案と
逝きますか。日本発、ちゃぶ台返し。だりゃーっ！

60 ：

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

61 ：

>>56
sometimes, 誤発信しそう。

62 ：

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

63 ：

>>58
> そうだよ、その通りだよ。
で、それと HTTP がテキストの方がいいというのかなんか関係あるのか？
"http" って入力してるだけの人が、HTTP がテキストベースのプロトコル
だからこりゃ楽だとか思ってるの？ (w

64 ：

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

65 ：

>短いプロトコルと短いプログラムは無条件に正しい。と思う。
この手の知ったかぶりのヴォケ老人って
うちの子会社にすげーいそうなんだよな…
迷惑だから窓際でじっとして何もしないでくれ。

66 ：

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

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

67 ：

> > インターネットバブル時の感覚に侵されているのでは？
>
> でももう戻れないんだけど、ついて来れないの？
大丈夫。今なら、日本中のIP電話器が一斉に機能しなくなっても、
そうは困らないと思う。みんな携帯電話持ってるから。
間に合う。SIPプロトコルはは正しい設計方針で修正や。

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

68 ：

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

69 ：

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

70 ：

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

71 ：

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

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

72 ：

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

73 ：

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

74 ：

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

75 ：

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

76 ：

>何を言いたいのかさっぱりわからん。
いい加減スルーしてやれよ...

77 ：

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

78 ：

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

79 ：

>>76
まあ、暇だし他に話題もなさげだし、スレタイから大きく外れてるわけ
でもないから大目に見てくれ。
話題あるなら引っ込むけど、なんかある？

80 ：

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

81 ：

このスレというか、この業界が過疎ってたので、
この盛り上がりは素直にうれしい。
もっとやってくれ（笑

82 ：

Sigcompでいいじゃん。

83 ：

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

84 ：

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

85 ：

あれ？　ドラフト貼ってくれた？
IETFのSIPのMLに送ってくれた？
届いてないんだけど？
μSip ブロックバイナリ形式コンパクト化でしょ？
役所への届出書類でもそうだけど、本人が自分で書けても作成はまず
行政書士に依頼するのが基本。

86 ：

台湾のヤフオクなんだが、関連機器大杉。
http://tw.bid.yahoo.com/tw/2092097076-category-leaf.html?.r=1157820480
ある意味うらやましいな。

87 ：

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

88 ：

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

89 ：

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

90 ：

>>89
Etherealで見たってバイナリはバイナリでしょ。

91 ：

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

92 ：

脆弱だと思う -> 脆弱性をはらみやすいと思う

93 ：

EtherealからWiresharkに乗り換えた

94 ：

はらみやすい。。。ﾊｧﾊｧ

95 ：

ざっと読んでみたけどバイナリの利点がわからん
受話器側がしょぼいとバイナリの方がいいかもって程度？

96 ：

バイナリだと仕様がガチガチになる
その代わり開発が楽だ

97 ：

だったら H.323 使えと…

98 ：

>>96
バイナリだからガチガチにしなきゃいけないというワケじゃないんだけどね。
融通効くようにするとテキストよりも大変そうだけど。

99 ：

>>90
バイナリでも見えるけど、Ethereal 使う意味が半分以上ないと思うぞ。
>>93
Ethereal が商標登録されてるとは知らんかった。

100 ：

もうskypeでいいよ

101 ：

漏れはG.711でいいよ

102 ：

それじゃ しぐなりんぐ じゃないYO

103 ：

ssipになると中身はバイナリになるんじゃない？

104 ：

>>103
あんた、ズレてますよぉ！

105 ：

http://news19.2ch.net/test/read.cgi/newsplus/1158759425/175
＞原因はN社製鯖(ハード自体はh社製IA鯖)のCPUかメモリ故障。
＞ベンダーで交換したボードを回収して原因を解析中

106 ：

大分SIPも浸透してきたよね
って最近感ずる

107 ：

で、アスタリスクつかってたの？

108 ：

>>105
N社製ってのはNECだよね、たぶん。
>>107
NECがどっかにつくらせたやつじゃねえ？
って、asteriskベースだったりして。

109 ：

Asteriskを導入してる大手企業ってあるのか？
零細企業なら導入しても問題なさそうだが

110 ：

>>109
米国ではそこそこ人気あるらしいけどねぇ
*9で保留とか慣れないんだよなぁ

111 ：

>>110
asteriskって、保留指示の方法すら自分で設定できないの？？

112 ：

>>111
普通のビジネスホンて保留ボタンがあるでしょ？
VoIPゲートウェイ使って普通の電話機をつないでるから使えないの
ちょっとでも安くしようと思ったら・・・あきらめてる

113 ：

http://voip-info.jp/index.php?%A3%B1%C8%D6%A4%CB%C5%C5%CF%C3
Asterisk+snomで出来る

114 ：

ＮＴＴ東のＩＰ電話不具合、ソフトのバグが原因
http://www.asahi.com/digital/nikkanko/NKK200609250008.html
ＩＰ電話はＳＩＰサーバという専門のサーバをプログラムで制御する発展途上の技術を使う。

115 ：

>>114
さすが朝日、技術音痴丸出しな記事だ。

116 ：

>>115
いや、まだまだSIPはこれから技術発展して途上だよ。
SIP/SIPPING WGに来ればわかる。

117 ：

>>116
日本語の問題をいってるのでは？

118 ：

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

119 ：

＞現在は毎秒100コール程度の処理をこなせるようになったという。
性能こんなもんでいいのか??

120 ：

外の世界を知らないから。

121 ：

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

122 ：

ひかり電話は終わってるね
NTTはSIPの自主開発すらできないってことか
http://itpro.nikkeibp.co.jp/article/OPINION/20060922/248791/
＞電話交換機はNTT自身が設計・開発しているから，何かあってもすぐに原因がわかる。
＞ところがIP電話の機器は，メーカーが開発した装置を買ってくるから，
＞ある意味ブラックボックス」（NTTのある幹部）という事情もある。

123 ：

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

124 ：

>>123
細かくサーバ分けるほどの加入者がまだいないだけだろ。
ロードバランシングぐらいしておいて欲しいけど。

125 ：

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

126 ：

>>125
輻輳の原因はバグだろ？

127 ：

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

128 ：

>>127
>東日本全体が何日も通信障害に陥るという構成にした設計
違う違う。
どこからでもかけてこられないように全部をとめたわけさ。
構成の問題じゃない。
どんな構成にしたって同じ。
127は実際、どういう構成にすればいいってわけ？
122をよく読め。フィルタリングする設定をしてなかっただけとある。
単なる怠慢。

129 ：

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

130 ：

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

131 ：

どうでもいいが、「かからない」じゃなくて「かかりにくい」な。落ちてないから。落ちたの西だから。

132 ：

もうBIG-IPでも入れてサーバ台数増やして何とかしろよ。

133 ：

BIG-IPなんて初期のころから入れてるよ。サーバーの台数も有り余るほど。

134 ：

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

135 ：

>>133
ひかり電話でBIG-IP？
え？ほんと？

136 ：

BIG-IPってSIPにも対応しているの？

137 ：

>>136
v9からOK。実績は知らん。

138 ：

ttp://www.f5networks.co.jp/solution/archive/whitepaper/wp09.html

139 ：

いまどきの性能の良いSIPサーバは、どれくらいの量こなせる??

140 ：

宣伝ぽく聞こえるかもしれんが3CXのIP-PBXってどうなのかね？

141 ：

>>140
宣伝でもいいので、いろいろ情報書いて。

142 ：

>>140
面白いISPだね。バックボーン1.5Mbps？

143 ：

>>134
NTTはさっさとENUMを導入しないから。
SIPドメインも分散すればいいのに何故しない。

144 ：

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

145 ：

>>144
また何億もかけて無駄な物を作るんか？
BIG-IP買ってくりゃいいのに。

146 ：

DNS設定でロード分散すればいいだけなのに

147 ：

>>146
SIPだよ？さすがにそれじゃまずいでしょ。

148 ：

なんか久々に盛り上がってますね

149 ：

今回は誰もSIPit参加してないのか
てゆーか前回の日本開催でどれだけ日本のベンダがいたのやら

150 ：

おい、f5！さっさとNTTにBIG-IP入れろよ。
ひかり電話がまた輻輳だぞ。

151 ：

しかし、こんな初歩的ミス犯すかね？
NTT東はバグだと弁明し、NTT西はサーバの能力不足と弁明し、ありえない。
サーバーの能力不足が原因　ＮＴＴ西のＩＰ電話障害
http://news19.2ch.net/test/read.cgi/newsplus/1161687060/

152 ：

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

153 ：

| ひかり電話にはSIPサーバーが何台ある？
| http://itpro.nikkeibp.co.jp/article/COLUMN/20061005/249968/
|
| 正解は，「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 ：

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

155 ：

SIPサーバーの性能検証試験をサボって
STP と同じ台数でいいだろ、っていうことで設計した
なんてことはないだろうな?

156 ：

ＮＴＴ西のＩＰ電話、３日連続で規制実施
http://headlines.yahoo.co.jp/hl?a=20061025-00000105-yom-soci
規制は３日連続となり、静岡県から沖縄県まで２府２８県の全８３万３０００回線で、
発信の２５％、着信の５０〜９５％がつながらない状態となっている。
２３日朝に発生した通信障害は、２４日午後１０時２０分過ぎにいったん復旧。
２５日午前６時までに通信処理サーバーを１台増設したが、
その後、通話が集中して新サーバーに負荷がかかりすぎたとしている。
規制解除のメドは立っていない。

157 ：

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

158 ：

そもそもClass4ってかMGCはあれ？Nと通研のやつじゃなかったっけ…

159 ：

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

160 ：

http://news19.2ch.net/test/read.cgi/newsplus/1161687060/219
>>呼出し用の SIP ソフトウェアは CISCO の Call Manajer 臭いな。
>>保守があって日本で馴染みの深い SIP ソフトウェアと言うとそのくらいしか思い付かん。
>>と仮定すると、サーバーのOSは、Windows 2000 Server か 2003 Server だな。
>>あんな糞 OS をミッションクリティカルなシステムに採用していたとしたら、
>>NTT もダメダメだな。

161 ：

>>160
あまりのアホさに呆れました...

162 ：

http://www.nikkei.co.jp/news/main/20061026STXKE043426102006.html
＞ＮＴＴ西の森下俊三社長はこの日の記者会見で、
＞通信処理サーバーの処理能力が
＞仕様書の記載内容より低かったことも障害の一因と強調。
いったいどこのSIPサーバを使っているんだろう？

163 ：

re-INVITE時にSDP内のConnection-InformationのIPアドレスを変更してRTP送出先を変更させるのって、
どっかのRFCに書いてあったっけ？

164 ：

>>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 ：

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

166 ：

何が起こるかわからないもの売るなよ。

167 ：

「人知を超える範囲」
これ割と稀代の名言じゃね？

168 ：

>>167
社会インフラに対して、「最先端の取り組み。何が起こるか分からない」と言うのも恐ろしい名言だ。

169 ：

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

170 ：

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

171 ：

きれいに整理把握して設計できないまま運用しているようにみえる
http://headlines.yahoo.co.jp/hl?a=20061027-00000003-imp-sci
発着信規制時に一定のトラフィックが加わった時点で
一部の中継系呼制御サーバーと相互接続用関門交換機との間で
想定外の「制御信号の衝突」が異常発生したことが原因。
これまでNTT西日本が経験したことのない事象だった

172 ：

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

173 ：

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

174 ：

あれ。半角スペースだとフシアナ解除できなくなったのか…。orz

175 ：

>>173
しかし、このままでは、PSTNからSIPベースへの置き換えは数年遅れるかもしれんな。

SkypeやP2Pなどインターネット電話が覇権を取るかもしれん。

176 ：

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

177 ：

って資料を見る限りやつらもそこまでばかじゃないな。
http://www.ntt-west.co.jp/news/0610/061027a_4.html

178 ：

電話というシステム上、2重ぐらいに出来んのかね。
何があるかわからない　ということは、結局見積もりが甘すぎたって事だな。

179 ：

>>178
見積もりが甘いにしても、度が過ぎていると思う。
余裕係数とかの取り方がNTTの場合は非常識。
http://itpro.nikkeibp.co.jp/article/NEWS/20061027/251982/
＞ 障害の原因は，毎秒140程度の同時通話に耐えられるよう設計していたはずが，
＞ 実際には毎秒120程度までしか耐えられなかったこと。

180 ：

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

181 ：

>>143
まともなキャリアなら、ENUMなんか導入するわけがない。
何のメリットもないもの。

182 ：

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

183 ：

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

184 ：

一極集中の方が管理が楽だし責任の所在も明らかなのだ

185 ：

管理のための一極集中と区切るかどうかは全く関係ないけどな。

186 ：

>>184
ドメインを区切ったほうが責任の所在はさらに明確になるし、
トラブルが起きたときも最小限の範囲に抑えられる。
NTTのような一極集中型のほうが圧倒的に不利なのは明らか。

187 ：

>>157
16.2万ライセンスってすごいな。サーバーマシンも１万台は必要じゃね？

188 ：

>>184
「「ＩＰの世界は何が起きるか分からない。人知を超える範囲だ」と述べ、トラブルは避けら
れなかったとの認識を示した。 」って、責任逃れの言い訳だよね？

189 ：

そふとばんく なハゲ電波にも
「顧客対応・管理の世界は何が起きるか分からない。人知を…」
とか言って欲しいな

190 ：

>>188
うん。たとえ言ってることが本当だとしても、今度は、リスク管理を問われる。

191 ：

地域IP網も最初の数ヶ月は毎日のようにトラブルあったなぁ
あれも丸投げやっつけ仕事だった

192 ：

ただのイソターネットと電話じゃ事の重大性が違いすぎるぜ。

193 ：

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

194 ：

メールなんかダイヤルアップで十分用が足りるからな。

195 ：

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

196 ：

>>195
あの社長、技術系じゃないからな。あんな事を言わせる技術系の部下も酷いが。

197 ：

どうせ全部丸投げでしょ。
誰一人実態を把握できていない。

198 ：

ま、部下の話を聞く奴なら、こんなことは言わんだろ

199 ：

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

200 ：

全く関係ない

201 ：

ゲートウェアに使ってたら関係あるんじゃマイカ？

202 ：

このスレで「関係ない」というのはSIPのプロトコルと関係ないということ
機器を使っているとかお客に入れているというのなら別板の話だよな。

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

203 ：

ゲートウェイに搭載してるファームウェアだからゲートウェア

204 ：

久しぶりに訪問したらなんかすごい盛り上がってるねー
>>157
ワロタ。座布団３枚

205 ：

ローゼンバーグおじさん

206 ：

| http://www.asahi.com/digital/internet/OSK200611100093.html
| システムに余力を持たせるため、３種類のサーバー計１５台を増やす。
| 装置の性能を検証し、ＩＰ技術者の育成も強化する。
やっぱり交換機技術者ばかりでIP/SIP技術者はいないのか

207 ：

早くノウハウがたまるといいんだけど。でも、まぁ、この手はなぁ

208 ：

>>207
NTTからRFC4715 (ISDN Subaddress Encoding Type for tel URI) 出たぜ

209 ：

ISDNなんかもはやどうでもいい。KPMLもようやくRFCになったのか。

210 ：

callidとかtagとかbranchとか乱数を使う場合に、
乱数の種が時間になっていると同タイムで動作した時に乱数値が同じになる。
これらの値は一意であるべきなので、これは望ましくない。
乱数だけでなく他の値も付加するか時間以外の値を乱数の種とするのが良い。
と最近思ったのですがどうでしょうか？

211 ：

>>210
当たり前じゃん。MACでも使えばいい。

212 ：

>>211
そんなことを全く考えていない端末もまだまだあるけどね。

213 ：

SIPベースで、IP電話に中継局オーナーって必要あるの？

214 ：

>>213
近未来は必要なんだろうよ

215 ：

そもそも最初っから明らかに詐欺じゃんねぇ

216 ：

>>210
まったく同意です。困ってます。直してくれよ。

217 ：

>>213
ニュースでラックの中に装置がなかったことを社長に問いただすと
「アナログからデジタルへの設備更新中」
と答えていたんで、たぶんSIPじゃないとおもわれw

218 ：

ベースバンド伝送じゃなくて変調掛けたモデム伝送なんだよ。

219 ：

>>210
そんな乱数の意味がない実装をしているSIPソフトって存在するの？

220 ：

>>219
ソフトは知らんけど、電話機ならあったな。
ファームアップで直ったけど。

221 ：

>>220
そのファームアップはソフト更新したということだろ

222 ：

ミドルウェアってどうよ

223 ：

あ〜疲れた

224 ：

SIPの次はあるのか？

225 ：

>>224
ＳｉＰときたら次はＳだろ
http://ja.wikipedia.org/wiki/%E5%91%A8%E6%9C%9F%E8%A1%A8

226 ：

というか、今はもうほとんどsips:へ移行しちゃったよね
いまどき、セキュリティに問題ありまくりのsip:使ってる人っているの？

227 ：

>>226
キャリアやISPのIP電話はsipだろ。

228 ：

電話会社やISPはあんまりセキュリティ考えてないからしょうがない。

229 ：

でやっぱりSIP技術者少なくない？
第一人者って評価高い？

230 ：

>>229
日本にもローゼンバーグ級のひとたち、たくさんいる？
もしいれば、評価高いはず。

231 ：

>>226
https使ってればセキュリティばっちり、って思ってるタイプかな？
SIPサーバとのトランスポートの安全性だけあってもしょうがないのよ。
まあ勉強してくださいな。

232 ：

>>231
はあ？ sipsつかっていれば、ホップバイホップのセキュリティはバッチリですが。
もちろん、エンドトゥーエンドのセキュリティも欲しければS/MIMEすればいいだけのこと。
あまりにも常識過ぎて勉強することか？？

233 ：

SIPなんて結局ローゼンバーグのおっさんに従ってるだけなんだなあ。。。

234 ：

>>233
ローゼンバーグおじさまは、結局、会社ごとCiscoに買収されちゃったの？

235 ：

SERってユーザーごとのコンカレントコール数制限できるの？
事情があってなんとかSERでやりたいんだけど、、、、。
知ってる人おしえーて。

236 ：

個人でも使える　ＰＳＴＮ−ＳＩＰのゲートウェイってあるのかな？

237 ：

>>236
NTTに頼めば月３００円で貸してくれる

238 ：

>>236
SIPから外線(FXO)だと一般人で手に入れられるのはアイコムのSR-5200VoIPシリーズしかない。
普通の電話機をSIPの端末にする(ATA)ならNTTのVoIPアダプタやPlanexのVTL-TA02Xなんかがある。
YAMAHAのRT56v, RT57iあたりもATAとして使える。
（SIPサーバの仕様によってはRTA55i, RTA54iもATAとして使える可能性アリ）

239 ：

>>238
NTTの116にIP電話アダプタをレンタルしたいといえば借りられるから楽だよね

240 ：

NTTのVoIPアダプタはリレーがカチカチ鳴ってうるさい。
デフォルトだとダイアルプランを設定することもできないし、
PSTNに落ちるまでの時間も長いのでオススメできない。
※といってかわりになるものも知らないが
BLW-54VPあたりはどんな感じなんだろう。

241 ：

みなさまありがとうございます。
接続形態は
>>238　さんの前者の方です。
ＮＯＫＩＡのＥ６１を内線電話（つうかコードレス）で使いたいというのが
あるんで、、、

242 ：

>>241
光ファイバー引いてるなら、加入電話をひかり電話に変えるのが一番楽だと思う。

243 ：

SIPなんかいるんかい

244 ：

NGNの話題でSIPってよく出てきますけど
一から勉強するのにお薦めの書籍あります？

245 ：

>244
RFC3261

246 ：

>>244
普通にマスタリングTCP/IPでも嫁

247 ：

>>244
実践SIP詳解テキスト リックテレコム刊
がむちゃくちゃ詳しかったが。
実際に動かしてみた方が判りが早いから、asteriskでも動かしてソフトフォンでデーターを流して、キャプチャしてシーケンスを追ってみると良い。
設定はvoip-info.jpのサンプルを使えばすぐ出来るから。
それで基本な動きが見えてから詳細を見た方が良いだろう。

248 ：

>>247
有難う
早速発注しました

249 ：

NGNの成功というより普及がSIPのステータス向上に繋がると思うわけだが、そうだよな

250 ：

果たしてあれは SIP と思っていいのか
似て非なる別のものと思った方がいいのか

251 ：

なんでもかんでも制御はSIPでって発想でしょ？NTTは。
なんなのよ、あれ。他は個別対応って。

252 ：

SIPのようなものです。
昔からNTT仕様ってそんなものです。

253 ：

SIP流行りそうな気配をビシビシ感ずる

254 ：

竜宮城はどうじゃったかの?

255 ：

今のHTTPと同じくらい流行るだろうな
好き嫌い言ってられなくなる

256 ：

SDP-ng ってまだあるの?

257 ：

>247
244じゃないが、俺からもthanks。
その本買って勉強してみる。

258 ：

>257
発刊以降のドラフトは当然入っていないので、IETFはたまに見ておくと良いよ。
セキュリティー絡みの拡張や、モバイル系の拡張はまだ入りそうだから。

259 ：

PSＴＮゲートウェイ
http://wt.uniden.co.jp/2005/04/pstn_gw_gw15p.html
http://www.ntt-me.co.jp/wondertalks/component.html#gw15p
これってどうよ？

260 ：

CxServer500のみに対応だってｏｒｚ

261 ：

上のは２５８でないです、

262 ：

いんちきnoritsuna、もう気づいてるみたいだけど
焼いておいたからねコレ。
219x113x184x110.ap219.ftth.ucom.ne.jp
219x113x184x110.ap219.ftth.ucom.ne.jp
[IN:219.113.184.107 -> OUT:219.113.184.110 ]
[殺人] 紫苑(20070203-123010)のキンタマ.zip oBHir3NXvZ 3,797,315 9d01dc3cc67c2b26d940c018d38b5480
劇団今申楽朧座(http://www.oboroza.com/index.htm)の内部資料
oboroza.com　＝　siprop.org

263 ：

>>253
ISDNやATMと同様、大流行する。

264 ：

FusionのソフトフォンのフォンPをIP電話機で使用することは出来るでしょうか？
以前G-LEXと言うサービスでSnomと言う電話機を使って利用できるようなことを言ってました。SIPを使った同じようなサービスなのでこちらの方でも利用出来るのでしょうか？　

265 ：

>>264
voip-info.jpは見ましたか？
どっかにSnom 220でFusionフォンP'につなぐ話が出てたはず。
ダイアルするときにドメインを入力しないといけないので、まともに使うのは難しいと思うけど。

266 ：

>>265
voip-info.jpを早速見ました。
受信は取り敢えず出来るみたいですね。それだけでもかなり有り難いですけど。
発信に関しては現段階では難しそうですね。同じFusion系のG-LEXでは難なく発信も出来る見たいですがどうなんでしょう？

267 ：

>>266
FusionフォンP'はSo-netのシステムで動いているので、
G-LEXとは別物と考えたほうがいいよ。
G-LEXなら至って普通に使えるけど、FusionフォンP'は専用ソフト以外の
接続を考えてないので普通のIP電話機だと使えないと思うべき。

268 ：

ヤマハのVoIP-TAがフォンP'と繋がったらしいよ

269 ：

みなさんありがとうございます。
やはり現状ではフォンPではSnomを使うのは受信以外は無理っぽいかな？
私は来月から海外勤務になるのでIPフォンが使えたら便利だと考えてます。
パソコン無しで利用できる環境を希望しているんですが中々難しそうですね。

270 ：

>>268
フォンP'以外で接続しているとFusionから電話が来るらしい。
なんでもフォンP'使うの嫌なら解約しろなんだとさ。
>>269
G-LEXにしておけば？
050番号持つなら月525円(+7.35円)かかるけど、番号なくても外線からの着信は
可能なので試しに使う分にはいいんじゃないかな？

271 ：

現状ではＧ−ＬＥＸが一番無難みたいですね。
Ｆｕｓｉｏｎは永遠に基本料が無料みたいなきがするから重宝してるんだけど。でもフォンP以外で接続すると恐怖の電話が来るんですね。気をつけないとだめですね。しかしこのサービス利用者がいるんだろうか？急にサービス中止になりそうで怖いです。

272 ：

Fusionで動作保証できない物を勝手に使われて
万が一全回線に影響するような問題が発生したら大変だから
当然の対応かな

273 ：

G-LEXで
ソフトフォンならログオフしたら留守電が機能するけどsnom220だとログオフしても留守電が機能しない。
g-lex+snomでg-lexの留守電機能使用できている人居ますか？

274 ：

Snomはログオフ時に登録を削除しにいかないのかな？
Proposed Expiryを1分にしてみてはどうでしょうか？
これならイーサの線が抜けても1分経てば留守電になるはずです。
IP電話機なんかの話をするスレをハードウェア板に立ててみました。
興味があるようでしたら何か書いてください。
【SIP,H323】VoIP機器スレ【IP電話機,ATA】
http://pc10.2ch.net/test/read.cgi/hard/1172001769/

275 ：

SIPやりたいならどこの会社がいいですか？
フラフラとかいいかな？

276 ：

>>274
thx。確かに上記設定にしてLANプラグ抜いたら留守電はいりました。
G-LEXに問い合わせた際も
"ソフトフォンの仕様で終了した事がサーバに認識されない為
「ボイスメールサービス」および「留守番センター」が
正常に動作しない場合がございます。"
という答えでしたがこれをsnomにどう照らして判断すればよいのか
理解できませんでした。
固定電話の契約をしないで携帯+G-LEX(Snom)で社会人生活を送っておりますが
なかなか一般電話と同様にというわけにはいきませんね。
SIPの仕組みから理解していかなくては、、、。

277 ：

サーバへクライアントのIPアドレス、ポートを登録するのにREGISTERリクエストが
送られるんだけど、その時に登録失効までの時間(Expire)も設定します。
ログオフするとき本当ならExpire=0のREGISTERリクエストを送って即座に登録削除
してもらうんですが、IP電話機だとそのあたりの処理を端折っているんじゃないです
かね。

278 ：

なるほど。素人にも理解できました。
簡潔で明瞭なコメントありがとうございました。

279 ：

0

280 ：

>>277
ＩＰ電話でアンレジを端折ることはないです。

281 ：

>>280
ほんと？deREGしそうな唯一の機会は電源切るときだけど、
電源切ったらそもそもdeREG送れないし。

282 ：

>>281
Snomはメニューを選ぶとログアウトできますよ。
でもログアウトなんて機能もってないのもあるから>>280は必ずしも真ならず
だと思う。

283 ：

>>280
世間知らずだな。

284 ：

手元にあるIP電話がunregister動作をするのかどうか調べてみますた。
(SIPサーバはAsterisk)
・unregister動作する
Snom 105: メニューでログオフを選択するとunregister
MobbyTalk: プロファイルを切り替える際、前の登録をunregister
・unregister動作しない
BT-101: ログオフがないのでメニューでリセットするもSIPサーバ側の登録はそのまま
BT-101ではunregisterできないと思われます。

285 ：

http://www.3cx.jp/

286 ：

もうSIPだけじゃ食って行けないな

287 ：

VG820どーっすか？

288 ：

>>286
今まで食えてたの？

289 ：

sipfropって何じゃ

290 ：

SIPropやってたのかまだ

291 ：

>>288
SIP関連の本書いてた人は印税ウハウハだったろうし、
派遣とるにもSIPのノウハウ持ってる人は希少だったから高くうれたが、
もうコモディティ化が著しいしな。

292 ：

なんかないの

293 ：

SIPを知っているの、知っているレベルが問題なんだが。
ちゃんと知っていればまだ需要は有る。
昔程高くは売れないが。

294 ：

VG820iなかなかなかなかなかなか癖があるな
TDM400ｸﾛｰﾝ買うならどこがいっすか？

295 ：

IPv6スレでSIPの話が盛り上がってたからここにもitojun来てると思ったけど、誰もいないとは…。

296 ：

itojun SIP/RTP問題まとめ
http://pc11.2ch.net/test/read.cgi/network/1131651785/819-886

297 ：

捕手

298 ：

NGNに関わるならSIPって必須？

299 ：

>>298
SIPを使ったダイヤルアップ交換網だから必須。

300 ：

INFOはなんで駄目なの？

301 ：

sip対応のwinソフトで、サーバー(またはアカウント)がいくつも登録できるものってありますか？

302 ：

>>301
CounterPathのX-Liteはどう？

303 ：

良スレあげ

304 ：

すげぇｗ　>>303カウントしなければ、去年じゃないか。
というか、名前入れないとIP表示なのな。

305 ：

age

306 ：

◆食べた人、全員肝臓ガンで死にます　〜　三笠フーズ　汚染米事件　〜
・「アフラトキシン」は地上最強の天然発ガン物質
・発症までに１０〜２０年かかるが、極微量でも摂取すれば、
　肝臓ガンになる可能性は１００％
・調理では分解されず食品中に残る
・西日本で肝臓ガン死亡率が高く偏っており、原因不明とされていたが・・・
　（資料）国立がんセンター
　http://ganjoho.ncc.go.jp/pro/statistics/gdball.html?7%9%1
医師板からのコピペ　
40 ：逃亡者：2008/09/13(土) 01:26:17 ID:23fUP1Pf0
　2年前から大阪で勤務しているが、以前の勤務地と比較して大阪は本当に
肝臓癌の患者が多いと感じた。消化器内科からTAE（肝動脈塞栓）の依頼
が次から次へとくる。
　で、ずっと疑問に感じていたことがある。大阪では患者の殆どが男性なの
だ。おまけにウイルスフリーもちらほらいる。それでHCV・HBV以外にも肝臓
癌の原因はきっとあるに違いないと、大阪に来てからずっと思っていた。
　今回この事件を知って二度驚いた。ひとつは不謹慎だけど、「あー、やっ
ぱり」っていう驚き。実際には因果関係を証明するのは無理でしょう。でも
治療している私の実感としてはピッタリだったてことなんですよね。そうい
う驚き。
　もうひとつは、自分も肝臓癌になる可能性があるっていう驚き。というよ
り、恐怖だろうか。肝臓癌の治療すればするほど思うのだが、本当に治らな
い。今では絶対に治らないという確信さえ持っている。最期が悲惨なだけに
考えてもみなかったことだ。
　肝臓癌になるかどうかは別にしても、今はこんな情けない国に生まれてき
たことが悔まれて仕方がない。
三笠フーズ（大阪）、浅井（愛知）→ノノガキ（三重）、太田産業（愛知）
島田化学工業（新潟★）　←new!!＼(＾o＾)／

307 ：

IPv6, SIGCOMP, NAT に対応したB2BUA（SBC)ってありませんか？
OpenSBC はSIGCOMPにまだ対応していないみたいなので…。
AsteriskをIP-PBXとしてでなくSBCとして使うというのもありなのかなぁ。

308 ：

保守上げ

309 ：

NTTのひかり電話利用者が700万超えたらしいね
最大で帯域どのくらい使うんだろ。
さすがに全ユーザが一度にアクセスすることはないだろうがｗ

310 ：

土日の朝方か夜間に大規模震災起きたらどんなことになるかな
まぁ、電話どころじゃないだろうが

311 ：

UPSを持ってて、なおかつONUをバックアップしてるところなんて少ないんだから、どーって事無いと思うぞ。

312 ：

SIPit24開催中
http://www.nic.ad.jp/ja/sipit24/

313 ：

関西でやってくれ

314 ：

ひかり電話＋asteriskでSIPデビューします！

315 ：

agileが超値上げの気配・・・いきなり３倍以上ってなんだよ

316 ：

残存者利益の収穫に入りますた。

317 ：

ま、慈善事業じゃないし。

318 ：

http://www.agile.ne.jp/phone/price/index.php
今まで５２５円だったのが、1890+210円って４倍の値上げやね
これじゃ普通にプロバイダのIP電話申しこんだ方がマシやん・・・？

319 ：

私はサロンパス派

320 ：

>>306
とっても暇だったので、しらべてみた。
西日本で肝臓がんが多いのは、アフラトキシンと関係があるかも知れないが、
アフラトキシンと気候に関係があるのではないかと思います。
以下引用。
東南アジアおよび日本における土壌中のアフラトキシン産生菌の分布を調べると，
アフラトキシン産生菌は本州中部以北には生息できず，本州南部から東南アジアにかけて分布していることがわかった（真鍋ら，1978）。
その分布域は，年平均気温16℃より暖かい地域であった。
http://www.shokusan.or.jp/haccp/hazardous/2_1_kabidoku.html

321 ：

skyぷー

322 ：

SIP機器とH.323機器を接続する方法ってありませんか？
出来ればお金をおかけずに・・・

323 ：

テレビ会議みたいなのってオープンソースでありますか？

324 ：

引っ越したらひかり電話ルーターも新しくなってRV-S340HIになったんだが
何度やってもiPhoneのソフトフォンでレジスト出来ないと思ったら、これ対応の携帯以外はレジストできねぇでやんのｗｗｗ
NTT糞すぎんだろ・・・・・・

325 ：

AGEphone エイジフォン さいきょーーｗｗ
http://blog.keitec.jp/p/agephone.html

326 ：

AGEphone(エイジフォン)エントリ一覧
http://blog.keitec.jp/p/agephone.html

327 ：

NAPT配下のネットワークで、SIPクライアント(IP電話)アプリが
複数同時起動して、別々のSIPサーバと同時通話できるのは
どういう仕組みですか？
単純に考えると、NAPTでUDPポート5060を特定のSIPクライアントのホストに
向けてしまうので、同時に通話できないような気がするのですが。

328 ：2013/05/30

知ってるパターンとしては、NAPTルータが
配下の各端末からsrc-port:5060で受け取った
ものを、UDPアッパーポートにすり替えて外部
SIPサーバまで送達させる。
この時のポート変換ステータスを利用して、
配下端末へのINVITE等が逆に透過されて届く。
(なので、SIPサーバから見た場合、IPは一緒
だけど、ポートが別に見える)
ちなみにルータの変換ステータスは機器にもよる
けど、短い時間で失効するので、REGISTER間隔
を短くしたり、OPTIONSパケットとかを定期的に
打ったりして、ルータステータスを更新し続ける。
SIPペイロード内のプライベートアドレスは、
ルータのSIP-NAT機能で変換させたり、専用の
SIP-NAT機器を間に噛ませて、変換して中継
させたりします。