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

1 ：2006/02/01 〜 最終レス ：2012/04/23

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 が商標登録されてるとは知らんかった。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Foundryについて語ってくれなスレ (326)
NTTさん光はいつくる？ (344)
AIR -Hってどうよ？ (489)
【DMS-10】NORTEL NETWORKSスッドレ【MAGELLAN】 (246)
■法人向けサービス　BBフォンってどうよ■ (254)
IETF 総合 (285)
--log9.info------------------
逝去したミュージシャン情報 3 (240)
洋楽の「邦題」について語ろうよ　Part2 (913)
【ｲﾝﾅ】BIG COUNTRY ﾋﾞｯｸﾞ･ｶﾝﾄﾘｰ【ﾊｯ！】 (201)
【Rock Lobster】the B-52's【Private Idaho】 (220)
ジョニ・ミッチェル‘天《女》才’Joni Mitchell (919)
フレンチポップス (442)
The Doors (744)
イーグルス / EAGLES ♯5 (760)
80年代のイギリス (357)
Simon & Garfunkel vol.3 (536)
【オールライト】フリー＠FREE No.２【ナウ】 (490)
　　◎フィル・コリンズ◎　 (266)
SPICEGIRLS　スパイスガールズ (921)
CYNDI LAUPER☆シンディ・ローパー７ (375)
★命を救われた一曲★ (675)
ボズ・スキャッグス (851)
--log55.com------------------
Androidの神アプリを挙げるスレ part67
【Adaway】Android hostsスレ Part15【Adfree】
【朗報】Huawei大勝利！！華為煽りのネトウヨ赤面ww
Nexus 5X Part34
Fire(2015) / Fire7(2017)/Fire7(2019)Part12
SAMSUNG Galaxy Tab S4 S5e part4
Androidアプリ質問スレPart21【探し物は別スレ】
Fire HD10 （2017） Part30