SIPって知ってるかい？

SIPってプロトコル知ってるかい？

VoIP に使う、セッション開始プロトコルかい？
あんまし興味ないけど。つか、常識だろ。

＝＝＝＝＝＝＝＝＝＝＝＝＝終＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

このようなスレを立ててしまい申し訳御座いません。
私の職場ではＳＩＰに焦点を置いた各種プロトコル
解析ツールやボイスプロトコル関連製品の販売を
主業としており、今日も上司からＳＩＰの知名度が
低すぎるのでもっとアピールしてこいと言われた私は
短絡的に２ｃｈだったらＳＩＰの知名度も上がるもの
だと期待して、皆さんの興味を弾くように偉そうに
『ＳＩＰってプロトコル知ってるかい？』などとスレ
を立ててしまった浅はかな消防です。

ＳＩＰでしか凌ぎを削れない会社は特定少数ですが
今後とも暖かい気持ちで見守ってください。

今思えば、『ＳＩＰってどんな風に使われているの』とか
『ＳＩＰとＶｏＩＰの未来』というスレ名にすべきだった
と反省しております。ただＶｏＩＰスレでは一瞬にして
ＳＩＰなんてプロトコルは新しい話題によって打ち消され
てしまうことが明らかだったため、敢えて調子に乗った
口調で書き出してしまいました。ああ、本当に私は恥ず
かしいです。明日、上司にありのままを話して結果どう
なろうと皆様にはご迷惑を一切お掛けしないことをここで
明言致します。本当に申し訳御座いません。何度詫びを
申しても許してもらえないことは壱百も承知です。
本当に申し訳御座いません。

知っている人は知っているし、知らない人は知らない。

知名度が上がったところで解析ツール買う奴は増えたりしないだろーが。

ていうか、まともに SIP の話をするスレにしようよ。

でも SIP は解析ツールいらん気がする...生パケット見りゃ全部わかるだろ?
(RTP は別ね。ひょっとして 1 さん、いま有明で展示とかしてます?)

どこの softphone がいい? とかね。

Pingtel のは Java だけどなかなかいい。Hotsip もそこそこ。
まあ MS から出たら全部食われて終わりのような気もするが。

今日､浜松町でSIPの会議やってたよ｡

>>9
TTC ?

age

あんまり詳しくないですが、H323とかに比べるとSIPのシステムはやっぱり
インターネット屋さんには分かりやすくていいかな？とはおもいましたね。

まあ、私の場合VOIPがあまり好きではないので、あれですが。

H.323 元がマルチメディア。でも SIP も H.323 も向きが逆なだけで
目標は被っています。

フリーなSIPの実装にはどういうものがありますでしょうか？

やっぱり VoIP って幻想ですか？
当面は「用途を限れば可」って感じッスかねぇ。
QoS できなきゃ、現状と同じ品質は保てないんでしょーか

>>15

VoIP とVPN を組み合わせてまともに動いてかつコストダウンした事例って
存在しない筈。

いまどきのは、呼び出しだけSIPであとはH.323てな感じ？

新生銀行(旧長期信用銀行)はどうやってるの？

>>17
意味不明。本屋にいって VoIP の本でも立ち読みしてこい。

SIP も H.323 も Megaco も MGCP もぜーーーんぶベアラと
いうか実信号は RTPをつかうものが殆ど。

>>19
日本語つかえ

>>20
日本語が通じていない（藁

H.323て呼び出しとか何をやり取りするのかだけまでしか規定がないってことなのね？
RFCみたいにインターネット上に転がってないのかしら。

http://www.itu.int/

>>22
ちゃんと理解するならばH.323以外にH.225.0やH.245も読む必要有り
>>23
正式版はITUからITU-T Recommendationとして買うしかないですね
Draft版なら公開しているところあった

>>24
>正式版はITUからITU-T Recommendationとして買うしかないですね
>Draft版なら公開しているところあった

20スイスフランでダウンロード出来るらしい。私は会社の ID
で好きなだけ落とせるのでやりませんが。
http://www.itu.int/

http://www.ttc.or.jp/ には H.323 の日本語版があります。
もちろんお金は必要。どっちが良いかは議論が分かれるところ
なので・・・・。

>>25
会社で持ってるID使える方ならばそうですね。
(最近なぜか繋がらなくなった)Draft版のおいてあるところは、
SGのミーティングへの寄書も全てあるので、途中の経緯もわかって
良かったんですが…残念

H.323に対応したTTC標準がどうなっているかはわかりませんが、
TTC標準は日本語訳というよりは日本仕様への拡張や機能省略を含む
場合もあるけど、概要つかむのには良いかも。

＃ SIP、この1年ほど、I-D多すぎ。追いきれない。(^^;;;
＃ WG分割しようというのも納得

>>14
http://www.cs.columbia.edu/~hgs/sip/implementations.html
を探すと(メジャーな実装ならば)載ってます。

>>27
イイもの教えてくれてありがとうございます。

SIPの話題から少しそれてしまいますが…
>>19
日本の普通の本屋でVoIP関連技術解説書ってあまり置いてないですよね。
プロトコルの話だけでなく、通話品質とか音声符号化のあたりまで丁寧に解説したもの。
洋書、和書、訳本含めて。

やっぱりSIPの話題では盛り上がらんね

アプリケーション層の話題って盛り上がらないのかな(T-T)。

SIP、がんばれ！ (^o^)/

netmeetingの呼び出しってSIPだよね

Microsoft NetMeetingは少なくとも音声系はH.323でしょう。
もしかして、最新のやつはSIPが使える？
それとも、ホワイトボードとかはSIPでやっている？

最新っつーか、次の Windows XP に付く Windows Messenger が SIP。
今の NetMeeting は H.323。

>>34
> Microsoft NetMeetingは少なくとも音声系はH.323でしょう。

現在入手可能なバージョンは H.323 だけ。

> もしかして、最新のやつはSIPが使える？

次のバージョンからそうなるそうです。

噂では Microsoft お得意の「無料戦術」で Windows XP Server に
H.323 の Gatekeeper とか、SIP の Proxy とかを付けてくるんじゃ
ないかというのがあって、Oki なんか戦々恐々としていたらしい・・・

どうもそこまではやらないみたいだけど・・・

>>35
Windows Messengerということは、VoIPといよりはIM(インスタントメッセージ)なのでしょうか？
確かに、IETFでもsimple WGではSIPのIMへの拡張をやってますからね。

>>35 >>36
NetMeeting、同じバージョン３や２でもDownloadする時期によって
微妙にマイナーバージョン番号が変わっているので、
もしかして、今downloadできる奴はSIPも使えるのかと思いました。

…というのも、たしか、V2の頃、初期のNetMeetingと後期のものとで
H.323プロトコルスタックのライブラリのバージョンが変わり
(これでH.323v1対応からv2対応になったらしい)、
初期の奴と後期の奴で繋ごうとしたら警告のダイアログが出た経験があるので。

>>37
そうですね、Windows Messenger は MSN Messenger の後継ですから。
IM というか、Presence は SIP のキモになっていくと思います。
オンラインの相手には電話、電話がまずければ IM、オフラインなら
メールか留守電といった使い分けですね。

あと、H.323 の相互接続性って改善されてきてるんでしょうか。
SIP はその辺も優位かなと思ってるんですが。

> SIP はその辺も優位かなと思ってるんですが。

これから相互接続を苦労して改善するんでしょう・・・。

国産品の SIP電話ってあります？

>>40
見たことないですが、久我山方面とかどうなんでしょう?

>>39
最近のSIMPLEの動きは余り追ってないのですが、
3月のミネアポリスの頃には、IMはSessionなのか？、というような
議論もされていましたね。

WinXPでPresence情報での切替えができるようになるとすると、
CPL(Caller Preference Languageだったかな)も
やっと日の目を見るのですかね。

>>40
相互接続性はどうなんでしょうね。
H.323みたいにH.323v1〜v4、各種Annex、H.450.Xなどの組み合わせの
バリエーションが少ないから楽そうな気はしますが…
SipIt(旧SIP Bakeoff)には日本からはどこが参加してるんですかね？
それともSIPスタック自体は買い物で済ませて、単に組み込みで
済ませちゃうのかも。

SIP電話機、国産品は大興電機(H.323電話機だしてるよね)とかが
だすのかな？

一部で有名なNOTASIP電話機(アダプタ)なら、ワールドアクセル？が
出してますよね。

>相互接続性はどうなんでしょうね。
>H.323みたいにH.323v1〜v4、各種Annex、H.450.Xなどの組み合わせの
>バリエーションが少ないから楽そうな気はしますが…

そういわれれば・・・、そうかも。プロトコル自体も簡単だし。

> SIP電話機、国産品は大興電機(H.323電話機だしてるよね)とかが
> だすのかな？

私は Oki だと思っているんですけど・・・
H.323 に足を突っ込みすぎている感も否めませんが。

>>43
安くIP電話機出すには、やはり、普通の電話機作ってるところが
有利なんじゃないですかね。金型とか使いまわして、中身をIP電話機
の基盤にしちゃえばできそうだし(素人考え)

まぁ、現状の使われ方を考えると、オフィスの多機能電話機の
置き換えだろうから、少しくらい高価でも良いのかな。

秋からのusenのIP電話は、やっぱりNOTASIPなのかな。

Pingtel かっこいい！！

http://www.pingtel.com/

でもこんなもん日本のオフィスじゃ絶対売れねぇー。でかすぎ。

デザインかっこよいよね

あげ

>>14
いろいろ探したんだけど、ソースが自由に手に入るという意味で
フリーなのはここにあるやつだけじゃないでしょうか。
http://www.vovida.org/

>>49
27ですが、>>27に書いたSIP生みの親(の一人)Henning Schulzrinne先生の
ところのURLで辿ると、NISTとoSIPもソースコード入手可能のようです。
ただし、どういうライセンスなのかまでは確認してません(oSIPはLGPLらしい)。

＃ このスレも以前に比べて書き込みが増えてきましたね。
＃ でも、実は数人で書いているだけだったりして…(^^;

この仕事の第一の特徴は､一切あなたの顔も名前も出さずに
お任せして進めることができることです。

即収入になりアップもダウンも組織も無く、
何人入らないと収入にならないとか
何段目から、オートシップ、片伸び、
一切関係の無いFuture-Webのご紹介です。
毎日少しづつ、掲示板とかＭＭ、ＭＬ等、で
宣伝しているだけですが
一日に５件〜１０件くらいの申し込みがあります。

即収入の欲しい方必見です
■詳細は今すぐこちらから
http://futuer-web.com/7823/

「オートシップ」ってとこが SIP と関係あるのか。

SIP のみの話題ではないですが。
http://www.zdnet.co.jp/news/0106/21/catv_2001.html?1606011e11
松下さんはひょっとして SIP やりそう?

>>53
やりそうですね。ヤマハさんはやらないのかな。RTで。

ところで、53さんのSIP URIはちゃんとつながるですか？
mailto:になってるから、クリックしてもだめでしょうけど。

51に関してですが
http://futuer-web.com/7823/system.htm
の図を見るとSIP Proxy経由での接続の図に見えてきた。:-)

>>54
いえ、残念ながらネタです。

↓ここの sip: アドレスは持ってるけどさすがに 2 ちゃんには書けない :)
https://sippo.hotsip.com/

微妙にまちがえた → http://sippo.hotsip.com/

>>55
確かに。こういうコールフローならばっちり課金できますな。:-<

やはり(^^;;;;
たとえメイルアドレスではなくSIPのアドレスだとしても、
さすがに、ここには書けないですね。

うーん。基本的にSIPはステートレス（呼のセッションがどこにも保持されない）
のでキャリアレベルでは、オリジナルの課金システムが必要だよね。
その代わり、エンタープライズ（企業）では、その軽さが受けるんじゃないかな。
H.323でダイアルしてからつながるまで異様に時間がかかったりするし。
※今はクイックコネクトがあるからマシだけど。

Ciscoは社内の電話はSip Phoneらしいね。イーサネットのコネクタに電話を挿すと
すぐに自分専用の電話になるの。ああ、なんて先進的。
雑誌でチラと見ただけだけど、自分の机は任意で、その日の都合で机をかえられる
らしい。

あと、フュージョンがどんなVoIPのシステムを使っているか知りたくない？
何処のVoIP機器を使って、どんなシステムを使っているかとか？

>>59
フュージョンってSonus使ってんじゃないの？

>> 59

Cisco は Skinny Phone だよ。
Skinny は、Cisco 独自のシグナリング･プロトコル。

>>61
おおっ

>>61
Cisco は SIP も H.323 もやっているよ。標準と独自両方
やっている。6/29 の Cisco の赤坂オフィスの見学会に
行った人いませんか？

プロトコルは何を使っているのだろう＞赤坂オフィス。

赤坂は Skinny です、というかテスト用を除いて全社 Skinny でやってます。
SIP は家庭向けとかに売るつもりみたい。

ｗ君？
とかいってみたり

ロンドンのIETFのdraft agendaでたね。
sipは初日の朝一からあるのか…
最終日にiptelがあるのも痛い

>>66
去年のサンディエゴの IETF では荒れまくった＞SIP

ローゼンバーグおじさん元気でした？

>>67
残念ながら、去年のサンディエゴには行ってないです。
ローゼンバーグおじさんは相変わらずパワフルですね。

去年のピッツバーグは、天候が荒れまくりましたね(^^;
私はあんな思いして目的地に辿り着いたのは初めて。

サンディエゴ楽しかったです（藁

SIP は２日に分かれていました、ところが初日の
始め、３者通話の方式からいつの間にやら SIP WG の
運営方針で初日はパー。

２日目のアジェンダを組み直して、２日間に分かれている
ものを１日に押し込んだ形になってしまいました。それでも
一応きちんと全部発表できて質疑応答出来たのだから、
やっぱりローゼンバーグおじさんは凄い人です。

ローゼンバーグじゃない SIP に比べれば sigtran とかあっ
さりし過ぎてめちゃくちゃつまんないです。まぁ目的が
ハッキリしているから揉める要素は少ないのですが。

>>69
そういう経緯があって、SIPのコマが異常にたくさん
あったわけね(3コマ＋late night session)。なっとく。
それで、SIPPPINGも分裂して生まれたわけね…

megaco、sigtranは、確かに粛々と進められていくよね。
比較的ITUよりだからなのかな。

でも、サンディエゴではスコット爺から

「ITU-T でやれば？」

と言われていました＞ Megaco（笑）。

Megaco ≒ H.248 みたいなもんだから
言われてもしょうがないかな・・・。

>>71
>Megaco ≒ H.248 みたいなもんだから
>言われてもしょうがないかな・・・。

というか、表紙とか頁ヘッダなどの見栄えの部分を除けば、
内容はまったく同一だから、"≒"なんてものではなく"≡"
だけどね。

＃ あっ、RFC側の図がAsciiArtであることは違うか :-)

IETF age

ほれ、EPSONの98互換機でPC-9801のソフトを動かすときに
使うやつでしょ。

…つまらぬことを言った。逝く。

>>73
おおっ。ロンドンはどうですか？
SIP は荒れてますか（笑）？

>>75
ロンドンは曇ると結構肌寒いです。長袖でないとちょっとつらい…
この気候になれて帰国したら倒れそう(藁)

SIPは2コマ(計5時間)が終わりましたが、まだ、時間が足りなくて、
Bar BOFを夕食時や深夜にやるようです…ローゼンバーグおじさんも
相変わらず元気でした。(^^;;

>>76
東京なら今週は涼しいです。３０℃は越えない。

ロンドンは寒いけど SIP は暑いと云うことで
しょうね。sigtran は静かで、megaco がその
間ぐらいという感じでしょうか？

って、自分が行かないから時間割見ていない（藁

SIP、SIMPLE、PRIM、IPTEL、IMPP、SIPPING…
SIPに関連あるとこ、どこででもRosenbergおじさんは元気です。
いやぁ〜、ほんと元気(藁

agarimasu

■IMプロトコル「SIMPLE」が事実上の業界標準に――AOLとマイクロソフトが指示を表明
http://www.idg.co.jp/report/itreport/backnumber/200108/20010817_01_report.html

ＩＥＴＦおわたら、しずかになってしまた

ＳＩＰ　Ｐｈｏｎｅのクライアントソフトはどこかにないで
しょうか？出来ればWindowsで動作して、フリーなら
嬉しいのですが・・・。

何でNTTの工事は、往々にしてL1とL2を逆に結線しているんだろう。
長年の疑問だったが、NTT仕様のモジュラーケーブルって反転型が標準なんだね。
だからだろうかね。

>>82
ttp://www.cs.columbia.edu/~hgs/sip/implementations.html
ttp://www.sipforum.org/products/
あたりが参考になるかも。
>>83
スレ違い？

>>82
Windows XP

>>85
XPのmessengerのSIPってVoIPでも使うの？
>>80に書いてあるみたいにIMに使う以外に…

SIPの呼制御は、VoIP専用というわけではない。

>>84
ありがとうございます。
ttp://www.sipforum.org/products/
にあったクライアントソフトを何とか使えるように設定できました。
これからいろいろ試してみます。

>>85
Windows XPの発売まで待てなかったもので。

>>88
はやく、WindowsXPで試してみたいですね。(^_^)

rfc2543bis-05がでたようなのでageてみる。
ところで、誰かXPで試した人いる？

>>90
TTC技術書、訳し直しだそうです。

eAccess&MicrosoftのVoIPサービス、確かSIPを使うはず
だけど、何処の会社がサーバ作ってるんですかね？MS?

>>91
ありゃ、かわいそうに。
でも、まだまだ05版だしねぇ。訳しなおすのもまだ早いかも。

このスレなかなか思うように上がらないねえ...

>>92
わたしも気になる。
国産でSIP対応してるのってもうある??

>>91
SWG133 は３０人ぐらいいるのでどーってことないでしょう。
私が○×の標準を訳したときは・・・・。
（書くと同業他社に特定されるので伏せ字）

http://watch.impress.co.jp/internet/www/article/2001/1114/notasip.htm

>>94
田町の会社のSoftswitchが対応しているらしいとの噂がありますね。
国産で他の会社だと。。。噂きかないからないかな？

そういえば、eAccessのって帯域100kbps使用するそうなので、コーデック
はG711を使うみたいですね。

>>97
西口 or 東口？
どっちもどっちのような気がするけど。西口のほうが人が
いっぱい居そうだから速いかもしれません。

>>98
そう言えば、両方ともやってますね。
私が聞いた噂では、穴が空いているビルの方の会社なんですけど。

100!

>>99
私の知り合いは田町駅東西口で同じところから SIP の
プロトコルスイート買ってきているんじゃねーかと・・・

>>101
いまさら、SIPプロトコルスタックを自社開発しても手間かかる
だけだから、ありえそうですね。

>>96
NOTSIP って セッション初期化プロトコルと無関係。

>>103
"NOTASIP"というだけあって、
おっしゃるとおりSIPではないですね。
あくまでもシャレでしょうけど。

>>104
ソルトレークシティーの IETF 逝く人いませんか？
ローゼンバーグおじさまにちくっておいて下さい。

IPv6が来るまで使えんだろ

>>105
今回は日本からの参加者(特に企業から)は少ないでしょうね。

NOTASIP、WG(SIPかIPTELかMMUSIC)で発表したいといったら
断られた、という話をどこかで聞いた。
あくまでもうわさ

>>106
直接的には無関係。H.323 だってそれは一緒。

>>107
SIP じゃやらせてくれないでしょうね。MMUSIC 辺りが適当か？
どうせなら NOTASIP の東工大のせんせい、ローゼンバーグに
喧嘩を売りに逝けば面白いのに・・・。

折れも逝くつもりだったのに（涙）。

>>108
かの有名なm*h*a先生ですよね。
00版は4月1日版I-Dだと思ったのですが、
いつの間にか04版にまでなっていたんですね。

違います。そんなおそれ多いことを・・・

>>110
あれ？でもNOTASIPを書かれた東工大の先生って、
かの有名なnecom830の先生ですよね。

もしかして、105,108,110さんて…

いま、神戸でInteropやっているみたいですね。。。
国産勢は相互接続できるのかしら？

SIPよりRIP

Salt Lake City へ逝かれたみなさん。
fusianasan 付きでカキコしてください。

誰かIETFスレでも作ってよ

ソルトレイクはどうですか？
参加者数は例年並ですか？

>>115

http://pc.2ch.net/test/read.cgi/network/1008077230/l50

作りました。

http://www.watch.impress.co.jp/broadband/news/2001/12/12/yamahar.htm

>>118 の URL みると

『ヤマハ、ISDNルータに「VoIP」搭載ファーム』

とありますが、なんか間抜けな感じがする・・・・
ISDN で Dialup して VoIP で通話？

>>119
今時、常時接続は当たり前

>>120
どうせ実装するならブロードバンドルータ（これもかなーり
意味不明な用語ですが）じゃないですかとゆーのを言いた
かったわけ。

64kbit/s に G.729 突っ込んで何がうれしい？
どうせなら ADSL とかでやらない？

>>121

RTA54iはADSL/CATVに対応してるよ。

また記事では

「なお、ISDN回線に接続されていなくてもVoIPは可能という。
　たとえば、ISDNルータであるRT60wでも、ルータがネット
　ワークに接続されており、グローバルIPアドレスが割り振
　られていれば、VoIPは使用可能。」

ってんで、普通の電話をヤマハルータにつないでVoIPとか
できるんじゃないの?

>>122
IP がピュア（はーと）。

>>122
Pod I/F, イーサ I/Fとハード的には揃っているので
RTA54i ---- ルータ --- the Internet
も可って事だろ。

常時＆定額で固定グローバルIPを取得できる場所ならば
内線を引けるってことっすね。

これでVPNにも対応したのがでたら最強やね。

超低価格でサテライトオフィス構築できる。
法人需要かなりあるね。
YAMAHAさんがんばって〜

何かと批判の多いヤフブブだけど。グローバルアドレス取り放題らしいので相性いいかも。

>126
局にもよりますが、すでにMACアドレス数で対策されているそうです。

41 ：>40 ：2001/06/17(日) 21:01
>>40
＞見たことないですが、久我山方面とかどうなんでしょう?
これねー、今上にも出てきたけど田町の穴明きビル関係で
大変なんよ

某社CAとの相互接続をSIPでやれっていわれてこまっています。
SIPとSIP-Tじゃつながらないよな...

たまにはageてみる。
良悪のSIP電話サービス、いつ始まるのかな？

そろそろ旬なのでage

http://bbs8.otd.co.jp/804033/bbs_plain
旬の話題

2543bis-06がでたよage

2543bis-07がでたよage
とうとうlast callのようね

>>134
TTC はどうするんだろう・・・。SWG133 だっけ。

良悪のタリフはこちら。
http://pc.2ch.net/test/read.cgi/network/1009535128/l50

VoIP以外のSIP利用ってどうよ。
VIDEO会議システムとか。
ﾎﾟﾘｺﾑあたりやってないのかな。MCU相当の機能ってあったっけ。

>>136
インスタントメッセージ用のRFCがあったと思うが

>>136,137
SIMPLEでやってるね
でもまだI-Dでなかったかな？(usokamo...)

>>138
I-Dだったかもしれない。
SIPのドキュメントって多すぎて、最近見ていないんでわすれているYO。

ちなみに、SIPって3者通話とかCall Waiting, Call Forwardingに対応
できるのか、だれか知っていますか？
MGCP/Megacoなら簡単に出来るんだけど…

どうでもいいけどよ、ip化とvoipで、日本はアメリカから、ソフト・ハード・特許とか
いろんなものを買うしかなく、この分野では、超貿易赤字だよ
この先にほんの将来は・・・

日本企業さん、もっとがんばってください

>>139
標準化されてるかどうかは知らんが
ttp://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/sip7960/ug/sipuget.htm#xtocid2473327
ttp://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/sip7960/ug/sipuget.htm#xtocid2473328

>>139
SIP関係の各種call flowはSIPPINGでの検討項目になっていたような…

ttp://www.ietf.org/html.charters/sipping-charter.html
によると、昨年末から今年にかけてIESGに出したようね。

ＮＷ工藤です。
いじょ！

>>143
どなたでしたっけ？総務省の方ですか？

SIPってシーケンス的にはきれいですよね！
ただMGCPにも言えることですが、SoftSwitchが高い！！
（あとライセンスも高い！！）

あのソフトスイッチのすれっどがあると聞いて迷い込んだもだものですけど、
皆さん結構SIPでもりあがってますね。私的にはもうSIP終わってるって感じ
なんですけど。（YBBがあなうんすしてから、意味なし。技術者のおもちゃ。
みんなで標準おもちゃにしすぎ。３GPPとおんなじ。って感じですけど。 ）
皆さんの意見はどうなんですかね。）
Megacoもおんなじ・・・多分ATMと同じ道のり・・・・

>>146
一般電話としてのサービスを提供することだけを考えると、別にSIPでなくても
かまわないかと思っています。MGCPベースの中央集権的なSoftSwitchのほうが
電話キャリアとしてもサービスし易いでしょうし。

一方、端末側にインテリジェンスを持たせたPC的なコミニュケーションサービス
を提供することを考えた場合、MGCPよりSIPの方が良いように思います。MGCPは
電話だけを考えたような点が目に付きますが、SIPの方は柔軟ですから(そのため
RFCやI-Dが沢山出来ちゃうんでしょうが)。

どんなサービスを提供しようと考えるかによって、プロトコルを使い分けること
になるのではないでしょうか？(なので私的にはSIPは終わっていないです)

Megacoは…MGCPと基本思想が同じも、ITUが絡んでいるだけあって複雑ですね。
下手したらATMと同じ道を歩む可能性がありますね。みかかさんも好きそうな点
も似ている！

>>147
>SIPの方は柔軟ですから(そのためRFCやI-Dが沢山出来ちゃうんでしょうが)

それが SIP の狙いでは？
つまり標準制定というゲームに参加しやすくすることにより普及を
測る、つまり「オモチャ」にし易くしてあると・・・・。TTC とか
早速オモチャにし始めているようですし。勘ぐりすぎかも（笑）。

>Megacoは…MGCPと基本思想が同じも、ITUが絡んでいるだけあって複雑ですね。
>下手したらATMと同じ道を歩む可能性がありますね。みかかさんも好きそうな点
>も似ている！

Megaco って適用領域が限られているから転けるとしても ATM 的な
転け方はしないと思われ。

ATM 的な転け方するのは BICC のほうでしょう（笑）。B-ISUP
と N-ISUP を統合しさらに IP にも対応なんて(CS2)・・・

SIP-Tってはやっているんですかね？

IPマスカレードしてるNAT環境クライアントにインターネット電話
使って通話は可能でしょうか？
「UPｎP使うと…」とメッセンジャーのヘルプに書いてありますけど、
このあたりのことが詳しくわかるサイトがあれば、どなたか教えて
ください

>>149
TTC のオモチャと化しています。

>>150
かなーり困難とおもわれ。不可能ではないけど。

>>150
もしかすると、ここ↓もオモチャとなりつつあるのかもしれませんが、
http://www.ietf.org/html.charters/midcom-charter.html
を参考にすれ

>>151
TTCのえらーい人達がいる会議で SIP の SWGリーダが ISUP との
インタワーク作るので協力お願いしますと ISUP のリーダにお願い
したとさ。そして ISUP にも一部変更をお願いするかもしれねーと。

そすると ISUP のリーダは激怒して、んなこった ITU-T でやれと。
それは正論だけど（笑）。日本で作ってどうする？

そーすると、I-Dを元にSIP-Tを実装したら、TTC様仕様SIP-Tとつながんなく
なっちゃうんですかね？
困ったもんだTTC。

SIP-Tを使用したCA間接続しているCAってあるんですかね？Type1 CA?

なんかちょっと見ない間に
rfc2543bisのバージョンにbis-07.9とかbis-80とか出てきるね
bis-07でたあとに変更点がたくさんでたからかね
それにしても、I-Dの番号で小数点まで付くとは…

>>154
ん、そうしないようにしろとゆー話では？

つまりIETF SIP-T の為に TTC ISUP をいじるべきではないと・・・
IETF SIP-T の為にいじるのは ITU-T ISUP → TTC ISUP の順に
しないと変だという話。

ｼｽﾃﾑ　ｲﾝ　ﾊﾟｯｹｰｼﾞ

最近沈んでるのでageてみる

>>122
IPv6対応の方はどうっすか？
Yさんと一緒にやってるんすか？
物は出来てるみたいですが納入までいってますか？

ロー船バーグおじさんの話題はいろいろ出てますが、だいなみっく祖父との
製品のほうはどうなんすかね。特に日本での状況って？
いつでも最新ドラフトに対応してるっすか？

新しいSIPのRFCって何時頃でるの？

IETF＠みねあぽりす での結果報告きぼんぬage

SIPの最近のドラフト読んでいないんだけど(英語不得意)、RFC版に比べ変更/追加
って結構あるの？

巨大IPって、SIPのcall-idみてパー死すテンスできるんだね
しらなかった

こんど遊んでみたい

巨大IP何でも出来ておっかねぇYO．

調べるの大変。。

とても初心的な質問させてください。
SIP ってインターネット電話、インターネットビデオコンファレンス、インター
ネットTV、ラジオ以外の session establishment, modification, termination
の用途以外に何か使い道はあるのでしょうか？？

Instant Messaging？

>>167
確かに…ですね。 実際にインプリする人がいるかどうかは別として。
まあ、あと２，３くらいはアプリケーションが出てくるのかもしれませんが、
今後需要のある技術なのかどうか、勉強しておいてもあんまり意味ないのかなあ、
とちょっとその辺がわからなくって質問してみました。って悩むほど複雑な
プロトコルでもないんでしょうが（基本は）。

>>168
MIME使えるから、エンドーエンドあぷりで対応させれば、いろいろすきかって
拡張できるよう〜〜。将来的にはCPL?
あと、ルーティングは最近複雑になってきてるよう〜〜。

RFCのdraftに付く「bis」の意味か教えて下さい。

ちなみに最新のドラフトは、
http://search.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-09.txt
のようです。

RFCのdraftに付く「bis」の意味を教えて下さい。

でした。

>171
2番目とか次のという意味だったと思う。

bis
━《副》
1 二度, 二回.
2 【楽】 繰り返して 《楽譜の指示またはアンコールの要求》.
【ラテン語 `twice, double' の意】
[研究社新英和中辞典]

>>172,173 どうもありがとう。
てっきり略語かと思い込んでいて、
辞書で調べてませんでした。

YAMAHAのRTシリーズはSIPをサポートするようになったらしいけど、
いろんな意味で、どうなのよ？

>175
SIPのパケットをNAT変換してくれたりするんですか？それは便利ですね

電話加入者権が高いので，よく電話をかける友達間で
RTA54iを使ってVoIPで電話をつかってますけど
何の問題もなく使えますよ．
いろんな意味でどうよ，って言われるとよくわかりませんが

>>176
ちがう。RT自体が SIP-RGW になる。

組込み機器にSIPを載せる場合、どこの会社のスタックがいいんでしょうか？
やっぱりRADVISIONなんですかね？
このへんの世界的なシェアを知っている人がいたら是非教えて下さい。

教えて下さい。
今、組込み機器向けのSIPスタックを探しているのですが
どれがいいのか良く分かりません。やっぱり、RADVISIONでしょうか？
どなたか市場でのシェアなど詳しい情報を知っている方がいれば教えて下さい。

こんなスレがあったとは！
業務でバリバリSIP使いました。次も使うとか言われてます（泣）

>>179 180
世界的なシェアは分かりませんが、RADVISIONはニュースサイトでも時々出ますね。
Trilliumを前回使ったのですが、でかい・複雑・おそらく高価。

国内でも『SIP プロトコルスタック』とかやるとひっかかるようですが。

179-181あたりを見て，久しぶりに見てみたら，
いつのまにかoSIPはFSFの配下になってしまったのね。
http://www.fsf.org/software/osip/

MGCPだと聞いたぞ

>>183
BB Phone はMGCPですけど、これは Yamaha のルータの話。

http://www.yamaha.co.jp/news/02051601.html

をごらんあれ。

LinuxかBSDで動くSIPのプロトコルスタックってないでしょうか？
YAMAHAのRTあたりとPCをつなげて遊んでみたいです

>>185
スタック探してそこからご自身でクライアントソフトを組まれるので
しょうか？期待しています。是非がんばってください。

>185
http://www.vovida.org/

>BB Phone はMGCPですけど、これは Yamaha のルータの話。
売れ残ったISDNルータのハードを、苦し紛れに使いまわししてるだけ。

vovidaって会社なのかな？
どうやって儲けてるんだろ？

oSIPが複数の呼（Call-Id）に対応しているか分からなくて苦戦中。
linphoneはソフトとして対応してないっぽいが…。

RFC,IETF準拠と言った場合には、Re-INVITEやTransfarも
必ずサポートなんですかね？

>190
Transferはdraftだから無しでしょ。
RFC2543準拠だけじゃ使い物にならない公算大。
bis07ぐらいまでは追わないと。

>>185 じゃないけど。
OpenH323とかSIPRGとか見てて思ったけど，やっぱりVoIPのカードの定番って，
QuickNet Internet {Phone,Line}JACK-ISA Card シリーズなんだね。
LineJACK は公衆回線に繋ぐから，JATEの認可がないからまずそうだけど，
JATEの認定制度自体が廃止になりそうだから，輸入品も繋げてでｳﾏｰになれる
のだろうか。

このカード個人輸入した強者はいるかい？

PhoneJACKとPhoneCARDは３年ほど前に通販で海外から買ったよ

>184
http://www.rtpro.yamaha.co.jp//RT/ipv6/faq.html

>194
＃途中で出してしまった。
ここによると、やっぱりMGCPらしい。

vovidのライブラリは転送出来そうだね。
oSIPはだめそう。

>>196
Vovida Software Licenseてのは、
copyright noticeさえ保持すれば、煮ても焼いてもOKてこと？

>>193
あのカードって，発売されたのは結構前だったから，持ってる人もいるんだね。
今から個人輸入するには(ﾟдﾟ)ｳﾏｰ ではない？

>>197 うん。BSD のライセンスと大体同じもののように見える。

現状ではプロバイダなどが提供するサービスをあまり聞かないのですが
自分でSIPサーバを立ち上げるしか手がないのでしょうか

>>195
ん？、１年前の話じゃないですか？
しかも IPv6 ・・・・

>201
パケットキャプチャで調べたら、MGCPだったよ。

MS MessengerとはSIPで通信し、機器間アナログ通話アプリとはMGCPで
通信する模様。

>>203
SIP REGISTERとかは用いられていない？
SIPの使用はMS Messengerとの間だけ？

>>203
んなこたぁない

>>205
というより >>203 て意味が良くわかんないですけど・・・
RT って SIP-MGCP コンバータなの？、それって SIP そのもの
を作るより難しそう。

>204
Messenger以外のSIP端末とも通信できるらしいが、YAMAHAからは提供されていない。
SIPソフトバンドルしてくれ＞YAMAHA

>んなこたぁない
あなたが否定しても、太陽が西から昇るわけではありません。

>206
コンバートするとは言ってない。
両方動くと言ってるだけ。
コンバートするのかしないのかは知らん。
でもパケットの中見たら、かなり似てたのでそう難しくなさそう。

>>207
>でもパケットの中見たら、かなり似てたのでそう難しくなさそう。

MGCP と SIP が？、冗談は休み休みお願いしますよ。

MGCP ってゆーのは実際何処から判断しているんですか？

RT内部での通話にはMGCPを用いております。
VoIP機能はSIPを用いております。
なわけで、SIPとMGCPの変換をやってVoIP機能を実現しています。
TEL-(MGCP)-RT-(SIP)--[internet]---Messenger こんな感じ

>>207
MGCPとSIPのどこがどのように似ているか詳しく述べよ！

207ではないけど，Megaco/H.248のText encodingならば，
SDPを使っているということで，少し似ている，とも言えなくも無い。
MGCPはmediaの記述には何使ってるんだっけ？

>>207
もしかして似てるってのはText encodingだということ？
Binary encodingに比べたら確かに難しくはなさそうな気もする。

MGCPのメディア記述はSDP
そういう点ではSIPもSDP使っているから同じといえるが。。。

>>209
>TEL-(MGCP)-RT-(SIP)--[internet]---Messenger こんな感じ

なんで電話機と RGW(=RT) の間に MGCP が入るの？？？？

YAMAHAのルーターがMGCP使ってると言うことより、
MGCPとSIPが似てるかどうかの方が、食いつきいいですね。

似てると言ったのは、パケット見て、テキストだし、SIPのヘッダの短縮形(?)と
フォーマットが似てたので、解析ルーチンが使いまわせるかなと言う気がしたからです。
そんなんじゃ似てるとは言えないという方を説得する気はございません。

SDPはパケット見た限りじゃ見当たらなかったですが、使えるみたいですね。

>208
>MGCP ってゆーのは実際何処から判断しているんですか？

パケット見たから。
＃って前に書いたぞ

mgcp 1.0って書いてあったんだから、それ以上疑う理由も無いでしょ。

>>213
MGCPはMGとMGCの間の制御プロトコルだから，
TEL=MG
RT=MGC
とつながっているのでは？
もちろん，TELがMGCP対応IP電話機の場合ね？:-)

>>203
MGCとP2Pのプロトコルをは、各々の処理機能部の機器への配置構成が
違うと思われ。
私の思うにこのヤマハの製品は：

MGCP　-　RGWとして機能させた場合に使用。
SIP　-　Routerとして機能させた場合にSIPを通すNAT機能を提供。
よってMessengerのみ対応。

もしくは、MGCPとSIP両スタック対応のRGWと思われ。

＃個人的な興味の対象は、MGCP利用時にどこのコントローラ使用してるかですね。
＃このスレとは関係なくなってしまいますが。

>>214
SDPなかったら、お話できないYO。
MGCPのSDPを含まないメッセージ種類をたまたま見たと思われ。

両方対応なら、両方対応ってうたった方が
受けがイイと思うんだけどなぁ＜SIPとMGCP

WinXPのMessengerとRTでのシグナリング時のパケットdumpキボンヌ（笑）
# やっぱり実物がナイと話がぁゃιぃ

晒しどーにかならんかな…（泣）

>218
そのとおり。
よく見たら、SDPありました。

通話が出来たのは
機器間アナログ通話アプリ--(MGCP:LAN)-->RT--(ISDN)-->一般電話
電話機==(アナログポート)RT--(SIP:LAN)-->MSMessenger
の二つ。
MSMessenger--(SIP)-->RT--(ISDN)-->一般電話
は出来るのかが良く分からない。

なんとなく一昨日からbis09を眺めてるんだけど、全体によくわかんない。
特に87ページからの14章。re-INVITEでのremote target URIの変更って
一体何に使うの?

わかる人いてる？

>>223
http://www.ietf.org/mail-archive/working-groups/sip/current/msg03908.html

| Here is an example. I send an INVITE with a Cotnact header of
| sip:<my-piece-of-state>@<my-FQDN>. The call is established. A BYE,
| re-INVITE, or other mid-dialog request will arrive to me with this URI
| in the request URI. I can use that for whatever purposes I like. If I
| wish to change it, I can issue a re-INVITE, which updates it at the
| other side.
|
| -Jonathan R.
|

一つの dialog の中で自分の Contact: をころころ変えて遊べる、
ということでしょうか。

>>224
thanks.

でも、dialog中に remote URI を
Contact: sip:[email protected]
に変更したとします。

でも、んなことしたら、IPアドレスを一つ
しか持たないふつーのUAは、以降のmid-dialog
requestを受け取れなくなるよねえ。xxx.bar.com
に端末がいたとしても、対応するdialogが
見つからないと不平を言うだけだろうし。

そのへんどうなってるんすか。

俺にはその状況が想像できないんだけど、
なんらかのかなり特殊な状況でしか使わ
ないと考えて良い？

こんなの見つけました。
http://ftp.digex.net/pub/rfc/authors/rfc3261.txt

RTA55i に プロアナ咬ましてみたけど、見事に SIP でした
けど・・・・。INVITE だとか 200OKだとか BYE だとかを
採取できました。

MGCP っていうのは結局ネタだったの？

>>227

機器間アナログ通話はMGCPを使っている。
機器間アナログ通話ユーティリティ を使って
PCとRTA55iの間でパケットをキャプチャしてみては？

>>228
機器間アナログ通信とは何処と何処の間ですか？

よーわからん。

>>227
ちなみに

TEL-----RTA55i-----DSL Modem---->

のRTA55iとDSLモデムの間にプロアナつっこみました。
「機器間アナログ通信」って何処と何処のあいだ？

>>228

機器間アナログ通話とは
http://www.rtpro.yamaha.co.jp/RTW65/FAQ/analog-extension.html
例はRT60wになっているけど、RTA55iでも同じ。
RT60w同士の通信にMGCPを使っている。

自分が試したのは（RTを2台もっていないので）
PCに機器間アナログ通話ユーティリティ(PCをアナログ子機にするアプリ）を
インストールして、RTの設定を「アナログ親機」に設定。
それで機器間アナログ通話ユーティリティから電話をかける。
構成は
PC---RT---一般回線(うちはISDN)
で、PCとRT間のパケットをキャプチャ。

＃SIPとは違う話題でスマソ

>SIP SIPPER SIPEST
結局どっちだった？

SIPで会話の保留転送ってどうするんですか？

>233
http://www.ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-05.txt

YAMAHA RT以外で、安いSIP対応電話サポートしてるのってないですか？

>235
MegaBig Gear TE4126
ttp://www.megabitgear.com/Product/FproductJ.html

うぉ、ＳＩＰについて話あってる！珍しいスレを発見したなぁ〜。
正直、ＲＦＣの表現にまだ慣れて無くて、ＳＩＰのいいテキストが国内に無いし（あっても、まぁすぐ英語版が更新されて使い物にならなくなるだろうけど）、苦労しとります。

ＳＩＰの端末を作る時、毎回思うのだけど、ＷＭのバグ対処をしなくてはならないのが一番イヤんだね。

rfc3261-3265の話題は素通りかよ〜〜〜

>>237
Windows MessengerのSIPに関するバグについてどこか情報ないでしょうか？

>>238
RFC3266もIPv6でSIPする時に影響が？

>>239
自分で調べてます。
対抗試験やってるとボロボロ出てくる。
今までやってて思ったのは、WindowsMessengerは、BYEの扱いがかなりおかしいと思います。

>>240
というか、全般的な実装がおかしいとエラー吐き出すのがBYEに集約される。
経験的に…

>>241
え？ちょっと意味が分かりにくいです。
「経験的に、プロトコルの実装がおかしいSIP端末は、BYE関連に最も異常動作が集約される」
という事でよろしいでしょうか？

まぁ、WindowsMessengerのBYEの扱いがおかしいのは間違いないです。

……そもそもBYEに応答が必要な理由が分からないんだけどねぇ。無くてもいいだろ……

>242
>……そもそもBYEに応答が……

UDPだから送信が成功したか確かめないと、状態が同期しないからでしょ。

>240&241
具体例を聞いてみたい。

未だに、ACKの代わりにBYE送るUAがある。

CANCELじゃなくてBYEが来る。

21 名前：　 投稿日：2002/06/03(月) 22:01
始めて裁判見てきたけど、ひろゆきって２chでの中傷について、「おいらは第三者だもんねー」ってな主張してたけど、裁判官に一喝されてた。
どうもひろゆきが企業の中傷を禁止してないことと、削除依頼を自分の意思で突っぱねたことで、当事者と判断されてる感じ。
でも裁判官も他の掲示板と２chは同じには扱っていないみたいだったから、他の掲示板には影響ないと思うけど。
それにしても、ひろゆきの顔はイベント板のタイトルに使ってる写真と全然違うのに驚いた。
あの写真は「勝負写真」なんだろうけど、あれじゃ詐欺だよ。
実物は深海魚みたいな顔だった。

>>243
試験した他の端末、例えば……おっと社外秘事項か、なんで某社製品と言っておくけど、セッション切断契機になるメッセージで最後に投げる時、そのメッセージを複数回投げるという端末があったよ。
具体的にはBYEを３回、BYE応答を３回。

＞UDPだから送信が成功したか確かめないと、状態が同期しないからでしょ。
その理屈だと200応答にもリトライが必要になるけど、BIS09では200系のリトライは無いんだよね。

ちなみにWMのバグだけど、上記に出てるものは比較的軽いよね。もっと非道いのがたくさんある。ある条件だとBYEを絶対に受け付けなかったりする。

>248
>その理屈だと200応答にもリトライが必要になるけど、BIS09では200系のリトライは無いんだよね。

BYEに対する200 OKを送った後に、またBYE(再送)を受信したら、
200 OKも再送しなければならないのでは？
17.2.2 Non-INVITE Server Transaction
はそう読めるが・・・

もしかしたら、
>具体的にはBYEを３回、BYE応答を３回
もそういうことかもね。
それにしても3回は多いと思うけど。

>244/245
CANCELの代わりのBYEとACKの代わりのBYEは間違いとは言えない気もする。
もちろん、RECOMMENDEDでは無いけど。

今まで見た一番ひどいUAは
INVITEとACKのCall-IDが違っている
ACKのCseqが増えている
To-tagを覚えないでACKを送信する
と言う319uaだな。

>>249
おっと、ちょい説明がわるかった。ごめん。BYEなどの非セッション系ではなく、INVITE系の200だ。
非セッションはそれ以降の受信が無いので200も再送対象に入るけど、INVITEの200はどういう事だ、と。
つまりそれだとINVITEを送るしか無いが、Transactionはきっと処理済みのCSeq番号のINVITEなのでそのまま読み捨ててしまうだろうと思う。
あるいはUAがINVITE処理中のINVITEなので483応答を返すか。

rfc読み返さないで記憶だけで書いてるので間違いあったらｽﾏｿ

>252
INVITEの200応答も再送されるでしょ？

|13.3.1.4 The INVITE is accepted
| ACK arrives. The 2xx response is passed to the transport with an
| interval that starts at T1 seconds and doubles for each
| retransmission until it reaches T2 seconds (T1 and T2 are defined in
| Section 17). Response retransmissions cease when an ACK request for

質問
100応答には、To-tagを付けるのですか？

>254
付けても付けなくても良いと思うが、大抵のやつは付けてくる

>253
あ、本当だ。すまん。何かと記憶違いをしていたようだ……

>254
rfcには必須、オプション、付けてはいけない等の表があるのでそれ見ればいいよ。
少なくとも２ｃｈで調べるのはどうかね、君……

漏れも３回は多いと思う。

２回が妥当でしょ。
あなたも漏れも、分かれるときはバイバイっていうじゃろ。

Viaの;maddrと;receivedってどう違うの?どう使い分けたらいいの?

>257
妥当と言うなら、一回だろ。

>>259
えーっと、君はアレだ、信頼できるトランスポートとかそういう話分かるのかね

と言うと？
(TCPなら上位層で再送の心配は要らない、ってことぐらいは分かってるけど・・・)
も少し詳しい説明よろしく。

>258
maddrは送信側がつけるが、receivedは受信側がつける。
viaのsent-byがFQDNだったり、実際の受信アドレスと違うときに、
受信ソースを記録しておくためのもの。
bis09
18.2.1 Receiving Requests

IETF総会のsipレポートキボンヌ。
薔薇山おじさん元気だった？

>>261
この話の一連の発言番号をたどれば分かるよ。

もしも分からなかったら、ＢＩＳ０９を読んでみましょう。

>>262
すんません、maddrの役割は・・

>264
一連のスレ読んでも、特に分かることはないと思うよ。
BYEが普通は再送されないから1回だと言う点に、異論の余地があるかなぁ？

あー、ごめん。
この端末が作られた当時、トランザクションという概念がまだBISに書かれていなかった事を書くのを忘れていた。
書いたつもりだったんだ、すまん。

過去ログ読んでというのはそういう事です。

>265
maddrは元々マルチキャストアドレスなので、普通はViaに使わないと思う。
つまり、応答も同じマルチキャストに投げろってこと。

ただし、マルチキャストではなくても付いて来る場合はあって、その時は、
応答の送信先としてsent-byの替りに使わなければならないらしい。

ああ、エプソンでNECのDOSを動かす奴な。

http://www.t-cnet.or.jp/~heaven/adultranking/rankem.cgi?action=in&id=yama

上げんな！

INVITEに200が戻ってきたときのTUにおけるACKの再送間隔ってどこかにかいてありますか？

>>272
TUにおける再送間隔？TUが再送するの？
てっきり再送はTransactionだけしかやらない、と決めつけていたけど……

>273
ACKの再送はトランザクション管理の自動再送ではなくて、2xx応答による都度再送。
処理はトランザクションユーザーのUACコアが一応担当するはず。

ありがとうございます>>273,274さん

...しかしながら質問を間違えました。INVITEに200を返したけどもACKが帰ってこない時のUASの200の再送間隔、でした。再送はするんですよね?

>>274
へぇ、ＴＵも再送するんだね。
上位がしかけるタイマーなんてTimerCぐらいかと思っていたよ。

>>275
まぁ仕事で使うデータなら自分で調べるしか。２ｃｈが根拠で仕事するわけにはいかんでしょ。
でもひょっとして、自作ＳＩＰ端末とか作るつもりなの？だったら協力してもいいけど。

>275
2xx応答はトランザクションユーザーのUASコアが担当。
0.5,1,2,4,4,4,4,4,4,4秒間隔で再送。
最後の再送から0.5秒で諦める。
トータル32秒。

>275
もちろん再送はUDPだけね。

ttp://www.ietf.org/mail-archive/working-groups/sip/current/maillist.html
ここで、色々聞けるね。

もしかして、某同人屋さんって、半可通？
と、言ってみるテスト。

そうだね
オレみたいのが居ると迷惑だったかな

>277
bis09? rfc3211?

>>282
09も3261も同じだと思う。

>278
いや、TCPもだ。

>>283
どこに書かれてるっけ..? grepしたけどみあたらない

>>285
RFC3261の13.3.1.4 The INVITE is accepted
です。

http://kabu423.tripod.co.jp/deai.html
とりあえず出会いを楽しみましょう。

http://kabu423.tripod.co.jp/h.html
あなたも完全無修正を体験してみませんか?

http://kabu423.tripod.co.jp/
http://kabu423.tripod.co.jp/shop.html
http://kabu423.tripod.co.jp/top.html
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
こちらもどうぞ。いいですよ。

質問
H.323もSIPも両方動作するVoIP電話機って売ってる？

BISとか探してると、H.323とSIPの共通化とか出てる事もあるよね。

>>289
http://www.softarmor.com/sipwg/drafts/morgue/draft-agrawal-sip-h323-interworking-reqs-00.txt
http://www.softarmor.com/sipwg/drafts/morgue/draft-singh-sip-h323-00.txt
あたりのこと？

SIPサーバー（Softswitch)で商用に耐えられるものってありますか？

>>290
ちがうなぁ。
あ、こっちが言うdraftのＵＲＬは出てこないよ。別にそれ目当てで探した訳ではないので「へぇこんなのあるのか」と思っただけで次の検索結果に飛んでしまったので。

PRACKについて、情報収集中。
単体だと100の再送を止めるモノらしい事は分かったが、UPDATEとの絡みとか、よーわからん。

あの〜　突然ですが
H.323とSIPの具体的な違いってなんですか？
誰かわかる人教えてｸﾀﾞｻｲ。
教えてﾁｬﾝでｽﾏｿ。

>>294
かなり違いますけど。同じ所を探すのが難しいぐらい。
無理して共通点を探れば「VoIP に使う、セッション開始プロトコル」ぐらいじゃなかろうか。

つーかIP出てないか、いきなり。別に出て困るような会話してませんが。

>>293
100の再送を止めるものではないです。
(100は再送しないし)
18xなどが発信UAに受信されたことを、確認する為のメッセージです。
200応答に対するACKと似た役目を果たします。

UPDTATEとも直接は関係なし。

>>296
む？rfc3262によると、rfc3261では100の再送は無いが、2.5分間に1回再送すべきだとあります。
100の再送はあり得るのでは。

PRACKの例はドラフトに多く乗っていますが、100応答に対して投げていますが18Xには投げていないように思えます。

……いや、自分の方が間違ってるかも知れませんが。
英語の書類は読み慣れてないもんでね。

>>297
ちょっとややこしいけど、3261にはトランザクションを延長したければ、
"non-100 provisional response"を毎分送れとあります。
"non-100 provisional response"というのは101-199までの応答のこと。

それに対して、3262で提案された方法を使いreliablyに"provisional responses"を
送るのなら、間隔は2分半でいいよということです。

そして、"provisional responses"をreliablyに送るために使われるのが
PRACKです。

ついでに言っとくと、3262には100応答はreliablyに送ってはいけないとあります。
言い換えると、100応答にPRACKを投げてはいけないと言うことです。

おお、なるほど……かなり読みにくい部分があったのですが、そういう事ですか。
勝手に脳内補完していたようです。危ない。

ところで、Toのtagって、要求を受けた側が付けると思うのですが、Dialogが付けるんでしょうか？それともTU？

>>299
「Dialgoが付ける」って一体… ちょっとどうかと思うな。

s/lgo/log/;

ACKを出す時、ルートセットを用いて送信先を決めてもよいのでしょうか?

>>302
よいです。

リクエストを出す時のTCP/UDPのdestination address/portと、そのリクエストのRequestURIには何か関係があるですか?

INVITEに対する183ってSIP-PSTN通話間でしか送信しちゃいけなんですかね？
お客さんには指摘されたんだけど、RFC上ではそんなこと書いていないし。
ご存知の方いますか？

>>305
わざわざ呼出音生成して送りつけてんの？ご苦労なこって。

普通はRFCの解釈に自信がないなら機能削減の方向に気持ちが動きそうなもんだけど
逆を行く>>305さんに乾杯。

>>304
一般的には無関係です。

>>305
183の送信はSIP-PSTNに限定されているわけではありません。
また、SDPを必ず付けなければならないわけでもありません。
ただ、このタイミングで、SDPを付ける必要があるとすれば、
「お客様のおかけになった電話番号は・・・」
「・・・留守番電話サービスにおつなぎします」
「・・・新しい電話番号はxxxです。」
など、PSTNでは通話前にメディアの送信を開始しなければ
ならない場合があるからです。
ですから普通、呼び出し音だけなら使わないと思います。

ちなみに、SDP付きの183は普通reliablyに送ります。(298)

>>305
追記
SDPのない183はトランザクションを延長する目的でも使われるし、
そもそも、理解できない"non-100 provisional response"は
183として解釈せよと言うのがRFCではMUST項目です。
183を返信されて文句を言うそのお客さんは要反省です。

>>299
トランスポート、トランザクション、TUの３択だとすると
To-tagはTUのUASコアで生成すると思います。

e

SIPとSIPSって何が違うの？
勧告には「SIP（又はSIPS）」みたいな表記が結構出てくるんだけど・・・

SIPSはover SSL

SIPS-URIが指定された通信は、トランスポートにTLSを使います。

SSL≒TLS

>>307
じゃぁRequest-URIなんていらないじゃないですか

>>316
SMTPサーバにメールを送るときに、あて先書くでしょ。

>>317
RCPT TOですか?ちょっと抽象的すぎるのでSIPにおけるRequest-URIの役割解説ぼきーん。

http://kado7.ug.to/net/


朝までから騒ぎ！！
　　　小中高生
　コギャル〜熟女まで
　　　メル友
　　i/j/PC/対応

女性の子もたくさん来てね
　　小中高生大歓迎です　　　　　　　　　　　　　　　　　
全国デ−トスポット情報も有ります。
全国エステ＆ネイル情報あります。

　　激安携帯情報あります。

>>318
荒らされるから、sageでよろしく。

>>318
送信先がproxyだとして、メッセージの送信先アドレスはプロキシのIPアドレスです。
一方、Request-URIに指定するのは例えば
sip:[email protected]
だったり
tel:0312345678
だったりします。
Request-URIはアドレスを指定するのではなく、宛先を指定するわけですから、
DNSでAレコードが引けるわけではありません。

Request-URIが何かというとだ。
「REGISTERは何するんだ？」
が解答だと思うんですが。

あ、お久〜

>>321
To: との違いは…?

>>323
基本的にToは宛先としては使われません。
URIが無くて表示名だけでも良いぐらいです。
(定義では許されませんが)

というか、RouteSetとかproxyのforkingとか、
RequestURIを活用する場面はいくらでもあるでしょ。

具体的には「要求送信時」にtransactionは
「OutboundProxyを使っていない時に限り」
要求はRequestURIのアドレスに送るんですよ。

要求を送信するのに、ネットワーク構成上、どうしても
A-P1-P2-B
という経路で要求を送信しなければならない時、
Aの要求送信先(RequestURI)はP1になる。
けどそれだけだと、P1はそれを受け取っても次にどこに送ればいいのかわからない。
だからToを見る。P1はBに要求を送る場合、P2に送らなければならない事を、
LocationServerからの情報で知っているので、次はP2に送信する。
P2はBからREGISTERを受信して、Bのアドレスを知っているので、
TOにBが指定されている要求を受信したら、Bに転送する事ができる。

という訳で、TOの宛先は、アドレス必須なんだよ。>>324
オレでも役に立てたかい。

げっ、間違い発見。Transaction->Transportだし。
「2chだからいいかなぁ」と見直さずにupしたせいですな。

という訳で、参考程度に見てくれ。やっぱりRFC読んで理解せーへんと。

女子供はすっこんでろ

>>323 ていうか、Request-URI は hop-by-hop、To: は end-to-end。それが違い。

Record-routeの使い道がよく分からない。
requestに対するresponseの経路はViaで示されるものと
思ってるんですが、じゃあ何の為にRecord-route残すんでしょうか？

>329
AがBに要求を出した時、ContactがCだったとしよう。
その場合、Bは次にAに要求を出す時はCに送る。
”Record-Routeが無ければ”。そうだよね？

>330
早速のレスありがとうございます。
つーことは、Record-Routeがあれば、BからAへの要求はContactのC宛てではなく、
Record-Routeを付加した経路を逆に辿っていく、という事になるのでしょうか。

>>325
繰り返しになりますが、
基本的にToはRoute処理に使われません。

Request URIが受信したproxy自身を指す場合は、既にRoute Setが
決定済みで、次ルートが"Routeヘッダ"で示されているはずです。
ただし、これは古い(sl?)のルート処理で、3261の新しい(lr)
ルート処理ではRequest URIは送信先UAを指しています。

RFC3261
Figure 1: SIP session setup example with SIP trapezoid
の例から、もう一度読み直そう。

rfc3261の分りやすい和訳無いか?
もう英文見るのイヤになってきた。

>>330
ちなみに、Record-Routeが無い場合、ACKもContact宛ね。
(SIP-Triangleと言うのだろう)

同人さんよ、あンた、RouteとRecord-RouteとRouteSet、これらの語を正確に
使い分けているかい？

>>332
あー、それは君が僕の書いてる事を読み違えてるんだ。
RouteSetナシでも、A->P1->P2->Bというルートを通る事があるだろう。その例だ。
そもそも>325にはRouteSetの事なんぞどこにも書いてないぞ。先入観でモノを見るな。

>>335
使い分ける必要が「２ｃｈという場所」で、あるのかい？
まぁ厳密に言うなら、330はRouteSetが存在したらという事だね。
しかし、Bの立場からすると、Aから受け取ったメッセージにRecord-Route
があるか無いかって観点で見た方がわかりやすいかと思って
ああ書いただけ。

実際、君の説明と僕の説明、どっちが理解しやすい？
プログラマってぇのは人と接するのがどうも苦手なんだね。オレ自信もそうなんだが。

>>336
>RouteSetナシでも、A->P1->P2->Bというルートを通る事があるだろう。その例だ。

RFC3261
Figure 1: SIP session setup example with SIP trapezoid
がRouteSetなしでA->P1->P2->Bを通る例です。
そして、その場合A->P1に送られるINVITEのRequestURIはBのSIP-URIです。

>そもそも>325にはRouteSetの事なんぞどこにも書いてないぞ。先入観でモノを見るな。

あなたが
>A-P1-P2-B
>という経路で要求を送信しなければならない時、
>Aの要求送信先(RequestURI)はP1になる。

と書いたので、A->P1のRequestURIがP1になるのは、RouteSetが
決まっているときだと書いたのです。

もっとはっきり言うと、あなたの325の説明は間違っていると言うことです。

>>336
>実際、君の説明と僕の説明、どっちが理解しやすい？

Mr.335はRecord-Routeについて説明してないと思いますが。
何と比べてるんですか？

それから、分かり易い説明も大事ですが、まず正しい説明を心がけましょう。

ちょ、ちょっと待て！！！
何だよ、さっきから同一人物かと思っていたが、複数人なのか？sageって。
正直、こちらは何に返事をすべきか分からなくなった。何か交流したけりゃ
別の捨てコテハンでも使って、どの発言が統一された意見かを述べてくれ。
同じコテハンばかりでこちらが混乱しないと思ってるなら恐ろしいぐらい
コミュニケーション能力欠如だぞ、おい。

で、>337だけど、あんたoutboundProxyとSIP proxyの区別ついてるかい？
オレの説明でP1はどちらだと判断したんだよ。
どちらだと思ったのか、またその明確な根拠を述べてくれ。
多分、あんたは、そこを思いこみで語ってる。

更に言えば、今まで一度も通ってないルートにRouteSetが先に存在してるわけなかろうが。
あんたこそRouteSetの言葉の使い方間違ってるぞ。

sageばかりで発言をゴッチャにしていたら失礼。
でも、それは混乱させてる状況をそっちが作ってる事で了解だよな？

>>339
俺は、337には何処にも間違いが無いように思うけどな。

>更に言えば、今まで一度も通ってないルートにRouteSetが先に存在してるわけなかろうが。
せめて、「一度も通っていないルートを表現するRouteSet」くらいの文章にしてくれ。
意味がわからん。

>>339
>で、>337だけど、あんたoutboundProxyとSIP proxyの区別ついてるかい？

Outbound ProxyもSIP Proxyだと言うことぐらいは、
同意してもらえますよね？

>オレの説明でP1はどちらだと判断したんだよ。
>どちらだと思ったのか、またその明確な根拠を述べてくれ。
>多分、あんたは、そこを思いこみで語ってる。

Outbound Proxyとは考えていませんでした。
>>325
>要求を送信するのに、ネットワーク構成上、どうしても
>A-P1-P2-B
>という経路で要求を送信しなければならない時、

とあったので、定かではない理由により、AはP1にリクエストを
送るのだと考えただけです。

>>339
すごいな。
IDが同じ＝同一人物
と勝手に思い込んでいたのに、
「恐ろしいぐらいコミュニケーション能力欠如だぞ、おい。」
とか
「でも、それは混乱させてる状況をそっちが作ってる事で了解だよな？」
とか書いてる。
自分は正しくて、悪いのは相手だ信じ込んでいるところが厨ですなぁ。

>>341
おいおい、OutboundProxyとSIP Proxyの区別付いてないの？
OutboundProxyがSIP proxy、だから何？
動作が全く違う。特に今回の話に関わる部分で動作が違う。一緒にするな。
両者は、Request-URIに関する扱いは、全く一緒なのか？
PRESENSEサーバに送るRequestURIのホストは何を指定するんだっけ？

掲示板で何か言い争うってのは嫌いだから、正直、この辺でやめたいんだよな。

あと、335だけど、あんたはオレよりRouteSetの事が分かってない。
ContactもRouteSetを構築する要素の一つのはずだ。
だからRecord-Routeとの違いを説明する為には、330の説明でいいんだろうが？
「RouteSetがRequest-URIに影響を及ぼす」のは大前提として、その上での優先順位を語っているのだから、
330は全く問題が無い。
335は完全にこれを論破する確たる証明をするように。ケチつけたんだから。

>>342
ハァ……あんた、SIPについて語りなよ。
人を煽るぐらいなら、オレを知識で言い負かせなよ。やり方が厨だぜ。
少なくともオレのように、ＳＩＰについて語るならともかく、
態度にケチ付けるんなら、単なる邪魔モンだ。

ちなみに
>すごいな。
>IDが同じ＝同一人物
>と勝手に思い込んでいたのに、
これ、当然だと思うけど。
どこが当然じゃないのか、キッチリ論破してくれよ、厨。

同人屋厨兵衛の語るところのSIPモドキのナニカの実装を見た事がある俺。
どうもお久しぶりです。逝ってよし。

>>339
>更に言えば、今まで一度も通ってないルートにRouteSetが先に存在してるわけなかろうが。
>あんたこそRouteSetの言葉の使い方間違ってるぞ。

RFC 3261
8.1.1.1 Request-URI
の"pre-existing route set"についての説明によれば、
今まで一度も通ってないルートにRouteSetが先に存在することはあるのです。
更に、"pre-existing route set"はRouteヘッダで処理するとか、
Outbound Proxyは、そのURIを"pre-existing route set"として処理するとか書いてあります。

ですから、
>>336
>そもそも>325にはRouteSetの事なんぞどこにも書いてないぞ。先入観でモノを見るな。
とありますので、やはりP1をOutbound Proxyとは考えてなかったんですよね？

とすると、やはり
>>337
>RFC3261
>Figure 1: SIP session setup example with SIP trapezoid
>がRouteSetなしでA->P1->P2->Bを通る例です。
>そして、その場合A->P1に送られるINVITEのRequestURIはBのSIP-URIです。

と言う結論に達するのが、妥当では？

そろそろ、
>Aの要求送信先(RequestURI)はP1になる。
と言う主張の根拠を知りたいんですが？
その自信はどこからくるの？

>>343
>おいおい、OutboundProxyとSIP Proxyの区別付いてないの？
>OutboundProxyがSIP proxy、だから何？
>動作が全く違う。特に今回の話に関わる部分で動作が違う。一緒にするな。
>両者は、Request-URIに関する扱いは、全く一緒なのか？

Outbound Proxyというのは、UAがリクエストを最初に投げるSIP Proxyです。
それは、UAの都合であって、proxyにとっては、Outbound Proxyだと
"思われているかどうか"で動作を変えたりはしません。
Request-URIに関する扱いは、全く一緒です。

ところで、結局あなたは、A->P1->P2->BのP1をOutbound Proxyだとして、
説明をしていたんですか?それとも違うの?

>PRESENSEサーバに送るRequestURIのホストは何を指定するんだっけ？
PRESENSEサーバに送るSUBSCRIBEリクエストのRequestURIはPRESENSEサーバのRequestURIです。
[A->PresenceServer]
SUBSCRIBE sip:[email protected] SIP/2.0
(ttp://www.ietf.org/internet-drafts/draft-ietf-simple-presence-07.txt)

PRESENSEサーバはproxyではなくUAですから、もちろ[んA->P1->PresenceServer]と言う場合の
A->P1のRequestURIもPRESENSEサーバのRequestURIです。

>掲示板で何か言い争うってのは嫌いだから、正直、この辺でやめたいんだよな。
言い争いではなく、SIPについての議論だと思っています。

掲示板で何か言い争うってのは嫌いだから、正直、この辺でやめたいんだよな。
でも、要望には応えなくちゃね。

>>344
>どこが当然じゃないのか、キッチリ論破してくれよ、厨。

2chは同一人物しか同じIDを使えないシステムじゃ無いから。
Q. E. D.

>>347
s/PRESENSEサーバのRequestURI/PRESENSEサーバのSIP-URI/

うーむ、じゃ、こっちの根拠を書き出そう。全てRFC3261からの引用。

8.1.1.1 Request-URI

The initial Request-URI of the message SHOULD be set to the value of
the URI in the To field.

Request-URIは基本的にはTOの値のコピー。だからTOにURIが設定されなくても構わないと
いうのはRequest-URIに変な文字列が設定される事を誘発させる。


16.5 Determining Request Targets

If the domain of the Request-URI indicates a domain this element is
not responsible for, the Request-URI must be placed into the target
set as the only target, and the element must proceed to the task of
Request Forwarding (Section 16.6).

つまりAはRequest-URIを常にP1に置かなければならない環境がありえるという事。


12.2.1.1 Generating the Request

The UAC uses the remote target and route set to build the Request-URI
and Route header field of the request.

つまり、Request-URIは決してTO及びRouteSetから「だけ」で作られる訳じゃない。

>>348
えーっと、あんたアホですね。
それを言うなら
「オレは寝たきりの自由に殺す事ができる。なぜなら、この世の物理システムが、オレが寝たきりの老人を殺す事ができるようになっているからだ」
と言ってるのとまるで変わらん。
「出来る」と「許可されてる」と「倫理的にしても良い」の区別がついてないのか？

ちなみに2chのFAQより「なりすましは禁止」とされている事は知ってるよな？
だからキャップ制度があるという事ぐらいは分かるよな？
オレが人殺しをしてはいけない理由、それは倫理的なものだ。そして、２ｃｈにも倫理がある。そして、他人と同じHNで書き込む事はＦＡＱで禁止されている。

ちなみにマジツッコミすると、あんたＱ．Ｅ．Ｄ．っていう意味、分からなくて使ってるだろ？
それを使う事が出来る条件を挙げてみて、あんたがここで使えるかどうか、もう一度考えてみな？

>>350
>Request-URIは基本的にはTOの値のコピー。だからTOにURIが設定されなくても構わないと
>いうのはRequest-URIに変な文字列が設定される事を誘発させる。

だから以下は無視するとして、To-URI=Request-URIと言うことは、
"あなたの"Aが出すINVITEは
INVITE sip:P1.domainX SIP/2.0
To: <sip:P1.domainX>
なるの？

"私"のAの出すINVITEは
To: <sip:B.domainB>
だから、
INVITE sip:B.domainB SIP/2.0
だと言ってるんですが。

>If the domain of the Request-URI indicates a domain this element is
>not responsible for, the Request-URI must be placed into the target

この章はプロキシの章だから
「Request-URIのドメインが、proxyの管理しないドメインである場合」
って、あなたの説と無関係だよね。

>The UAC uses the remote target and route set to build the Request-URI
>and Route header field of the request.
>つまり、Request-URIは決してTO及びRouteSetから「だけ」で作られる訳じゃない。

"remote target"と"route set"からRequest-URIは作られると書いてありますが？
"remote target"ってToに書くURIだよね？

指摘がいちいち的外れなんですが・・・

＞344
＞人を煽るぐらいなら、オレを知識で言い負かせなよ。やり方が厨だぜ。
＞少なくともオレのように、ＳＩＰについて語るならともかく、

知識で言い負かされたようですが、めげずにこれからもSIPについて語ってください。

>>347
ハァ？脳味噌にウジわいてるのか？
>だから以下は無視するとして、To-URI=Request-URIと言うことは、
>"あなたの"Aが出すINVITEは
>INVITE sip:P1.domainX SIP/2.0
>To: <sip:P1.domainX>
>なるの？
どこをどう読めばそうなるんだよ。オレは「TOには正しいアドレスを指定する必要がある」と書いているのだよ、Request-URIの構築の為には。
＞繰り返しになりますが、
＞基本的にToはRoute処理に使われません。
これへのツッコミなんだよ。
自分の過去発言は無視で、オレの発言だけ曲げて読んで間違い指摘かよ、んなの誰でも出来る。

オレの書き込みの中で、どこにRequest-URIがTOを形成する、などと書いたよ？
勝手に補完するなと何度も書いたろうが。

>353
とうとう屁理屈でも完全に言い負かされたからって、それか。
いいから、Q.E.D.という言葉はいつ使っていいのか調べて、それで上記はそれに当てはまるかどうか確認したのか？
オマエ自信に、SIPの知識で言い負かされなれない限り、あんたは突っ込む権利無いんだよ。
さっさとオマエ自信が、ＳＩＰの技術的会話しろや。

というか、何の為にRFCの原文引用したのか、わからん。
>"あなたの"Aが出すINVITEは
>INVITE sip:P1.domainX SIP/2.0
>To: <sip:P1.domainX>
>なるの？
ここ、ちゃんとオレの引用した原文読んだ上で書いたのか？逆の事なら書いてあるが、そんな事を思わせる記述はどこにも無いだろうが。

それらしく語っても、言ってる事がグチャグチャだぞ。
でもって、第三者として煽るなら、どちらが正しいのか雰囲気ではなく、ちゃんと書き込みの内容から判断して書くように。ｎ
んでもって技術的なツッコミを行うように。

まぁ、屁理屈でも負けてるんだからしょーがねぇ存在だよなぁ。

はいはい、Request-URIにproxy指定して、Routeヘッダも付けずにINVITE出してください。
おそらく、あなたのエセSIP端末としか繋がりませんが、私は別に気にしません。

ごちゃごちゃ書いてるが、Toを使ってルーティングするなんて、
RFCのどこに書いてるんだよ、ボケ。

某同人厨についての3択
1.英語が読めない
2.日本語が理解できない
3.単なる負けず嫌い

漏れは３に1北朝鮮＄

厨さんですが
>Request-URIが何かというとだ。
>「REGISTERは何するんだ？」
>が解答だと思うんですが。
と最初に書いてる。
REGISTERのRequest-URIとINVITEのそれの区別がついてないことからして
すでにダメダメって感じ。

こんなのどう？

Riquest-URIにはToのURIをコピーすべきである。
ToヘッダのURIはBである。
∴Riquest-URIはBを指定すべきである。
Q.E.D.

おそらく、厨は
「"すべきである"だからしなくてもいいんだ」
と反論するであろう。(予言)

お疲れ。>>356

INVITE sip:P1 SIP/2.0
To: sip:B
か？
送るのは勝手だが、うちのProxyなら即刻485(Ambiguous)だぞ。

そろそろ、違う話に移って良い?

sip:[email protected]
というURLが分かっているだけでも、通話って出来ますか?
つまり、どこにINVITEを送ればいいの?

>362
Outbound Proxy

>363
では、Outbound Proxyはthere.comのプロキシをどうやって見つけるの?

>364
DNSのSRV record?

>365
"there.com"のSRVレコードを引くの？

>366
ジャネーノ？わたしは全く実装を経験したことないので同人タンの降臨をまちましょ（藁

>同人タンの降臨をまちましょ（藁
思い込みの激しい、知ったか君は暑苦しいから、不要論。

INVITE-------->

<--------- 100 Trying

<--------- 100 Ringing

無効なパケットです。破棄します。

このままSIPで進めて間違ったらダウトをコールでいい?

<---------------- 699 A-bone

>374
同人を?

>370
ダウト

死にたい

UPDATE------------->

インターネットにつながってない状態で動作する
フリーのSIPアプリってないですか？
実際に流れるパケットを見てみたいです。

>379
http://www.vovida.org/

>380
「板違いだｺﾞﾙｧ」とか罵倒されて終わりだと思っていました。。。
ダメもとで聞いてみて良かった

ありがとうございました。

Voipｽﾚから追い出されました。
>ttp://pc.2ch.net/test/read.cgi/network/1013050662/353

みなさん課金について語ってください。

>>382
発呼時刻と着呼時刻をソフトスイッチで記録しておく。

>383
切断は？

>>383
TDMの発想だとおもわれ。
時間課金であれば実際のRTPパケットの何らかのモニタ必須。
そうでなければ時間課金でなく定額など。

OSP(Open Settlement Protocol)だろ

Q1.転送のためにREFERを送るダイアログは、転送するコールと
　 同じダイアログにしなきゃならないの?
Q2.REFERを受けて送信されるINVITEのCall-IDは元のコールと同じもの？

age

sage

sage

SIPってなくなりそうじゃない？　重要なの？

>392
今のとこ重要

うまくなくなれば開発費ふんだくって
動くものおさめなくてもよくなるかもYO

>392
この給料泥棒！貴様はクビだ。

>393
いいじゃん
みんなどっかでそれを期待しながら作ってるくせに！！

なにがいいってあの納入直前の各種品質記録関連ドキュメント
をデッチアップしなくていいのがｲｲ!!

間違えちゃった
>394は>391じゃなくて>392です

REFERってなんだ？

>>396
draft-ietf-sip-cc-transfer-0?
draft-ietf-sip-refer-0?
draft-ietf-sip-referredby-0?

＞REFERってなんだ？
新しい勧告でてなかったけ？

ここはIEFT　SIP評議会、
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-refer-05.txt
ここにあるけど。
SIPトランザクションとともにあらんことを！！

may sip transactions be with you!!

SIPサイコー！

曖昧なRFCサイコー！

先週、某○KIと打ち合わせしたら、RequestURIとRecordRouteについて
故同人屋と同じ見解だったなぁ。
大丈夫かなぁ。

>403
トリップの人達？

>399
ttp://www.ietf.org/internet-drafts/draft-ietf-sip-refer-06.txt
こっちの方があたらしいよ。

>>403
本人

>>403
故・・か（藁

>>407
あんな彼でも居ないとなると寂しいなぁ、なんて思ってませんか?

善 善

誰か会議について語ってくれ

>381
某代理店サイトによると、RFC違反もあるようだから鵜呑みにはせんほうが
よいかもしんまい。

　　　　　　　　　　　,. ''"´　 　 ｀ `　､　　 　 　　 　　
　　　　　　　　　　 ;'　　 　　　　　 　　 ':..　　　　　　
　　　　　　　　　 ;'　　 　　　===　　　====　　　　　／￣￣￣￣￣￣￣￣
　　　　　　　　./　　　 　　　 ● 　　　 ● 　　　＜　ウタちゃんですが、何か?
　　　　　　 　./　　　 　　　　　 ⌒ 　▼⌒': 　　 　＼＿＿＿＿＿＿＿＿
　　＿＿　　./　　　　 　 　　彡　　∵人∵ﾉミ＿＿＿
　　　￣　.／　　＿ 　　 　　　　　ﾐ　　 ﾉ"ﾐ￣￣￣
　　￣￣￣￣￣━━￣￣￣￣￣￣￣￣￣￣￣
　￣￣━━━￣￣￣￣￣￣￣￣￣

>>411
ＭＬで指摘すればすぐ直るものを…、
って、どこにそんな情報あった？

http://www.nortelnetworks.com/products/01/succession/cs/ims.html
こんなの発見。　使えるのかな？

>>410
ttp://www1.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-02.txt
ttp://www1.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-00.txt
ttp://www1.ietf.org/internet-drafts/draft-ietf-sipping-cc-framework-01.txt
ttp://www1.ietf.org/internet-drafts/draft-ietf-sipping-cc-framework-01.txt
あたりじゃねーの

>>414
宣伝でつか?

>>413
某代理店サイトって ttp://www.dairiten.com:81/ のことじゃ
ないかと。googleに広告出してるみたいだけど、何を売っている
のかは良くわからない罠。

SIP SOP SUP

いみなくあげんなよ
さて潜行。

REGISTERするタイミングについて、どのような実装が存在するか教えてください。
SIPのmobility機能について興味持ってます。

･DHCPでアドレス取得できたら。。
･クライアントを起動した際
･マニュアルで。。。

等々。できればどこそこのクライアントとういう情報込みで。

漏れはDHCPで…で実装しますたね。

っていうかageんとるてぃーや。

>420
マニュアル
起動時
アドレス取得・変更時
設定変更時

ぐらいか

>421 , >423 有難うございますた。

ティムポ-------INVITE------->マムポ

家庭で使えるSIPフォンってある？

>426
PC

QoS関係の新しいRFC出たね。

フュージョンとBIGLOBEから発表されました
SIPらしいですよ

SIPの本が出てました。
翻訳らしいけど。
内容はどんなん？

http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06492-1
オーム社から出たこれやね。


マスタリングTCP/IP SIP編
Henry Sinnreich・Alan B.Johnston　共著
阪口克彦　監訳
B5　320頁　定価(本体3800円【税別】)
ISBN　4-274-06492-1

阪口克彦って誰や?

オリジナルは Internet Communications Using SIP みたいですね。amazon の書評は★５か。

>431
googleで引いたら、
http://www.softfront.co.jp/company/manage.html
がトップヒット。
業務からして当たりの予感。

>433
ふぅ〜ん。
でもまぁ監訳だからねぇ。
実際の訳は近所の大学生にアルバイトさせたとかあるかも。
買った人レビューｷﾎﾞﾝ。

買って読んでる。
解説範囲は割と広い。
SIPを使ったサービスにも触れてて、初級＆中級をカバーしていると思う。
オリジナルは約２年前なんで2543ベースだが、訳の段階で3261準拠にしたらしい。
って、どこが違うのか分からないけどねー。

>435
「H.323/MPEG-4教科書」
と比べてどうよ。

>>432
原著者の会社って倒産したんじゃ・・・

RFC3261(2543でも可)の翻訳をダウンロードできるサイト知りません?
もちろん無料がありがたいけど有料でもいいです。

>>438

ここにあるよ。
http://www.softfront.co.jp/tech/sip/rfcdraft_sip.html

ふれっつadslでc806でうまくいきません。おしえてちょ
Router#sh run
version 12.2 / ip subnet-zero
no ip domain-lookup / vpdn enable /vpdn-group 1
request-dialin /protocol pppoe /interface Ethernet0
ip address 192.168.1.1 255.255.255.0 /ip nat inside
hold-queue 100 out /interface Ethernet1
no ip address /ip nat outside
pppoe enable /pppoe-client dial-pool-number 1
interface Dialer1
ip address negotiated /ip mtu 1454
ip nat outside /encapsulation ppp
ip tcp adjust-mss 1414 /dialer pool 1
no cdp enable /ppp authentication pap chap callin
ppp chap hostname ******@******.ne.jp /ppp chap password 0 *********
ppp papsent-username *******@*****.ne.jp
ip nat inside source list 101 interface Dialer1 overload
ip classless /ip route 0.0.0.0 0.0.0.0 Dialer1
no ip http server /ip pim bidir-enable

>>439
ありがとー
他のも翻訳と薄く見えるんだけど、そのうち公開されるのかなぁ?

ソフトフロントがんばって欲しい。ってゆーかもっと注目されてもいいのに。

http://www.eaccess.net/company/press/2002/021127.html
これって SIP なの？

SIP らし http://www.rbbtoday.com/news/20021127/9611.html

>>444
MGCPのBBホンを包囲するつもりなんでしょうか？

"N" SIPって聞いた。
ところで"N"ってどんな方言なんだろ？

ＳＤＰ内のメディアフォーマットで、１０１って何でしょう？
ＲＦＣ等で調べたんですが、分かりませんでした。
０，８，１８等は、ベアラ（圧縮率）ってのは分かったんですが。。。
情報キボン

>>446
NOTASIP ？

>>447
ユーザ定義コーデック値だとおもうが。
SDP内にコーデック定義ない？
ない場合は、端末側が勝手に定義した値のはず。

>>446
Nanchatte SIP

野郎ども。パークとピックアップについて語れ。

ここに全部書いてある http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-03.txt

pickupするための情報を、SUBSCRIBE/NOTIFYで知らせてもらう場合の
Eventってどこかで提案されてた？

>>447
Content-Length: 269

v=0
o=internet_HQ 0 0 IN IP4 202.54.5.12
s=session
c=IN IP4 202.54.5.12
b=CT:1000
t=0 0
m=audio 6360 RTP/AVP 97 0 8 4 101
a=rtpmap:97 red/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

linphone で DTMF 送ると 101 だったな

HTTP Digest認証を使う時に、
cnonce等のオプションを付けて返答するか付けないで返答するかはどうやって判断するのが良いかな？
ときどき、これらのオプションが無いとエラーを返すサーバとオプションが有るとエラーを返すサーバとがあって苦労してます。

無線ＬＡＮの電波を無線機で傍受、ＰＣで変換してデータをハッキング出来る方、暗号化していてもそれを解読できる方、「ホットスポット」をピンポイントで確実に狙える方、必ずお礼はしますので、ぜひ一度メール下さい。よろしくお願いします。[email protected]

strict routingとloseroutingの違いは何でしょう？

>>454
それはDTMFだよ。

http://www.sip.or.jp/

いいからお前は IP-T の売り方必死こいて考えてろ

test

http://bb.watch.impress.co.jp/cda/news/332.html
SIP通信ソフト？

FUSIONのIP電話サービスってソフトフォンなの?ハードフォンなの?

>>464
2ちゃんねるの通信技術板のSIPってしってるかい？というスレッドに書き込んでる人間が
フュージョンの公式サイトにたどり着けないとは思えない

>465
そのサイトの、FUSION IP-Phone というのがソフトなのか
ハードなのかを聞いているとは考えないのか?

test

ACKって要るの?
TCPのsynとackじゃだめ?

TCPだけしか使ってないノカよ

H.323ならTCPだよね？

VoIP関係の資料は日本語少ないね
はぁ

だれか2ch用SIP串でも作ってあそぼーよ…っていかないよな（爆

（＾＾）

SIP串の設定詳細きぼんにゅ

http://www6.ocn.ne.jp/~endou/index2.html
　　　　　★YAHOOOプロフィール★

>>470
H.323 なら IP 使うとも書いていませんが、何か？
勧告の上では。

H.323でUDP使ってもいいし、SIPでTCP使ってもいい
それとアプリのACKとトランスポートのACKの違いがわからない奴は
ネットワークの入門書からやりなおし

>>473
siproxd
http://sourceforge.net/projects/siproxd/
ネットワークインターフェース二つ以上を使った
Linux Routerで動かすなら、これが一番設定簡単。
ドキュメントも分かりやすい。

partysip
http://www.partysip.org/
上以外なら、これも結構設定簡単。
でも
"Is there any documentation?"

"Not yet. I hope this FAQ will be useful. The first documentation will be available when the first stable version of partysip will be released."
とのこと(FAQより)

Sip Express Router
一番汎用性有り。
商業用のシステム作るならこれ。
ドキュメントも充実しているが、設定がやや難。

siproxdは、LANの中で使う用みたい。
internetに公開するつもりならSip Express Routerかpartysipかな。

わお！
ありが�d�d

とりあえず、速いマシンを借りてきたので入れてみます（しかも2CPU

>>476
SIP だと UDP/TCP/SCTP/TLS を使うと書いてあるけど・・・
後ろ２つが使える実装あるんでしょうか？

NATの中から外に繋ぐのにとりあえずlinuxでip_masq_sipっての
入れたけどこれって実際どうなの？

こんなのみつけますた。でもたかいね。
ttp://www.j-techno.co.jp/semi3/sip.htm

おまいら、今月のOpenDesign読んでみれ

JAIN SIPの実装分かる人ています？
SIP SERVLETとのからみがよく分からなくて･･････

あの痛いところに貼る奴？

　そうそう、それです。

　けっこう痛がってんですけど、どこに貼っていいのか
　わかんなくて･･････

　なんかいい情報ないですかね

その貼る奴ってコーワとかいうメーカーもありましたよね。
友達から聞いたんですがお勧めらしいですよ。

>>487
ひょっとしてこのｽﾚたてた勇気あるメーカ？

age

漏れはトクホン派

はぐれ刑事純情派

ＶＰＮとの相性は悪そうだが、どうだ？

ここで色々探すのは邪道ですか？

http://adult.misty.ne.jp/rank/enter.cgi?id=fdeai

セッションってなに？

>>494
もともとSIPは、Session Invitation Protocolとして始まった。
MBoneでのsessionにinviteするしくみだな。
SDPは、SAP (Session Announce Protocol)のbodyとして始まった。

ソフトフロント　もうダメポ

>>496
softfrontなんでもうだめなの?

ところで、SIP URIからnexthopのDNS解決の時に、
NAPTRを引かずにいきなりSRVを引くのはもう駄目なのですか？
最新状況での許容される挙動を誰か教えてください。

おいお前ら、SIPが大変ですよ
CERTｮ Advisory CA-2003-06 Multiple vulnerabilities in implementations
of the Session Initiation Protocol (SIP)
http://www.cert.org/advisories/CA-2003-06.html

>>497

社員半数カイーコ

>>499
マジでっか？、社員１人雇いたいんですけど。
SIP に明るい人間キボンヌ。

いることはいるんだけど、人数が・・・・

>>347
UAって必ずOutbound Proxyに投げなあかんの？
自分で直接相手に投げるのは禁止されとる？

>>500
SIP/VoIPに完全集中のために解雇なら意味ないやん？

>>498
ガクブル・・・

ソフトフロントどうするんだろう。
ただでさえ不況の北海道がますます沈没してしまう。もうだめぽ。

http://www.bnn-s.com/bnn/bnnMain?news_genre=2&news_cd=220011025460

>>496 >>503
ベンチャー板でも話題になってるね。
つか、情報の速さ的に関係者だろ！

http://money.2ch.net/test/read.cgi/venture/987253536/

>>497
ENUMでNAPTR(u)引いてSIP URIを得てそれをNAPTR(s)引いてSRV引いてSIP鯖を得る
はずだがなんでこんなに複雑なんや！？

すんません。あほなことを聞きますが
SIPってこれから標準化されるものと、昔からあるものとあると聞きました。
RFC3261というのは後者に属するものなのでしょうか？

>506
マジレスすると、おそらくあなたの情報が古いと思われます。
前者がRFC3261で、後者がRFC2543でしょう。

SIPに複数のセキュリティホール
http://www.zdnet.co.jp/enterprise/0302/24/epn17.html

>>508
プロトコルにホールがあるのか実装にホールがあるのか

女の股にホールがあるのか

区別つけろよ

まあ多くのじっソウニ影響があるわけで

ＮＴＴと郵政公社
http://www.asahi.com/business/column/K2003022500629.html
　　　　　　　　　　　　　　　　　
ＮＴＴの担当者に家に来てもらう必要が出た。以下は電話でのＮＴＴとのやりとりである。

「今週末に我が家に来て回線の状況を見てもらえますか」「こちらはウイークデーしかやっていません」
「えっ、では今週金曜日の１８時に」「いえ就業時間中でないと困るんです。１０時から５時の間にお願いします」
「それは仕事のある身には厳しいですね。昼休みに職場から家に戻ります。午後１時に来て下さい」
「２時にしてもらえませんか。食事を終えてから出ますので」「もしかして昼食時間は働かない規則ですか」
「実はそうなんです。それから当日ですが車で行きますので早く着いてしまうかもしれませんから家には１時３０分ごろには居て下さい」

サービス業を生業としながら今時こんな風にやっている企業も珍しい。そう思っていたらつい先日、
電話回線の事業者間接続料金値上げを総務省が検討しているような記事を紙面で見た。

冗談ではない。通信コスト低減のためには通信事業者間の競争は不可欠で、何よりも新電電の競争力は担保しなければならない。
なすべきはＮＴＴ経営陣が労働組合を巻き込んで一層の合理化、効率化に取り組むことである。
民間企業の多くは合理化の上で賃下げもやむなしという状況にある。

遅ればせながら通信事業を追いかけ郵政事業が４月から郵政公社に衣替えとなる。
民間から総裁が起用され、客の視点による郵便局窓口の改革を実現しようとする取り組みもなされている。
だが国から独立して公社となっても競争状態がなければサービス、価格はいずれ硬直したものとなる。

民営化であってもＮＴＴ回線事業のようなことになる。要は市場における価格、品質、サービスの競争を通してしか
事業は健全化しないということである。役所仕事を考えてみればよく分かる。
郵政３事業が真の意味での民営化を必要とするゆえんである。（啄木鳥）

（02/ 25 ）

TTC で SIP の日本標準を作るらしい・・・

国境のないインターネットで用いるSIPに日本標準ですか。

だれがTTCなんかに従うのでしょう？
独自拡張とかも考えていたり？

>>513
事業者間で料金情報の転送を目論んでいるらしいけど。
つまり ISUP みたいのをつくるらしい。

習慣だけで動いてる…

>>501
Outbound ProxyがRedirect Serverだった場合に、
無限ループが発生しないかな？

FirewallとかでOutbound Proxy必須のときは、
専用Proxyであればよい？

VoIPとPSTNでは課金の考え方が異なるはずだけど、
PSTNと接続する限りはPSTNに引きずられちゃう
のかな。事業者間清算をTTCがどう決めるのか
気になるところ。本当にISUPみたいになるの?
3GPPみたいなのも囲い込みみたいで嫌。

↓↓↓↓↓★ココだ★↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp/linkvp.html

>>517
インターネット利用がほぼ定額になりつつ時代、
いくら音声分の帯域確保交換接続などの付加価値をつけたところで、
呼毎に課金をするようではコストが無駄で、無料かせいぜい定額制がいいところ。

もちろん、帯域確保されないベストエフォートでの利用ならば、
現状すでにISPに頼らなくてもインターネット電話は使えているわけで。

課金情報を交換ということは、呼毎に課金をするつもり以外になにかメリットある？

そういえば、SIPのRegister Server兼Outbound/Inbound Proxy Server設置するだけで、
インターネット上の任意のところからMSメッセンジャーなどSIP対応のを使えば
手軽に初心者でもインターネット電話を使えているようですな。

RFCもドラフトもさんざん読んで数人でSIPプロトコル、スクラッチから実装して製品も出た。
だが私の千時間近い残業代は全く出ない。いまの会社に愛想が尽きたんで転職先を紹介して
くだちい。

どっか募集してないでつか？

>>520
GOTO 500

>>500
社名晒して。

>>519
dairiten.comの方でつか?

>519
費用に占める課金コストの割合って、ばかにならない数字だった気がする。
高速道路のETCと似たような問題だね。ETCいらないから料金所なくせってやつ。
でもキャリアとしては課金システムは必須と。
高速道路の場合は料金所という目に見えるボトルネックがあるから素人にも
理解しやすいけど、課金システムの面倒くささは知らないよな。

現代のような従量制課金が導入されたのは30年くらい前だったかな。
それまでは市内は1回いくらの定額制だった。電話が一般家庭に普及しはじめて、
主婦の無駄話でクロスバ交換機がパンク。で、従量制導入。
コンピュータの発達があって初めて高度な課金が可能となった。
アメリカが定額のままいけたのは、ユーザーの圧力だけじゃなくデジタル交換機
の開発が間に合ったからか？電電公社は国産に拘って遅れたからなぁ。

>>512, >>513

TTCって、日本語の翻訳規格出しているに過ぎないと思うんだが．．．
H323とかもそうでしょ

>>524
このまま10G ether主流になると、電話くらいは誤差になるとして、
DNSとSIP proxy立ててSIPアドレスさえ月100円くらいで提供すれば、
他のISPなどに依存しなくても誰でもインターネット電話できるよ？

>>526
インターネット電話同士ならできるだろうけど、
固定電話や携帯とも繋がらないと意味なし。
仲間内だけでやるならお遊び、勝手にやって。

>>527
固定電話＝おうちのインターネット電話
携帯電話＝無線LANなど利用のモバイルでのインターネット電話

どちらも繋がりますよ?? 消え行く古典電話の心配しているの??

>>528
通信相手がみんなインターネット電話使ってるわけじゃないでしょ。
既存電話網の心配をしてるわけじゃなくて、既存電話網との
相互接続を考えなきゃインターネット電話も普及しないという話。
キャリアはそれで苦労してるのですよ。

>>528
田舎の人は実感沸かないんだよ

>529
ほら、春だからさ…

でも、ブロードバンド回線が1000万以上となると、相互接続のやり方も変わって
くるような気がする。相互接続費用じゃなくてレガシーサービス維持費になったり。
携帯電話が固定電話を脅かすのとはわけが違う。携帯は電話の仲間だけどIPは違う。
今現在のNTT内部でのISDNの扱いが気になる。1年前は「世界に冠たるサービス」
と言ってたが…

>>530
賛同。既に脱既存電話の方向へ進み始めているとの認識。

既にISPなどへ支払いをしているのだから新たに費用を払う必要はなく、
一方、既存電話しか通じない相手には既存電話でしばらくの間はかければよい。

なぜインターネット電話でさらに課金を考えるのかが謎であるし、
仮に接続用ISPに依存しなくてもSIPアドレスだけ他からもらうこともできる。

>>531
相互接続のやり方既に世界的な標準としてENUMで動きつつあり、
相互接続費用というのは、ドメイン名管理と同じくDNS管理費用となっている。

>>532
数年後にはどうなってるか知らないけど、
今どうするかを考えてるんだよ。
キャリアも食ってかなきゃいけないし、
でもインターネット電話もやらなきゃいけないし、
結構これで大変なんだよ。
理想でいえばおれも呼毎課金なんてナンセンスだと
思ってるけどね。ましてや従量制なんて。

>>531
田舎の親が黒電話使ってるような状況で、
固定電話が迫害されるのも困るけどね(w
メタル全廃して光だけになれば状況変わるかな。
かんがれ、みかか

あ、TTCは今じゃなくて数年後の為にSIPを改造しようというのか？
そりゃまったく理解不能だわ。
数年後の日本人は従量制通話があった事さえ忘れてるかもしれないのに。

>533
わざわざ迫害する必要性を思いつかないが、いつかは消え去るもの。
それに、旧式だからといって市内通話を定額にできないわけじゃない。
問題は中継回線のIP化なんだが、有線放送電話はすでにIP化してたりする。

とりあえずみかかは既存の電話網にて定額制をはじめたほうがよいかもね。
それもＩＰ電話と同等もしくは若干高い価格帯で。

それで十分ってユーザも多いはず。

自分の語っている理想が何年後の話か書いておけよ

まずは、いますぐの話をしよう。

インターネットを利用してる人とは、SIPアドレスにてインターネット電話を使用。
インターネットを利用していない人とは、従来の電話のまましばらくは使用。

新たに追加費用の発生はないし、インターネットを利用していない人とも通話可能。
そのうち、みんながインターネットを利用するので、そのときに従来の電話を廃止。

おそらくその前に、インターネット電話を使用するだけで従来の電話などへも、
従来の電話の基本料金を払うよりも安く通話できるサービスが提供される。
その時点で、従来の電話の契約をやめることになると思う。

したがって、従来との電話の相互接続は必要ないし、費用もかかるので無駄。

>おそらくその前に、インターネット電話を使用するだけで従来の電話などへも、
>従来の電話の基本料金を払うよりも安く通話できるサービスが提供される。

これを相互接続って言わんか？
まあ料金についてはいろいろ思惑あるだろうけど。

おまえら、通信はライフラインだってこと忘れてないか？
今のSIPごときが、いまの電話に取って代わるだけの
信頼性があるとでも思っているのか？

電話屋さんは、よくSIPを馬鹿にしますが、
具体的にどういう機能がSIPで問題かまでは言及できません。

電話屋さんにとってはSIPの普及は理解できぬ恐怖に見えているのです。

もちろん従来の電話と同様にSIPが完璧ではないことは明らかですが、
信頼性を問題にするにしてもきちんと明示しないと誰も納得しません。

>電話屋さんは、よくSIPを馬鹿にしますが、
>具体的にどういう機能がSIPで問題かまでは言及できません。
そういうおまえも電話屋だよ。
インターネット屋さんは、たかが電話ごときSIPでもH.323でもなんでもいいんだよ。

>>540
電話屋を馬鹿にしてるだろ。
H.323とかRFC 3261程度なら普通に理解してるぞ。
それぞれのプロトコルスタック実装したり、変換器つくったり。

で、SIPの話なんだが、
緊急通報(119など)の発信に十分利用できるとおもうか？
災害時などの輻輳制御は十分に検討されているか？

電話屋を馬鹿にするんなら、せめて、
電話に求められる品質や要求仕様を理解してからにするんだな。

　　　　　　　　　　　　　∩
　　　 　 　 ∧＿∧ 　　| |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　 （　 ´Д｀）／/　　＜　先生！こんなのを発見シマスタ！
　　　　　 ／ 　 　 　 /　　　　｜
　　　　 / /|　　　　/　　　　　　＼ 　http://saitama.gasuki.com/aomori/
　 ＿＿| | .|　　　　| 　　　　　　　 ＼
　 ＼　 ￣￣￣￣￣￣￣＼ 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　||＼　　　　　　　　　　 　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

>>542
>緊急通報(119など)の発信に十分利用できるとおもうか？
>災害時などの輻輳制御は十分に検討されているか？

「呼び戻し」実装なしなら・・・、とおもったけでやっぱ
むりか。「呼び戻し」は携帯では実装あったんだっけ？なか
ったと思うけど。

>電話屋を馬鹿にするんなら、せめて、
>電話に求められる品質や要求仕様を理解してからにするんだな。

それだけの為に電話網維持するカネを誰が出してくれるか大いに
疑問に思う今日この頃。みかか地域さん、電話定額制始めないと
マジでじり貧ですよ。

電話屋の最後の世代として、SIP の Call Control だけは
握っておきたいなぁ。これさえ握り続ければまだ他のサービス
への展開もありそう（ないかもしれんけど）。一般ユーザが
直接 DNS 叩いて通話始めたら、電話屋は完全廃業です（藁。

>>544
私はべつに５４２じゃないけど、そのような意見は３−４年前にたくさん
聞きました。が、どうも社会インフラとしての音声通話は単純に
ＶｏＩＰで音声の上に乗っければＯＫというものではなさそうではない、
というのが最近の流れっぽいです。はい。

>>545
「ユニバーサルサービス基金」ですか？
税金かそれに類するところからお金を引っ張るしかなさそう
ですね。

>私はべつに５４２じゃないけど、そのような意見は３−４年前にたくさん
>聞きました。が、どうも社会インフラとしての音声通話は単純に
3~4年前ならともかく、いまどき社会インフラはインターネットで、音声通話じゃなくなりつつありますが？
>というのが最近の流れっぽいです。
どこでの流れでしょう？NTT?総務省？

http://bbs.1oku.com/bbs/bbs.phtml?id=rantyan
★その目で確認すべし！！★超おすすめ★

つーかざっくりリストラすればNTTだって定額制にできるのに。新技術も税金もいらない。
そうなるとアメリカみたいにADSL普及速度が鈍ることだってありえる。

でもどうあがいても最終的にはIPになっちゃうんだから、今のままマターリ定年を
待つのもいいかもね。定額を求める人はすでにADSLにいってるのだし。

>でもどうあがいても最終的にはIPになっちゃうんだから、今のままマターリ定年を
>待つのもいいかもね。
というか、どうあがいても最終的にはNTTは再国有化、清算事業団化なんで、マターリしてれば？
>定額を求める人はすでにADSLにいってるのだし。
インターネット接続に定額を求めてた人は、そうだな。
今後は残りの連中が定額の電話を求めてADSLにいくことになる。

>>544
「それだけの為」？
電気通信事業法でも嫁。
>>539でも書いたが、電話網はライフラインなんだよ。

もちろん、技術屋はVoIPで十分な品質を確保できるように
日夜努力しているわけだが・・・

↓↓↓↓↓★ピンクエンジェル★↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp/linkvp.html

>>551
自分のドメインでSIPサーバを上げてユーザにサービスしたら、
電気通信事業法に抵触しますか？

>>544
その呼び戻しというのは、携帯電話でいうところの、
発信者番号通知された番号へかければ相手が移動しても大丈夫に相当しますか？

>>553
前半
提供する内容とユーザによるだろ。
っつか、電気通信事業法なんて日本語で書かれてるんだから嫁。

後半
相当しない。
緊急通報ってのは、発側から呼解放できなくなってるの。
わかりやすく言えば、かけた方の受話器を置いても回線は切れないってこと。
(ハンドセットをおいたら呼び出しベルがなり続ける)

ちなみに、SIPでは切断を拒否する手段は今のところは無い・・・と思う(^^;

>>554
固定電話より普及しつつある携帯電話においても実現できていない呼の維持を、
どうしてインターネット電話においても実現しないといけないのですか？

携帯電話と同様に、発信者へコールバックするだけで十分ではないですか？
インターネットで呼の維持をしようとしても、擬似的なものになって、
実際にはコールバックと変わらなくなると思うのですが間違ってますか？

意思決定するのは技術を解ってる人だけじゃないからね。
技術的に無理でもその人たちを納得させるのが難しい時もある。
無理だと解っていてもやらなきゃいけない。
インターネットのように技術主導で成長してきたのと、
進化が止まって過去にしがみつくしかない既存電話じゃ、
考え方が違い過ぎる。
それでもだいぶ変わってきたんだよ。

>>555
>インターネットで呼の維持をしようとしても、擬似的なものになって、

re-Invite で実装しましょう（ネタです）。

>557
話はずれるが、re-invite実装してるクライアントある？
あったらおしえてホスィ。

あ、サーバ側の対応も必要か。

>556
技術先導は電話も同じなのにね。
電話がコネクション型なのは警察や消防の要請ではなく、グラハム・ベルの時代の技術の制約。
電話の強みはその方式にあるのではなく、社会に認知され技術が枯れきっている事。
ライフラインという言葉が発明されるはるか以前に完成していた。

B-ISDNになると局給電できないけど、NTTはどうするつもりだったのか。
「B-ISDNは電話ではない！」でいいの？ライフラインとか言うなら停電時でも使えるのは
かなり素晴らしいけど。

輻輳制御はSIPの出番じゃないだろ。SIPだけではどうにもならないし。
公的機関は自前の通信網を用意するのが良いと思う。通信機器が桁外れに安いのだから。
yahooがNTTに払ってる暗ファイバとコロケ費用を考えれば、今より安くなるはず。

>>558
呼転送をサポートしているUAは、当然ながらreinviteもサポート
してますよ。pingtel他たくさん。
実装初心者さんでつか？

>>555
「どうして？」て聞かれても、
「緊急通報には必要だから」としか答えようが無いんだが？
携帯電話を緊急通報に利用することはあまり推奨されていないことは
しっているか？なるべく固定電話を使え。
固定電話の重要性をちょっとでいいから理解してやれ。

>>560
シグナリングで輻輳制御できなけりゃどのレイヤでやれと？
輻輳時のアナウンスや網としての輻輳制御なんかはせんといかんだろ。
独自網はいいんだが、各家庭までその網を張るわけにゃいかんだろ？

ライフラインにどれだけコストをかけてもよいかは562が決める事じゃない。
定額課金のIP電話がそこそこの信頼性を得た段階で、緊急時の安心のため
だけに固定電話に毎月3k払うか?

...んま、俺は払うけどな。少なくとも俺の書いたコードが動いてる電話機
しかないなどとなったら夜安心して眠れんわ(稿

>>563
いまいち意味不明・・・。
電話網は国が国民の権利を守るために整備しているんだぞ？
コストをかけてよいかどうかは論点ではないはずだが・・・

「SIPでインターネットで電話安い〜!!」
とだけ騒いでも、結局は移行なんてできない罠。


後半に関して、気持ちは激しくわかるんだが、
「局用交換機」開発に携わったやつにどうしろと？(w

>電話網は国が国民の権利を守るために整備しているんだぞ？
気のせいです。

>>562
緊急通報には必要だからといっても、対応の仕方として
既存の固定電話では適していた概念や手法を、
そのまま携帯電話やインターネット電話に持ってくるのは
無理だったり意味がなかったりするんじゃないかしら？

おっしゃってる発側から呼解放できないっていうのは、
そもそも回線交換モデルでの概念でしょ？

インターネットにおいてもそれらを忠実に再現しないといけないのはどうしてなの？

緊急通報ってのは生命にかかわる。
一分どころか一秒だってあらそうこともある。

輻輳制御で具体例をだすなら、
アイドルグループのチケット予約日に救急車呼べないとか。

切断のほうは良い例が思いつかないがこんな感じ。
電話をかける。緊急通報の内容を告げる。場所をなのる。名前を・・
ってのが緊急通報の手順だと思うが何らかの理由で呼が切断されたとする。
(あわてて電話機を落としたとか、上から物が降ってきたとか)
電話をもう一度かける。お互い相手が先ほどの相手だとは限らないので、
もう一度はじめから手順を踏むことに・・・。
災害などの広範囲な緊急時なら回線が輻輳がちになり、もう最悪。

違う面からいえば、緊急通報はすべて集計されているんだが、
一度つながった呼が解放されてしまうと緊急通報に対する対応率が
どんどん役に立たないものになってしまう可能性もあり、
公共性に問題が生じる可能性もある。
(緊急電話を無視するようなとんでもない奴がいても発見しづらい)

同一の実装にする必要は無いと思うが、本来の緊急通報の目的が
達成できないと乗り換えはむりってこと。

>>565
言いたいことはよくわかる。(w
が、ネタのつもりじゃないなら電気通信事業法よめ。

東ガスの事例では、NTTデータの松田さんの記事を見ると
110/119はそれ専用のGWにリダイレクトされるように見え
ますな。家庭ではこうはいかないけども。

>>567
切断のほうの例のお話だと、再び同じ相手と通信できることが目的？

単に通報者側でBYEできなくなっていれば、電話機を落としても問題なさそう。
SIPもRTPも状態維持されれば、発側から呼解放できない仕様を満たしますよね。

>>568
東ガスの事例の記事って、どこで見れるかしら。

輻輳管理もいいんだけどCACを実装してるところある？
H.323ですらまともにやってるところ少なかったように記憶してるがどうよ

「ＩＰ電話マンセ〜！！」と言って色々な所が某国の市民よろしく
両手上げて突っ走っている中でこういう話題になるってのもいいねぇ。
いずれは出て来ると思ってた避けて通れない話だし。

>>554さんが書いていた↓ですが、
>緊急通報ってのは、発側から呼解放できなくなってるの。
>わかりやすく言えば、かけた方の受話器を置いても回線は切れないってこと。
>(ハンドセットをおいたら呼び出しベルがなり続ける)

１１０番／１１９番におけるこの機能は、
交換機内のFPT(Fire Police Trunk)と呼ばれる部分の機能により実現されます。
(クロスバ交換機では回路としてあったのでしょうが、デジタル交換機では？？)

実はホテルや旅館などに設置される火災通報装置↓もこの仕組みを利用して、
http://www.taiko-ew.co.jp/security/sde204f.html
通報終了後に一度回線を切断し、消防署側からの呼び返し(逆信)を待ちます。
(通報装置側から切断するが、交換機側で保持してるのですぐに呼び返し出来る)
呼び返しして通報者と会話したり、通報確受ランプを点灯するのに使用されます。

連続カキコスマソ。長くなったので一旦切りますた。

この通報装置はISDNでは動かない事になっていたのですが
(逆信や回線保留、優先発信機能が普通のISDN用TAに実装されていない為)
それをわざわざ実装した火災通報装置用TAというのがあります。
(商品ページが消えてしまったのでぐぐったキャッシュで勘弁下さい)
http://www.google.com/search?q=cache:6SXfPw825BcC:www.taiko-ew.co.jp/information/tat/ta_t.htm+%E7%81%AB%E7%81%BD%E9%80%9A%E5%A0%B1%E8%A3%85%E7%BD%AE+TA&hl=ja&ie=UTF-8

もし同じ仕組みをＩＰ電話でやろうとするならば…ですが、
下位レイヤの仕組みからして違うのにそこまで実装しきれるか？
そこまで実装しても莫大にコストがかかるのでは？と様々な課題があるでしょう。
もしくは、緊急通報／緊急通話の形を変える事で解決する方法もあるでしょう…
簡単なのは今の電話回線が１１０番／１１９番専用になるとか（ｗ
ＳＩＰと関係無い話になってしまってスマソ。逝って来ます…

朝から盛り上がってますねぇｗ

http://www.agemasukudasai.com/bloom/

>輻輳制御で具体例をだすなら、
>アイドルグループのチケット予約日に救急車呼べないとか。

…。

>>570
CACって？

>>572
ISDN自体は、逆信や回線保留や優先発信機能をサポートしているってこと？
そのへんの普通のISDN用TAでサポートしていないのはどの機能？

>>571
『通報終了後に一度回線を切断し、消防署側からの呼び返し(逆信)を待ちます』
というのは、SIPとRTPで考えると、消防署側からSIPで通報者のIPアドレスへ
発呼すればいいということだろうか？

　　　　　　　　　　　　　∩
　　　 　 　 ∧＿∧ 　　| |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　 （　 ´Д｀）／/　　＜　先生！こんなのを発見シマスタ！
　　　　　 ／ 　 　 　 /　　　　｜
　　　　 / /|　　　　/　　　　　　＼ 　http://saitama.gasuki.com/hiroyuki/
　 ＿＿| | .|　　　　| 　　　　　　　 ＼
　 ＼　 ￣￣￣￣￣￣￣＼ 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　||＼　　　　　　　　　　 　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

おつかれさまでした>ALL

−−−−ＩＮＶＩＴＥ−−−→

<--- 193 Stalking ----

--- CANCEL ---->

http://www.f-cc.com/~momonga/

>>577
>ISDN自体は、逆信や回線保留や優先発信機能をサポートしているってこと？
>そのへんの普通のISDN用TAでサポートしていないのはどの機能？

その逆で、ISDN自体がそういう機能をサポートしているのではなくて、
普通のISDN用TAがサポートしてない上記の機能をこの専用TAが模倣しています。
>>572 ぐぐったキャッシュ先参照
>デジタル（ＩＮＳネット６４）回線を用いてアナログ回線と同じ仕様で
>運用できます。（逆信、回線保留、優先発信機能は、通常のＴＡではできません）

優先発信機能は実装しているTAがかなり多いと思います。
(Bチャネルに空きが無い時は110/119通報を優先し他の呼を切断するってやつ)
逆信は回線保留は普通のTAでは絶対無理でしょうね。
これは流石に通報装置とペアで動くTAだからこそ出来るんでしょうけど…。
(その為に通報装置から起動信号をもらうようになってます)

ちなみにNTT東日本の資料は↓
http://www.ntt-east.co.jp/ISDN/tech/spec/tsuika/pdf/118tuiki3-17.pdf
これを見ると緊急電話の番号に118(海上保安庁)も増えたんだったね…。

>というのは、SIPとRTPで考えると、消防署側からSIPで通報者のIPアドレスへ
はその通りで問題無いかと思います。

この手の話題は何もSIPに限った事じゃないから、通信行政板の方が適切なのかな…。

まあここではSIP/RTPベースで考えるとして、
優先発信機能というのはチャネルもないのでインターネットでは対象外だろうか。

逆信というのは相手のIPアドレスもわかってるので逆向きにSIP/RTPするだけだな。

回線保留というのは切っても実は切れていないという話だが、
回線交換でないインターネットで意味があるのかどうか謎だ。

やはり、>>567のいうアイドルグループとの戦いのほうが重要かもしれん。
ようするに、アイドルグループよりも優先して扱う機構が実現できるか、だ。

チケット買わないから世間がどうなっているのか知らないんだけど、ぴあなどは
21世紀になっても交換機を介した人間同士の通話しか予約する手段が無いのでせうか
人海戦術のほうが安いのだろうか

>>586
21世紀は「交換機を介した」ではなく「SIP Proxyを介した呼で通話は直接」です

>>569
端末が電話先の種別を覚えておくとコストがかかる。
電話の例で言えば、端末の数と交換機の数考えてみろ。
電話番号追加(118)とかあったときにこまるだろ。
ちなみに、切断だけの話ならいいんだが、
緊急通報かどうかまで端末側の判断を行うつもりなら論外。

>>577
電話の発信元に向かって電話がつながる保障なんてないだろ。
「緊急通報の場合、発側からの切断ではダイアログはクローズしない」
みたいな実装しないかぎり呼び返しなんてできねぇ。
もうちょとセキュリティにも気を使え。

>>588
オンフックでBYEを出さなければ良いだけ

>>589
はぁ? そんなことしたら普段から電話切れねーだろ。(w
かけた電話番号が緊急用かどうかの判断が必要になるだろ。
そんなデータベースがネット上にあるわけでもなし、
端末で勝手に判断すりゃ電話番号増えたときに対応できねーし。

> かけた電話番号が緊急用かどうかの判断が必要になる
判断すりゃええんちゃう？
> そんなデータベースがネット上にあるわけでもなし
つくればええんちゃう？

>>591
なんか話がずれてるな。
そんなことしても緊急通報でもなんでもないんだが・・・・
そんなよくわからんデータベースをわざわざ作って
メンテナンスしていくメリットってなにかあるのか？
結局、なにがやりたいんだ？>591

>そんなことしても緊急通報でもなんでもないんだが・・・・
の部分が理解できません

>>593
ちったぁ自分で考えろよ。

緊急通報ってのは、国民の生命、財産、権利などを守るため、
優先的に取り扱うことを目的とするためのもんなんだよ。

端末が勝手に「この通信は優先してね〜」ってほざいても
誰が信用するんだよ。
自発的な切断が無くとも網の一時的な異常とか
攻撃とかで切断されると役にたたんだろ。

「(見かけ上)切れても復旧できる」ことが重要なの。

>>594
宛先が緊急通報だったら信用すればいいのでは？
データベース方式でもなんでもいいけどインターネット上なら簡単

話題のここです
http://homepage3.nifty.com/digikei/

同人屋の次はうにょでつか

緊急通話の仕組みって世界共通？いつ頃から今のやり方になったの？

>>598
番号を始めとしてなにもかもばらばら。
日本はサービス少なすぎ。

お隣の国だと火災通報と並んでスパイ通報にも番号がある。
別のお隣の国にはガス漏れ通報にも特番がある。

　　　　　　　　　　　　　∩
　　　 　 　 ∧＿∧ 　　| |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　 （　 ´Д｀）／/　　＜　先生！こんなのを発見シマスタ！
　　　　　 ／ 　 　 　 /　　　　｜
　　　　 / /|　　　　/　　　　　　＼ 　http://saitama.gasuki.com/sinagawa/
　 ＿＿| | .|　　　　| 　　　　　　　 ＼
　 ＼　 ￣￣￣￣￣￣￣＼ 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　||＼　　　　　　　　　　 　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

>この通報装置はISDNでは動かない事になっていたのですが
って、一時はもういらんと認められてたってことじゃん。
それをいまさら持ち出してきて電話網存続の理由にするのは、いくらなんでも強弁がすぎるぞ。
ITU-T標準のH.323でできるんだったらまだしもな。
どうしてもこういうのにこだわるんだったら、RFC748でも嫁。

http://members.tripod.co.jp/coli2/linkrenai.htm

か

>601
この期に及んで電話網が存続できると考えているお目出度い奴はいないと思われ。
でも市内定額にしてしまえば、IP化は数年遅れることになるかもしれん。
テレビ電話などをやるつもりがないなら、電話でも機能は十分すぎる。
NTTは延命したけりゃ定額にしろ。収入減っても交換機の償却期間は稼げる。

>この期に及んで電話網が存続できると考えているお目出度い奴はいないと思われ。
まだ３年くらいはもつと考えてるお目出度い奴はいると思われ。
>でも市内定額にしてしまえば、IP化は数年遅れることになるかもしれん。
長距離まで定額にしないと対抗にもなんにもならんが、市内定額を口実に基本料金値上げして、
ＡＤＳＬと心中するのがほんとの狙いか？
総務省は許しても、世間とアメリカは許さんと思われ。

ハァ？どう足掻いても結局はADSLと心中する事になる。
ADSLが終わる時に銅線の時代も終わるのだから。

根拠があるなら基本料値上げ大いに結構。100円上げれば年間720億円の増益だ。
だが根拠が激しく不透明なADSLの回線使用料は値下げするべきだ。
プッシュ回線使用料390円も異常だな。

市内定額になると、相互接続料はどう計算するのかな？

>>512-525 にあるように、SIPで料金情報を送るらしいよ

ISP依存のライフラインなんて終わってると思うんだけど
二重障害すら考慮してないISPなんていくらでもあるのに

NTTが生き残るかどうかはともかく、電話網はあと30年は安泰

>607
誰が使うんでしょうね。それをサポートしてない機械は接続禁止？

>608
30年？銅線の寿命からしてありえない。銅線と光ファイバーのコストはすでに
並んでいるので、銅線が錆びれば光に置き換えられる。

ISPって、ダイヤルアップもyahooもusenもCATVも地域IP網もいっしょくたですか。

>>595
「簡単」ときたか・・はぁ、ちっとは考えろよ。

>>601
零細企業の製品がINS対応が遅かっただけで
ISDNの存在否定にまで発展させたお前をすごいと思ったよ。
どうでもいいが、RFC 748くらい理解しろよ、ど素人。

>>609
電話網＝銅線ではないと思われ。
回線交換網と言い換えたほうが良くないか？>>608

>609
ネタだろ
NTTがあと9年でIPにすると言ってる。新規投資はすでに無い。
維持のことを考えると9年は長い。誰が、どうやって、維持するのか…

http://pc.2ch.net/test/read.cgi/network/990585819/426
これどうなってるの。SIP-Tは？

>>611
「事業者間料金精算方式検討会」ってなにもの？
SIPで国内の料金精算するのを決めようとしているのはTTCではなく？

>>610
ITU-TとIETFがENUMですべて置き換えようとしてるのが世界の流れですな

>>612
どこでそんなもの流れているんですか？

ENUM を何で使わなきゃいけないの？
DNS でやるんだったらわざわざ電話番号なんて使わなくても
よいがな。この辺 ENUM っていまいち存在意義がよくわから
ない。

ITU から見れば全部 DNS でやられるとまずいんで ENUM と
いうのは存在意義ありなんです。

宣伝書き込みーですー。
２ちゃんねるっぽい、２ちゃんねるに似た、２ちゃんねるのようなの作りましたー
板がいろいろあります、、、過疎板も。。
http://zeta.ns.tc/
どうかな？
いいかな？

ぜんぜん２ちゃんぽくない
明日で消滅すんからね

亀レスでスマソ。今日の日経ITニュースを見ていたら
まるでここの住人が書いたんじゃないかと思えるようなタイムリーな話題が。
http://it.nikkei.co.jp/it/njh/njh.cfm
住人の該当者はfusianasanしてみて下さい(誰もしないって)。

漏れは維持費用が莫大な交換機はいい加減廃棄されても仕方無いと思う。
現にNTTはノーテル製DMS-10を2003年度以降順次廃棄すると発表↓
http://www.asahi.com/tech/nikkanko/K2003010300030.html
これよりも20年選手なD60、D70系は特に尚更問題だろう。

だが、交換機が廃棄されたとしても後釜はどうする！？となった時に、
ユニバーサルサービス(特に緊急通報)を代替し得る技術はあるのか！？と。
現在の所、IP電話で全部巻き取れる訳では無いのに誰もがIP電話マンセーと
突っ走っている現状を見ていると、ただ突っ走るだけで良いのかと。
早急に空いてしまう溝を補完出来るような技術やシステム作りをしなければ
まずいんじゃないんでしょうか…。>>601みたいな香具師が居る限りは無理か（ｗ

>610
同人屋さん久しぶりー
元気だった？

>>617
?ｽﾏｿ
人違いでは？

>>613
電話番号→URIをDNSでやる方法が、まさにENUMなのですが。
ENUMのことをちゃんと理解してる？

もちろん、数字の電話番号にいつもでもこだわるべきか、というのは別途ある。

★ココで決まり★男の掲示板★大人のリンク集★
　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓
　http://www.pink-angel.jp/betu/index.html

>616
新ノードでさえ3年なのか…
C&Wは出ていっちゃうし。マイラインの時点での決まってたのかもしれないが。
中国では今でも固定電話が急成長中らしいが、どこの交換機使ってるのだろう。

日経の記事はバックナンバーに移動してる。
http://it.nikkei.co.jp/it/njh/njh.cfm?i=20030314s2000s2
>現在の所、IP電話で全部巻き取れる訳では無いのに誰もがIP電話マンセーと
國領氏は携帯があるだろって言ってるな。
固定電話の延命より、携帯とIP電話の組み合わせのほうが合理的だ。
携帯キャリアは大喜びでやるだろう。
そのサイトの翌日の記事は韓国の暴走っぷりについてだが、
http://it.nikkei.co.jp/it/njh/njh.cfm?i=20030317s2000s2
携帯の可能性に文句はないだろ。固定電話だとLモード止まりｗ
しかし、誰か止める奴はいなかったのか韓国…

韓国の緊急通話には、コンピュータウィルスにやられた時に通報する番号も
あるってホントか。通報されてもどうしようもないだろうに…

age

　　 ,.´ / Vヽヽ
　　　 ! i iﾉﾉﾘ）) 〉
　　　 i l l.´ヮ｀ﾉﾘ　＜先生！こんなのがありました！
　　　 l く/_只ヽ 　　　
　　|￣￣￣￣￣|
http://saitama.gasuki.com/aomori/

サンプルムービー集
http://homepage3.nifty.com/digikei/
アップローダーはここ
画像http://www.pink-angel.jp/imgbbs2/imgboard.cgi
動画http://mav.nifty.com/ahp/mav.cgi?place=digikei&no=3727

最新の音楽情報満載。音楽ファン必見のサイト
音楽ギフト券の全プレあり
http://camellia16.fc2web.com/ongakudb.html

>>1
サロン

>>621
韓国ではスパイ通報センターが118番ですな。特番は国によって様々。

IP電話どうこう以前に、固定電話は携帯電話によって駆逐されつつあるので、
IP電話に回線保留機能がないとかいう以前に、携帯電話はどうするんだろう？

ようするに通報者がが受話器をおろしても回線が維持されるという機能は、
回線交換時代の名残りにすぎないと思われ。発信者番号通知があれば、
折り返しかければいいだけのことで、携帯電話ではそういう認識で運用。

そもそもSIPなどで回線保留をしようとしても、IP電話の通話自体には
SIPは関与せずにend to endでRTPのパケットが流れているだけなので、
携帯電話と同様に、そういう環境にて回線保留機能ってナニ？

>>627
end to endで直接IP通信ができる保証なんて何処にも無いわけだが？
そもそも、SIPにおける発信者電話番号なんてものが保証されないぞ？
閉じた世界の回線交換方式の携帯電話と比べられてもねぇ。

・・・コールバックを使った高優先のDoSアタックとかできそうだな。(w

　　∧＿∧
　　( ´;^;ё;^;)＜これからも僕を殺して下さいね( ´;^;ё;^;)。
＝〔~∪￣￣〕
＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　デブおた山崎渉

>受話器をおろしても回線が維持されるという機能は、回線交換時代の名残り

盲腸みたいに言うな。できないほうがおかしい。

>通話自体にはSIPは関与せずにend to endでRTPのパケットが流れているだけ

だからSIPは欠陥プロトコル。完全なQoS無しに緊急通話はできん。

おこってる？
ここで癒されてください
http://www.medianetjapan.com/2/16/internet_computer/goldenrich/

>>628
電話番号なんて古くさいものが必要なんですか？
メールですら、ユーザ＠ドメインですよ？音声やりとりも同じ。

>>632
はぁ？
日本語よめねーのか。そんなことが論点じゃねーだろ。ぼけ。


一応 マジレスしといてやるが、
電話の乗せ替えなら、電話番号は必須だろ。
今までの電話番号どうするんだよ。世界中同時にSIPに乗り換えるとか
おめでたいことほざくんじゃないだろうな。
なんのためにENUMなんてものが議論されてると思ってんだ？

番号ポータビリティって日本人にはSFの世界の技術だなぁ。

>>633
ENUMによって電話番号が何に変換されるか御存知ないんですかー！？

>>635
ユーザビリティ考えろ。
変換後がどうのとか言ってると全部「電気信号」で終わりだろ。

変換後がどうであれ利用客にとっては、「電話番号」なんだよ。

>>636
もう、基本は sip:user@domain URIになっています。

電話番号しか使えない旧ユーザからも電話がほしい人は、
ENUM service providerから電話番号を割り当ててもらって、
自分の sip:user@domain URIを登録してもらいます。

これで、黒電話からも sip:user@domainへと電話がかかるというしくみです。
もはや電話番号は飽くまでも旧ユーザとの通話のためだけの存在になっています。

一方、sip:user@domain URIを持つインターネット利用者は、
もちろん通話だけでなく文字や映像など多彩なコミュニケーションができます。

>>637
「基本は」ってより、「SIP上は」ってことだよな？

現状は電話番号が割り当たってないから仕方なく使ってるだけで、
電話番号がちゃんと割り当てられたら
SIP URIより電話番号のほうが使われると思うんだが。
英数字より数字だけのほうが入力インタフェース簡単だろ。

ついでに突っ込んでおくと、ENUM使ってても
音声以外のコミュニケーションに対してなんら制限は無いが？
レイヤの違う話題を一緒くたに並べるのは辞めねーか？

メールでも、user＠domain使ってますよー。
数字の方が覚えにくいし、どうせ知合いのは登録しちゃうから数字のメリットなし。

★あなたのお悩み解決致します！！
●浮気素行調査
彼氏、彼女、妻、夫の浮気を調査致します！！
●盗聴器盗撮機発見
あなたの部屋に誰かが仕掛けているかも！！
●行方調査
行方不明になっている家族の消息を調査致します！！
●電話番号から住所割り出し
一般電話、携帯から住所を割り出し致します！！
●ストーカー対策
社会問題ともなっているストーカーを撃退致します！！
その他人生相談からどんなお悩みでも解決いたします！！
　直通　　０９０−８５０５−３０８６
ＵＲＬ　　http://www.h5.dion.ne.jp/~grobal/
メール　　[email protected]
　　　グローバル探偵事務局　

>>639
メールと電話を同列に扱う奴、最近増えてきたな・・・

メールは文字を伝えるもんなんだから、あて先が文字でも問題ない。
( 文字入力できない環境でメールが使われることはほとんど無いだろう )

だが、音声通信ではそうはいかん。
電話かけるのにキーボードを打つ事が当たり前だと思うのか？
登録するも何も、業者などの新規のところに電話するときはどうするんだ。

電話番号で十分便利だし問題も無い。
世界中に広まった文化をわざわざ覆すメリットなんて無いんだよ。
SIP URIを使うなとはいわんが、電話番号を否定するのはただの馬鹿だよ。

http://f-cc.com/~momonga/

>>641
初めてのお店にかける時でも、クリックするだけですよー。
かける先のお店などの情報もインターネットで入手しますよね。

電話番号を否定したのって誰だろう
user@domainを頑なに否定してる奴ならいるが

>>644
電話番号を否定したのは >>639

user@domainを否定してる馬鹿はどこ？

インターネット利用できるユーザは基本的にはSIP URIを使って、
どうしても旧来の電話番号を持たないと困る人は、
ENUMサービスプロバイダー(ESP)にお願いすればいいのでは？

ESPが電話番号からSIP URIへの変換のDNSを持ってくれるわけでしょ？
ようするに電話番号は補助的に使う一種のaliasみたいなものね。

クリック先でこのように表示されます。
http://makiyumi.nonejunk.com/

>>643
だから普通の電話機でどうやってクリックするんだい？
(話の流れわかってる？)

いまどき携帯電話ですらクリックできてるぞ

２１世紀になっても黒電話つかってる奴だけせっせと番号まわせばよい
数字番号ユーザからの電話でもＥＮＵＭのおかげで電話できるだろう
もちろんクリックもできない黒電話からは音声のみに限定されるだろうがな

>>649
「IPネットワーク技術に関する研究会」に言ってみれば？ 050番は必要ないって。

>>650はスレの流れが見えてないのだろうか？？
あるいはみんなが言及しているENUMで050番号も含めて扱うことを知らない？？

>>651
どっちも分かってるつもりだよ。
ライフラインとして回線保留の実装の話をしてたところに
632で電話番号（数番）が必要なの？って話がでてきた。
そんなのここで議論するまでもないでしょ。
このスレの見解じゃなく、総務省が必要だと思ってるってこと。
電話番号が必要ないっていうなら、ENUMは必要ないじゃん。

まあ、ログを読んでなかったんだろうけど
一般家庭の固定電話がIP電話に置き換わるという大筋の流れも無視してる。
637の「文字や映像など多彩なコミュニケーションができます」ってズレ過ぎだよ。

SIPスレッドとしては間違った話題じゃないけどね。

おまえらアマアマだねｗ

どうでもいいが、ID消すのって流行か？
誰が発言してるのかわかりづらくなるからやめれ？

田舎のおじいちゃんおばあちゃんは黒電話しか持ってなくて、
東京の孫の声が聞きたくて電話を掛けようと思うけど、
馬鹿息子から教えられたのは「user@domain」なのでした。
おじいちゃんおばあちゃんは電話が掛かってくるのをただじっと
待つことしかできませんでした…

Lモードでも入れるかね。

>>649
馬鹿を相手するのもいい加減飽きてきたんだが・・・・

「クリックできない→音声のみ」？あほか。
SIP関連のWGでどんな利用方法が議論されてるかくらい読んでから書け。

固定電話→IP電話は絵に描いた餅。むりやりIP電話に機能を追加するとデジタル放送
の二の舞。

NTTの計画では交換機のIP化が9年以内で、でもちゃんと維持できるのはあと3年だっけ。
IP化といってもスイッチによるコネクションレスネットワークではないのだろうから、
劇的なコストダウンは望めない。その程度のものを本当に導入するか？

アナログテレビと交換機は今後消滅するまで現状維持で、デジタル放送とIP網は
以前の経緯を無視して開発していくべきだと思う。

>>657
はいはい。
総務省まで動いてる決定事項に対して文句をたれて面白いのか？
そんなことはとっくに議論され尽くされてるんだよ。
後半部分に関しては理由も書いてないし、もう世間知らずの馬鹿としか・・・・

さらしage

NTTの計画やみなさんの色々な立場は知らないけど、同じことを二つの見方で表現できると思う。

一つは従来のPSTN網を基準とした見方で、PSTN網ユーザからするとSIP URIなんていうのは当然指定できない。
でも050-番号ならば指定できるし、ENUMによって050-番号→SIP URIというのは
PSTN網ユーザからは見えずに意識すること無く利用できるので問題なしということ。

もう一つは基準のほうをインターネット利用者においた見方。
当然ながらお互いの通信はSIP URI(メールだとmailto URI)で行なう。
ただしこれだとPSTN網ユーザへかけたりPSTN網ユーザからかかってきたりできない。
かけてもらう方は上述と同じことになるわけだけど、
インターネット利用者の視点からはSIP URIの別名のような補助的なものとして
050-番号を割り当ててもらって用いる。マッピングは上述と同じENUM。
PSTN網ユーザへかけるほうも、いくつか方法があるわけだけど、
例えばTEL URIで古典的な数字の電話番号を指定して、
自分あるいはproxyかgatewayか運用は色々あるけどENUMで最終gatewayのURIを得る等。

だから、みなさん両者の言ってることは同じで、どちらも正しいと思う。

ENUMは駄目でしょ。ゲートウェイを指定するのが着呼側なんで。
今後はインターネットからPSTNへのゲートウェイは多数存在することになり、着呼側は全部列挙しきれない。
金払うのは発呼側なので、発呼側にとって最も安いゲートウェイを選択できないのでは、誰も納得しない。

http://www.agemasukudasai.com/bloom/

>>660
色々なモデルが考えられてるよ。
例えば、インターネット電話の一般通信は無料か定額。
非インターネット電話側のみ発着料金負担というモデル。

もちろん、誰か上の方で書いていたように一気に電話網は設備が維持されなくなり、
非インターネット電話側というのが存在するのは極短い期間だけかもしれない。

さらに、多くのISPが予想しているように、せいぜい64Kbpsしか帯域を占めない
通話というのは全体から見るとトラフィック的に誤差になるとの見込み。

従量課金システム構築によるコスト増との比較で、
定額制にもっていったプロバイダの方が有利になるとの話もよく聞く。

>>662
同意。
で、>>512-になっちゃうのはなぜなんだろうねぇ
という流れなのかなこのスレは。
SIPに余計なものを追加して何がやりたいのか分からん。

お前らこれからはCTI抜きにSIPは語れない
とボケをかましてみるテスト

http://218.44.246.37/~2ch/

CTIってなあに？

>>664
セントレックススレへ GO!!

http://pc.2ch.net/test/read.cgi/network/1033576806/l50

管理や規模の面での考慮は必要だが、
基本的にはそこらへんのPCにてメールサーバ運用できるように、
インターネット電話においても特殊な設備を必要としなくなっている。
（もちろん、既存電話網との接続は、サービス契約で外に出すと仮定。）

既存の物を残しつつ移行しようとしてるところほど、
その度合いに応じて費用もかかっているというのが現状であるのも事実。

設計や設備面だけでなく、課金の考え方についても同様。
既存の物にとらわれて依存する方法ほど費用が桁違いになっているのが現状。

もちろん、考え方を切替られない顧客に対して、
複雑なシステムを売り付けることができるチャンスがあるのも否定しない。

エロ画像求む
http://homepage3.nifty.com/digikei/

>色々なモデルが考えられてるよ。
原理的に駄目なものに色々考えても、全部だめなんだけど？
>例えば、インターネット電話の一般通信は無料か定額。
「例えば」で、使えそうな例を一つでいいから挙げてみれ。
>非インターネット電話側のみ発着料金負担というモデル。
インターネットから非インターネットに着信するのに課金？ぜんぜん駄目じゃん。
一般の加入者にいきなり請求書送りつけても払うわけないから、ENUMに登録した加入者という
ことだろう。しかし、そうまでしてENUMに登録するほどインターネットに熱心な香具師が非イン
ターネット側にいるわけない。
結局インターネット内で無量通話するだけになるが、だったら既存の電話番号なんか関係ないじゃん。

ITU-TとIETFではENUMを国際標準として進めています。

　　　　　　　　　　　　　∩
　　　 　 　 ∧＿∧ 　　| |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　 （　 ´Д｀）／/　　＜　先生！こんなのを発見シマスタ！
　　　　　 ／ 　 　 　 /　　　　｜
　　　　 / /|　　　　/　　　　　　＼ 　http://saitama.gasuki.com/sinagawa/
　 ＿＿| | .|　　　　| 　　　　　　　 ＼
　 ＼　 ￣￣￣￣￣￣￣＼ 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　||＼　　　　　　　　　　 　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

>ITU-TとIETFではENUMを国際標準として進めています。
だから？
昔話ですが、ITUとISOとIETFは、OSIを国際標準として進めようとしました。
その結果は見てのとおり。

>>673
特定の一部容認受け入れを除いて、IETFがOSIを進めようとしたことありますか？
（御存知の通り、特定の一部については受け入れて国際標準になっています。）

ENUMについては既に国レベルで『国電話番号.e164.arpa.』の取得をしている
ところも多いです。日本はなぜかかなり遅れているほうだったと思いますが、
このスレッドにて否定意見が多いことと関係がありますか？

>>660
どうやって発呼側が別ネットワークのユーザのGW検出するんだよ。
着呼側が、自分に繋がるGWを開示しないといけないのは明白だろ。

つか、DQN運用の一例だけを取り上げて、それを根拠に技術を否定するな。
レイヤの違う話だって事くらい理解しろ。

>670
BBPhoneとか駄目なんですか

うにょ？さんと、ENUM？さん、同じく？がつくから同じ人かと思っちゃったー。
でも批判しあってるから実は違うのね。

ENUMでのオープン運用モデルとしては、
うにょ？さんが書いているように、着呼側が自分へのGWをENUMによって開示して、
発呼側はDNSをひくだけで着呼側のGWを知ることができるというのが正解と思うの。

ただし、これらはもちろん古典的な数字の電話番号を用いる相手に対してね。
http://www.soumu.go.jp/s-news/2002/pdf/020222_3_05.pdf
総務省の研究報告書のIP電話の番号計画のところにもあるように、
インターネット電話においては数字以外のアルファベットをもちいてもよい、
とあって、これは例えばSIPのURIなどを意味してるのね。

そしてSIP URIを識別子として使うというのは現在のメールアドレスと同じで、
DNSを引いて直接相手のドメインと通信可能になる分散モデルとして有効なの。

>>677
ENUM?が言ってる問題の本質を理解してないから話が噛み合わないんだと思われ。

＞ENUM?
キミの言ってるのはENUMの問題じゃなくてオペレーションの問題でしょ。

>キミの言ってるのはENUMの問題じゃなくてオペレーションの問題でしょ。
ENUMは原理的にオペレーションできんといってるので、ENUMの問題だぞ。
>どうやって発呼側が別ネットワークのユーザのGW検出するんだよ。
別ネットワークって何だ？インターネットは一つだぞ。
別ネットワークになるのは電話網へ電話するときだけで、電話網もひとつだから、発呼側が
自分の使えるGWのうちから好きなの選ぶしかなかろ。

★男はココを見るべし★女と金とサンプルムービー★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html

http://www.agemasukudasai.com/bloom/

なるほど。

うにょ?モデルだとインターネット以外のところには複数の世界とそれらのGWがある。
極端にはそれぞれの古典電話会社が各自でGWを通じてインターネットにつないでいる。
（つまり、着呼側が自分のGWをそれぞれ指定開示している場がENUM。）

一方、ENUM?モデルだとインターネット以外のところには既存電話網ただ一つ、
ただし既存電話網とインターネットをつなぐ業者は複数いてGWは複数。
（そのため、発呼側が値段とかを見てGWを選びたい。昔の0070-付けてみたいな感じ？）

とすると、これは>>678のいうようなオペレーションの問題ではなく、
想定するモデルの違いではないか？？

★男はココを見るべし★女と金とサンプルムービー★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html

http://bb.watch.impress.co.jp/cda/news/990.html
急速に展開するIP電話サービスを比較

NTT電話　公衆電話　NCC電話
国際電話　IP電話　PHS　携帯電話

NTT電話→NTT電話
NTT電話→NCC電話
NTT電話→国際電話
NTT電話→IP電話
NTT電話→PHS
NTT電話→携帯電話
公衆電話→NTT電話
公衆電話→NCC電話
公衆電話→国際電話
公衆電話→IP電話
公衆電話→PHS
公衆電話→携帯電話
NCC電話→NTT電話
NCC電話→NCC電話
NCC電話→国際電話
NCC電話→IP電話
NCC電話→PHS
NCC電話→携帯電話

IP電話→NTT電話
IP電話→NCC電話
IP電話→国際電話
IP電話→IP電話
IP電話→PHS
IP電話→携帯電話
PHS→NTT電話
PHS→NCC電話
PHS→国際電話
PHS→IP電話
PHS→PHS
PHS→携帯電話
携帯電話→NTT電話
携帯電話→NCC電話
携帯電話→国際電話
携帯電話→IP電話
携帯電話→PHS
携帯電話→携帯電話

先見の迷惑
http://www.page.sannet.ne.jp/mnagai/msj/openmind.htm

softfront...

>>687 栗鼠虎であぼ〜んされませんでしたか？(w

しまった、一緒にあぼ〜んされて来ます…

>687
癒されました。リンク先にも貴方のホスト名にもｗ

このスレ的にはこれですね。
「この『電話』というものは欠点が多すぎて、通信に使おうと真面目に考える
ことなどできない。我々には本質的に価値のないものである。」
--- ウェスターン・ユニオンの内部文書、1876

687でつ。

やっちまいますた。


>>689

私は大丈夫．．．じゃなかったでつ。(´Д⊂)
でも次の就職先は見つかったので心配はないでつ。

softfrontってENUM対応してますか？

>>692
いまからSoftfront入りたいんですけどどうやったら入れますか?
金無知はサポーロだけ?

>>679
> 電話網もひとつだから

おまえ、もうちょっと世間の電話会社理解しろ。
携帯電話の第一種通信事業者だけで何社あると思ってるんだよ。

> 自分の使えるGWのうちから好きなの選ぶしかなかろ。

網制御とかの概念勉強しな。

>>682
モデル以前の話だろ・・・・

> 発呼側が値段とかを見てGWを選びたい

お前、電話料金くらい理解しろよ。
発端末、着端末の加入している業者がどこかと、発-着端末間の距離で
通話料金は決めてるんだよ。
おまえ、携帯電話にかけるときに何処の交換機を経由して
携帯電話会社に接続するか指定しながらかけたことあるか？
網の輻輳なんかで遠回りしたときは料金上がったりするか？

何処の経路を通すかは、キャリアが内部コスト減らすために
勝手にがんばるもんだろ。客に意識させるわきゃねーよ。

発信時に0077とかをつけるのは、発側の「業者」選択だろ。
経路の選択は指定した業者まかせなんだよ。

>561 さん
激遅レスですみまそん。（カキコしたことすら忘れてました。。。）

re-inviteの使い方として（転送はもちろんですが）
WirelessのVoIPデバイスを想定した場合、このデバイスがサブネット間移動
（L3ローミング）をした場合、Re-inviteを使うことでセッションを保持したまま
シームレスに移動できると思いますが、これができるUAが存在してるんだろうか
という意図でした。

AirＨ”がとても通信悪いです。
すこしでも回線速度あがる裏技ないですか？
おねがいします伊東家のみなさん

>>695
携帯電話の第一種通信事業者だけで何社あろうと、
古典的E.164世界のPSTN網である限りはいっしょ。

もちろん、インターネット電話が主流になった時点で、
各PSTN網会社はそれぞれがインターネットにつないでGWを別個にもつだろうから、
ENUMによって各社のGWへ抜けるという点では、うにょ?氏に賛同します。

一方、ENUM?氏のほうは以下の２点で考えが古すぎる。
一つ目はいまだに従量制課金を前提としていること。
二つ目はいまだに複数の電話網経路に対してを中継事業者を選ぶような発想。

インターネットでユーザ間はE2Eで通信する時代に、
中継事業者という概念はふさわしくない。
もちろん中継ISPは存在するだろうが、
ユーザにとって中継ISPがどこかはE2E通信にとって意識しない階層であろう。

>>685
>NTT電話　公衆電話　NCC電話
>国際電話　IP電話　PHS　携帯電話
インターネット中の電話と（古典電話会社が運営する）プライベートIP網中の電話をまとめてIP電話と
呼んでは、それ以外をいくら細かく分類しても何も意味がないぞ。

>>695
>> 電話網もひとつだから
>おまえ、もうちょっと世間の電話会社理解しろ。
>携帯電話の第一種通信事業者だけで何社あると思ってるんだよ。
世界中にISPはいぱーいあるが、インターネットはひとつしかない。同様に公衆電話網もひとつしかない。
そして、電話網内の経路は発呼（通話料払う）側が決める。

>もちろん、インターネット電話が主流になった時点で、
>各PSTN網会社はそれぞれがインターネットにつないでGWを別個にもつだろうから、
>ENUMによって各社のGWへ抜けるという点では、うにょ?氏に賛同します。
その電話がインターネット電話なら、GWなんかなしで直結だ。
PSTN電話なら課金問題が発生するが、NTT網内にある電話にかけるなら米国のGW回ったほうが安く
なるに決まってるんで、ENUMでひいたNTTのゲートウェイを使うのはバカ。
>インターネットでユーザ間はE2Eで通信する時代に、
>中継事業者という概念はふさわしくない。
E2EなのにGWなんてものを持ち出すおまえの考えのほうが古いんだよ。
念のためいっとくと、プライベートIP網中の定額制IP電話なんて中途半端なものを「インターネット
でユーザ間はE2Eで通信する時代に」わざわざ考えてもしょうがないし、GWが混んだら定額制くずれるぞ。

サンプルムービーです
http://homepage3.nifty.com/digikei/sample/sample.html

★ココで決まり★男の掲示板★大人のリンク集★
　↓　↓　↓　↓　↓　↓　↓　↓　↓　↓
　http://www.pink-angel.jp/betu/index.html

ENUMとは？

ENUMとはITU-TとIETFが共同で進めるtelephone number mappingのしくみである。
具体的には、電話番号からインターネット上のURIへの対応付けをする枠組みである。
利用方法としては細かくは種々あるが、発信方向により大きく2種類に大別できる。

一つ目はインターネット電話ユーザがE.164番号を持つ者へ発信するときに、
そのE.164番号を持つ者のURIあるいはGWのURIを取得するには使われる。

二つ目はE.164番号しか指定できない者からインターネット電話ユーザへと
発信するときに使われる。この場合、着信側のインターネット電話ユーザは
自分のURIに対応するE.164番号を持つ必要があり、ENUMに登録しておく。

みんながもめている例は、前者なのか後者なのか、はっきりしたまえ。

おーい、ENUM の話やりたい人はスレ立ててやれや。
固定電話の将来みたいな話は通信行政板に逝ってくれ。

>>704
ENUMは、DNSを利用した、電話番号からSIP URI等への変換技術でっせ。
つまり、ここのスレの主題であるSIPと電話番号の関係についての話。

>>703にあるURIというのも電話の場合は例えばSIP URIという意味なので、
通信プロトコル技術を扱うこの板のこのスレッドで議論するのが正解。

NECってSIPプロキシやらなにやらいろいろ作ってるじゃないっすか。
漏れも転職してその部署で働きたいんだけどさ、どこの面接受ければ
いいんか教えてキボンぬ

未来のネットワークについて議論してます
http://science.2ch.net/test/read.cgi/future/1022864257/

>>706
ＮＥＣの裏事情２１
http://tmp.2ch.net/test/read.cgi/company/1047079708/
さようなら 日本電気５
http://money.2ch.net/test/read.cgi/stock/1038295141/

SIPもENUMも、どうしてDNSをひくときはNAPTRを使うの？

>>706
我孫子の事業部じゃないの？鯖屋でも端末屋でも。
端末屋は ADSL-Modem とおなじとこ。

http://bb.watch.impress.co.jp/cda/news/1115.html
平成電電、国内3分6.8円とは。
IP電話網はこれで壊滅だね。高価なIP電話網機器も買ってもらえないからSIP屋さんも大変だ。
もちろん無料のインターネット電話はびくともしないが、高価な機器は使わんし。
「なお、NT東西に支払う回線利用料については「回線利用料というよりは管理費用という存在の
ため別途必要になるが、詳細については現在検討中」であるという」 のあたり、まだNTTと交渉
してなさそうで、紆余曲折はありそうだけど。

>>711
その何が言いたいのか判らない日本語は、なんとかならないか？

>>712
漏れに八つ当たりしても現実は変わらんのだから、早く転職考えたほうがいいぞ。

>>711
IP電話網が壊滅って何だろ？
NTTはIP電話網にシフトする事が確定してるし…。
平成電電が全国の回線交換網を維持するの？

>>713
八つ当たりする気は、さらさらないんだけど…。
唐突に出てくる用語と話の繋がりが判らないので、もっと順序を追って書き込んで
くれないか？ ってことを言いたかったのだが。

で、IP電話網ってなんのこと言ってんの？(一般的な用語？)

>711
最後の聖域、基本料がついに…
NTTと違ってプッシュ料金別に取るなんてこともしないよな。
つーかGC1局あたり200万円って、そんな交換機この世にあったのか。

>714
この程度の値段なら旧来の方式でも実現できるわけで、交換機IP化
する必要ないんじゃない？NTTの計画は2010年とかの話でしょ。

あ、交換機じゃないじゃん…

>NTTの計画は2010年とかの話でしょ。
ﾜﾗﾀﾖ。
でも、NTTの体質だと最速でその頃なんだろな。納得。
こりゃ、SIPとか平成電電とか関係なく、あと2~3年で潰れだ。
ファミリー企業の皆さんも、とっとと見限ったほうがいいぞ。

IP電話網はこれで壊滅だね

見限るもなにも、交換機の新規投資が既に止まっているの知らんのか

他社も平成電電方式真似できるが、やるとしたらyahooくらいか。

>>711
>無料のインターネット電話はびくともしないが

300円を追加
して支払うことで平成電話のユーザー同士
は無料で通話できる。

http://yahooo.s2.x-beat.com/linkvp/linkvp.html
◆よろしく◆

SIPプロトコルのやりとりってこれでいいの？
　　おばあちゃん　　　　　　　　　　　　　　　息子
年老いた母が電話をかける（オンフック）→電話先は息子（アドレス通知）
「最近腰が痛くて痛くて」（状況通知）　←「どうしたのおばあちゃん？」（問い合わせ）
「すまないが湿布はってもらえないかね」（本心：たまには会いに来い）→「わかったよ」（本心：しょーがねーな）
「いつ来てくれるんだい？」（遅延問い合わせ）→「次の日曜日でも」（日時設定）
「わかった。おみやげ頼むよ」（オフフック）←「じゃあそのときに」（長話カット）

>見限るもなにも、交換機の新規投資が既に止まっているの知らんのか
だからといってIP電話機器の研究開発なんかしたって元は取れないから見限れといってる。
>>無料のインターネット電話はびくともしないが
>300円を追加
>して支払うことで平成電話のユーザー同士
>は無料で通話できる。
もともと電話収入あてにしてないのにびくともしないさ。むしろ、平成電電のほうがジリ貧だ。

>> 723
オンフック、オフフック逆じゃねーの？

俺も最初はよく間違えた。

SIPプロトコルで、それぞれどれに相当するの？

＞オンフック、アドレス通知、状況通知、問い合わせ、遅延問い合わせ、日時設定、オフフック、長話カット

　　 　 ∧＿∧∩　／￣￣￣￣￣￣￣￣￣￣￣
　　　 （　´∀｀）/＜先生！こんなのがありました！
　＿ / /　　 /　　　＼＿＿＿＿＿＿＿＿＿＿＿
＼⊂ノ￣￣￣￣＼
　||＼　　　　　　　　＼
　||＼||￣￣￣￣￣||
　||　 ||￣￣￣￣￣||
http://saitama.gasuki.com/saitama/

（　´∀｀）/＜ 先生！！こんなのを見つけました。
http://muryou.gasuki.com/moe/jaz04.html
http://muryou.gasuki.com/moe/jaz03.html
http://muryou.gasuki.com/moe/jaz02.html
http://muryou.gasuki.com/moe/jaz01.html
http://muryou.gasuki.com/moe/jaz06.html
http://muryou.gasuki.com/moe/jaz05.html
http://muryou.gasuki.com/moe/jaz08.html
http://muryou.gasuki.com/moe/jaz07.html
http://muryou.gasuki.com/moe/jaz10.html
http://muryou.gasuki.com/moe/jaz09.html

　 　 　 　　　　┌┬┬┬┐
　　　　―――┴┴┴┴┴―――――、
.　　. / ￣￣￣//.￣￣| ||￣￣￣|||￣ |｜　　　 ＿＿＿＿＿＿＿＿＿＿
　　./　 　　∧// ∧ ∧| || 　 　 　||| 　 |｜　　／
　[/＿＿__(ﾟ_//[ ].ﾟДﾟ,,) ||＿＿＿||| 　 |｜ ＜ 　こんなのが有りますた
.　||_.　*　 ＿|_|￣￣ ∪|.|. 　 　 　 |ヽ.__|｜　　＼＿＿＿＿＿＿＿＿＿＿
.　lO|o―o|O゜.|二二 |.|　　　 救済病院 ||
　.| ∈口∋￣_l＿＿ｌ⌒ｌ_|＿＿＿|_ｌ⌒ｌ._||
　　￣￣`ー'￣ 　　`ー'　 `ー'　 　`ー'
http://saitama.gasuki.com/koumuin/

　 ∋8ノノハ.∩
　　 川o・-・）ノ　＜先生！こんなのがありました！
＿_/ / 　 　/ 　　
＼(_ﾉ￣￣￣＼
||ヽ||￣￣￣￣||
　...||￣￣￣￣||
http://saitama.gasuki.com/shinagawa/

http://www5b.biglobe.ne.jp/~ryo-kyo/osu.html

http://my.vector.co.jp/servlet/System.FileDownload/download/ftp/0/279026/pack/win95/game/table/pachinko/sikisai.lzh

相互接続か…

SIPのレスポンスはリクエストのViaが示すIPアドレスに返すのが正しいと思っていたのですが、
RFC3261の18.2.1と18.2.2を読むと結局sourceIPアドレスに返すのが正しいように読めます。
SIPはIPヘッダやUDPヘッダ部は気にせずに処理できるものだと思っていたのに違うのでしょうか？

sentbyの話だったらそのとおりだ>>734
イキロ

いや、receivedなんですが

http://www2.leverage.jp/start/

>>734
received付加するのにIPヘッダ読む必要なかろ。
たとえばsocketなら、ソースのIPは取得できるだろ。
どんなプロトコルスタック使ってるにしても
送信相手を指定できるレイヤなら、受信時の相手もとれるだろ。

>>734
もういちど18の最初から読み返そう

>>738
お前はネットワーク素人

http://e-words.jp/w/SIP.html
>> 転送機能や発信者番号通知機能など、同様のプロトコルと比べて
>> 公衆電話網に近い機能を備え、接続にかかる時間も短くなっている。

と、あるのですが、発信者番号通知機能というのは、
どういうふうに実現しているのでしょうか？
RFCを読んだのですが、該当する機能がわからなくて。

“IP電話で110番”実現には何が足りないか？
http://www.zdnet.co.jp/broadband/0304/15/lp11.html

>>740
つうか単にFrom:のURIのuserinfo部分でしょう。

例えば、050-1234-5678をもらったユーザは、

　　From: tel:050-1234-5678

っていう感じでSIPすれば、発信者番号通知になる??

>>743
>発信者番号通知になる?
なんどもいうが、UACが意図的に隠蔽しなければデフォルトでPSTNの
番号通知のような状態になるわけで、どう伝えるかはUACの好きにす
るなりその網の運用規則にしたがうなりすればイインジェネーノ。
知らんけど。

ちなみに、普通 tel:ではなくて From: "050-1234-5678" <[email protected];user=phone>
とでもするんじゃ。

[email protected]って、domain.nameは実際にはなんですか
[email protected]とかになるんですか

From:は自己申告なので、みんなが正直に伝えれば番号通知になるわけですね

Proxyが妙なFromをハネてもいいし、407で蹴ってもいいし、
UASですらUA-UA認証を要求したっていいんだから生全節で
もないのでわ。

>>746
UASというか着呼側SIP端末

>>746
Proxyは不正であるとチェックする能力／枠組みを持たない。
さらに発信側はProxyとして任意のところを使える上、
もちろんProxyを通さずに直接相手へ発信することも可能。

>>747
着呼側SIP端末が認証しようとしても、
相手の自己申告05012345678と相手のIPアドレスだけでは、
知合い以外は認証できないのでは？

> Proxyは不正であるとチェックする能力／枠組みを持たない。
ん〜、Digest認証のusernameと、Fromのuserinfoが一致していないと
リクエストを完全に無視するProxyなら存在するけど…?
これだけでは枠組とは言えないというなら残念な限りですが。

> さらに発信側はProxyとして任意のところを使える上、
普通IPレイヤでフィルタされるし、通ったとしてもそれこそ
Digest認証通らないでしょう。

> もちろんProxyを通さずに直接相手へ発信することも可能
これは、俺んとこの端末だと端末がフィルタしますね。SourceIP
によるから完全ではないことは認めるけど。

> 知合い以外は認証できないのでは？
ですね。

>>741
その総務省の研究会の報告書を見たけど、要求事項概要すらまとめられてないような。
ましてや技術的な要求事項や議論については皆無。このスレのほうがかなりまし。（藁

>>740
RFC3325 をどうぞ。Japanese ISUP を喋るSIPシステム
の中には実装されているものがあります。というかして
いないの何処？というのは興味があります。

>>749
認証しくじったらアナウンス接続してくれる SIP鯖もありますね。

アナウンス接続ってなあに

すいません、緊急に教えて頂きたいのですが、CAC（コールアドミッションコントロール）
って何でしょうか？

（＾＾）

>>749
Digest認証でのチェックくらい当然です。
しかし、それでは発番号通知(userinfo)が正しいと第三者は分かりません。

さらに、SIPやRTPがIPレイヤでフィルタされるというのは異常です。
今まで色々な商用ISPを利用してきましたが、
特定のパケットをフィルタするような無茶なISPには出会ったことはないです。

もちろん、この前の1434番ポートのフィルタといった一時的対処は別です。

基本的にユーザは、自分が利用できる任意のSIP PROXYを用いることが可能で、
これは、ISP Aにつなぎながら、ISP BのPOP/IMAPサーバを用いるのと同じです。
つまり、ISP BのSIP PROXYを用いたりREGISTERしたりすることができます。

http://www.agemasukudasai.com/movie/

>今まで色々な商用ISPを利用して
多分話が噛み合わないと思うわ

>>744
特定パケットをフィルタリングしてるISPってある？

>>これは、俺んとこの端末だと端末がフィルタしますね。
専用端末でなくてPC端末を使うとどうよ？

>>741
なぜ、VoIPにおける問題点、SIPにおける問題点、
ISPやそのbackboneにおける問題点などの具体的な問題が上がってないのだろう。

そもそも解決法にしても、ISDN化を進めることで2004年に対応予定とは。

>>739
あぁ、「相手先」に反応したのね。おばかさん。
receivedで必要なレイヤくらい理解して発言しろよ。

まじウザいな。消えろよ同人屋。

もめている >>734-739 の件だが、全員が誤解しているのか？

単純に言えば、Viaのsent-byは送り側の自己申告なので、
受け取った側はreceivedを付けておかないと返事するとき困るというだけ。
（もちろん、sent-byがIPアドレスであり嘘でない場合のみ、receivedは不要。）

で、それは >>734 のいうように相手のIPアドレス（＝ソースIPアドレス）であり、
もちろん、 >>738 のいうようにgetpeernameで取得できる。
そして、 >>735 のいうようにsent-byと比較するわけで、
一致してなければ >>736 のいうようにreceivedを付加して記録。

結論としては、自己申告のsent-byになんの意味があるのか？

>>762
仕様を理解してないのは>739だけだと思われ。

まぁ、IPが同じだからといって同じホストとは限らんし、
同じホストだからといってIPが同じだとは限らんわけだが・・
sent-byにFQDNを書けるってことでそれなりの意味はあるぞ？
ループチェックもそのひとつ。

sent-byとreceivedでは、利用するレイヤが違うってこった。

まじウザいな。消えろよ同人屋。

＞結論としては、自己申告のsent-byになんの意味があるのか？
それがキミの限界かもね（ｗ
RFCに書かれたことをまんま解釈するだけなら誰でもできる。

>>763
loop checkのためには、たとえ自己申告に過ぎないにしてもsent-by値は重要ですな。
しかし、特定のproxyと同じ名前を故意にぶつけることも可能でもある。

IPが同じだからといって同じホストと限らない件でいえば、
持ち歩いてるPCから発信する場合にsent-byをどうするかは悩むところ。
hostname自体がある意味いい加減である上、ddnsもいまいち。
そのときにもらっているIPからdns逆引きしたものでも付けるくらいか？

receivedが不可欠なのは複数のA RRあるいはAAAA RRなども持つ場合。
IPv6にてどちらのifからやってきた、など、reply時に必須の場合も多い。

http://www2.leverage.jp/start/

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

すみません。どなたかＩＰ電話の技術者クラスの方いませんか？
IPはどうして安くなるのか。またどのような方法で通信しているのか
なぜ交換機が必要ないのか”技術的に”教えて下さい。
VoIPでパケット通信してることは間違いなさそうですが信号の遅延やパケットの欠落などを
どのようにクリヤーしてるのでしょうか？

>>769
宿題の丸投げか・・・？
技術的な話がほしけりゃ、ソフトフロントさんあたりが
きれいにまとめてくれてるから参考にしな。
http://www.softfront.co.jp/tech/voip.html

>>766
故意にぶつけても、途中のでproxyではじかれるだけで、
誰もこまらないんだが・・・(w

それよりも、UAS側で経路上のViaのreceived書き換えちまったほうが
影響あるかも？それなりに使ったらDoSとかできそうじゃないか？

（　´∀｀）/＜ 先生！！こんなのを見つけました。
http://web2001.kakiko.com/koma/hankaku/hankaku07.html
http://www.web2001.kakiko.com/koma/hankaku/hankaku08.html
http://web2001.kakiko.com/koma/hankaku/hankaku10.html
http://www.web2001.kakiko.com/koma/hankaku/hankaku09.html
http://web2001.kakiko.com/koma/hankaku/hankaku06.html
http://www.web2001.kakiko.com/koma/hankaku/hankaku05.html
http://web2001.kakiko.com/koma/hankaku/hankaku01.html
http://www.web2001.kakiko.com/koma/hankaku/hankaku02.html
http://web2001.kakiko.com/koma/hankaku/hankaku03.html
http://www.web2001.kakiko.com/koma/hankaku/hankaku04.html

>>769
http://www.cisco.com/en/US/tech/tk652/tk701/tk587/tech_protocol_home.html
全部読んでください

>>769

ここのスレ見てる時点でほとんどが技術者クラスだろ！
んで、その初歩的な質問するおまえは少なくとも
SIPのキーワードを知っているわけだ！
んなﾔｼが、この質問か？VoIPとかIP電話をキーワードに
検索してそこで質問すれよ厨房。

このスレのsapporoという時点でソフトフロントな
わけだが。新しいビジネスモデルいけてるかい？

http://homepage.mac.com/hitomi18/

>775
どんなモデルヨ。

SIP関係に資本を集中モデル
日本をリードする予定

加藤大治郎追悼特番よかった。

SIPでINVITE requestが来た場合、以下のパターン以外を御教授お願いします。

1. 自分自信なので応える
2. 自ドメインなので（登録されている）正しい先をredirect
3. 自ドメインなので（登録されている）正しい先へrelay
4. 自ドメインだけど知らないのでエラー
5. 自ドメインでないけどproxyなので正しい先へrelay
6. 自ドメインでなくてproxyだけど正しい先が不明でエラー
7. 自ドメインでなくてproxyでもないのでエラー

>>780
( ﾟдﾟ)ﾎﾟｶｰﾝ

リダイレクトとリレー（フォワード)って、
気分によってどちらかに気ままに変えても違反しないんだろか？

>>775
いや○KIかもしれん。

>>775
>>783

両社ともVoIPに詳しい企業だよな！有名だからしってるよ。
漏れは、とあるメーカーからの受託でやってるだけなんだが、
実はSIPはそれほど詳しくもない．．．H323ってのをやってるんよ。
んで最近SIPもってな話が出てるわけよ！

>>783
札幌とSIPで何故に沖？

やっぱ富士通だろ？

TTCがSIPの勧告まとめてるそうだが、どうなったか知ってる奴いませんか？

>>787
このスレにて既出。どの辺かは自分で探してね。

>>788
いゃ、そろそろ正式に番号とられて出てもいい頃かな・・・と。
もしかして、もうでてる？

SIPの勧告をまとめる能力はないと思いますが違いますか

まとめるの意味が違ってる罠

翻訳するが正しい

>>789
番号取る気はあるらしいけど。
お勤めの会社のTTCに出ている人にでも問い合わせれば・・・
ちなみに正式には承認されていないのでまだ今年度の標準化
計画はTTCのWebには出ていません。

http://www.ttc.or.jp/j/m_term/index.html

>>793 ｻﾝｸｽ
各社の相互接続とかの動きが活発になってきているようなので、
そろそろ固まってきたかな・・・と思ったんですが、
まだ暇がかかりそうなのねん。

>>785
○KIで今度SIPに関する本を出すらしい。またこんな↓スレもある
http://school2.2ch.net/test/read.cgi/job/1026567122/

はぁぁ。ＳＩＰってもうちっともシンプルじゃなくなったよＮＥ

>>796
SIMPLE IPのSIPはIPv6になったよ

ここのSIPは元々SAP+SDP(広報系)にたいするSIP+SDP(勧誘系)だね
途中でSession Invitation ProtocolからSession Initiation Protocolへ名称変更

>>796
昔から複雑だったと思うが・・・
SIPのSはsimpleの略ではないぞ？

ちなみに、simpleから始まるプロトコル名称はSMTPのように四文字。

>>798
SIP/1.0は極めて簡単でしたが？

http://homepage.mac.com/ayaya16/

SIP技術に長けた会社ってどこなの？
コンサル契約しようとしてる会社がどーもあやしい；；

　 ∧＿∧ 　　
　（　・∀・）/＜　こんなの発見したっち♪　
http://www.yamazaki.90.kg/hankaku/hankaku02.html
http://yamazaki.90.kg/zenkaku/index.html
http://www.yamazaki.90.kg/hankaku/hankaku08.html
http://yamazaki.90.kg/hankaku/hankaku10.html
http://www.yamazaki.90.kg/hankaku/hankaku07.html
http://yamazaki.90.kg/hankaku/hankaku03.html
http://www.yamazaki.90.kg/hankaku/hankaku05.html
http://yamazaki.90.kg/hankaku/hankaku01.html
http://www.yamazaki.90.kg/hankaku/hankaku06.html
http://yamazaki.90.kg/hankaku/hankaku04.html
http://www.yamazaki.90.kg/hankaku/hankaku09.html

>>801
softfrontかokisoft

前者は既に総力あげて本出してるようだし後者ももうすぐ出るとの噂

ttp://images-jp.amazon.com/images/P/4872804872.09.LZZZZZZZ.jpg
S社の社長が本出したらしいぞ。

>>798
もともとのSはSimpleだった

SIP/2.0 (Session Initiation Protocol)
= SIP/1.0 (Session Invitation Protocol)
+ SCIP/1.0 (Simple Conference Invitation Protocol)

２５歳。
去年まで金無し君だったけど、オンラインカジノとパチンコで
二年で３５０万貯めた。一度やってみなよ。
初回のみだけど、１ドル以上のチップを買えば３０ドル（４０００円くらい）貰える。
もらうだけもらってプレイせずに換金することもできるし、ルーレットで赤か黒に
思い切って賭けてしまえば５０パーセントで二倍になる。
金なきゃオフラインでゲームすればいいだけ。暇つぶしになる。
ビデオポーカーとかスロとか色々あるのでマジでお勧め。
http://www.imperialcasino.com/~1kl5/japanese/

http://homepage.mac.com/hitomi18/

TTCのSIP勧告って木？巾晃の会社が公開してるのと比べてなにがいいの？
単なる和約なら必要ないよなぁ。
金かかるし。

☆^〜^★　50音順で探せて楽して得する
http://sagatoku.fc2web.com/
　　　あなたの探し物きっとみつかるよ☆^〜^★

隠岐のＣさんの書いた本、本屋にありました。SIP のヘッダ情報の
解説が細かくてイイ！です。

>>810
ｹﾞﾗｹﾞﾗ

>>803
S社の方、大規模な首切りがあってからというもの
Webの技術情報、定期更新すらされていないんだが・・・

もしかして、技術者にげちまったんじゃねぇか？

SIP教科書みつからないです
田舎には置いてないのでしょうか？

●貴方に代って恨み晴らします● 【復讐・特殊業務】
--------●○●別れさせ屋●復讐代行業務●○●----------
●騙された・裏切られた・弄ばれた・逃げられた・捨てられた・
相手に誠意が無い・異性問題・家庭内暴力・不倫疑惑解明・人間関係・金銭トラブル★ http://www.blacklist.jp/i
別離工作・情報収集・トラブル対策・ボディガ―ド・等々！
●真剣にお悩みの方、安心してご相談下さい。解決へ導きます★
□■各種データ・電話番号調査・住民票・戸籍謄本など調査■□
　　　http://www.blacklist.jp/i
【注意】ジャンプしない場合はURLをコピーしてファイルから開いて下さい●○● http://www.blacklist.jp/
--------------------------
◆リンク◆復讐現場密着24時◆ http://www.123456789.jp/

SIPって米、欧、日本以外のアジアでも盛り上がってんのー？
こんなに騒いでいるのは日本くらいじゃぁないのー？

>>815
中国、韓国、台湾、インドなどもやってるぞ！
おまえが無知なだけだ．．．

じゃぁ、米、欧は、、、？
MGCPとか使ってるところもあるし、、、

IETFがSIPを中核にいろいろ進めてるからそのうちHTTPくらいメジャーになるぜ

>>818
ありえない

>498 にある記事の中のPROTOS Test-Suite : c07-sip のツールが
使用途中にJavaのエラーで止まるのですが、どうすればちゃんと使えるか分かる方教えてください。
win2k j2sdk1.4.0 です。
たぶんJavaで2byte文字を1文字として数えてるのが原因だと思うのですが…

>>820
java -Dfile.encoding=ISO8859_1 ... とか。
そういや2月末頃にバグ(?)報告したんだけど無視されたわ。

>821
それで出来ました。助かりました。ありがとうございます。

>>819
壁越えとかには便利そうでつ。だからftpくらいには(r

SIP redirectってモバイル端末のIPアドレス(URI)変動にも対応するのかな？

Silicon in Packageのことでしょ

>810
社内で1割引セールしています。

# そんなことするより、社員にはただで配らんかい！

>>826

20冊ほど転売して下さい

SIP教科書みつからねぇ〜

>>828
それはなに？
ブキ？

>>828
今日、本屋で見かけてちょっと立ち読みしたけど、イマイチだった

これからはＳＩＰだな
Ｈ３２３／ＳＩＰコンバータってどうよ？

（*｀▽´*）うひょうひょ
http://jbbs.shitaraba.com/computer/2364/

>>831
H.323はきっぱり捨てるのが楽でよいと思う
マイクロソフトもいきなりSIPへ移行したね

>>830
まだ買ってないが参考のためどのへんがいまいち？

>>833
既設のＩＰ−ＰＢＸを０５０網に接続するのに必要になってくると思うよ
Ｈ３２３捨てられないところはどうしても出てくる
いくつかのメーカも開発に着手してるからね

http://www.zdnet.co.jp/broadband/0112/26/sip.html
>もちろん，業界がこうした問題を手をこまねいて見ているわけではない。解決策として，「ルータなどで変換をかけて，H.323とSIPのプロトコルを横断できるシステムも開発している」と話す技術者もいる。しかし現状，こうした技術はまだ完成の域に達していない。

この記事から2年経ったけど、どうなっているの?
やっぱH.323は企業ユーザー中心だから、ぼったくるつもりか?

>>835
やはり、中途半端に既存の活用ではなく、
一気にH.323捨てたほうが安く上がりそうだ。

確かに安く上げるのであればSIPだろうが、現実はそう単純にはいかないだろう。
どの企業もPBXの更改を迎えていて、PBXメーカがSIP対応を簡単に企業に勧めるとは思えない。
だから、今後売れ行きの商品は「SIP対応VoIP-GW」だろうな。これで
企業の外線コストを（050網で）削減していくのが当面の最強だと思うな。

http://yahooo.s2.x-beat.com/linkvp/linkvp.html

SIPのVoIPを販売している会社って、当然自社はSIPにしてるの？

スレにsage以外で書いたら以下のスレにageとだけでもいいので何か書いて、
スレが#1にならないようにしてください。
#1は広告の餌食になります。

広告よけ用スレッドです。
http://pc.2ch.net/test/read.cgi/network/1042627992/

http://homepage.mac.com/hitomi18/

　 ∧＿∧
　（　・∀・）/＜　こんなの有ったっち♪
http://www.muryou.gasuki.com/hankaku/hankaku07.html
http://muryou.gasuki.com/zenkaku/index.html
http://www.muryou.gasuki.com/hankaku/hankaku08.html
http://muryou.gasuki.com/hankaku/hankaku10.html
http://www.muryou.gasuki.com/hankaku/hankaku01.html
http://muryou.gasuki.com/hankaku/hankaku03.html
http://www.muryou.gasuki.com/hankaku/hankaku02.html
http://muryou.gasuki.com/hankaku/hankaku09.html
http://www.muryou.gasuki.com/hankaku/hankaku06.html
http://muryou.gasuki.com/hankaku/hankaku04.html
http://muryou.gasuki.com/zenkaku/index.html
http://www.muryou.gasuki.com/hankaku/hankaku05.html

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

H323-SIP GWは作ったとこあるらしい
某所では稼働中らしい

age

>>844
普通は「めでぃえーたー」といいませんか？

めでぃえーたーてなあに？

>846
PBX業界だとGWと表現することがおおいと思うけど

"site:www.vovida.org mediator"
１件か。。。ま、タダでできるんじゃみすみす誰もつくらんわなぁ（藁

>>848
GWはまずいでしょう。VoIP関係やっていると GW の Default Gateway は
とかいう会話はうんざりです。頭が混乱してきます。

Default Gateway はデフォゲであるからGWと混同しません

>>844
みかかＭＥで扱ってるようだね
ttp://nttiivs.ntt-me.co.jp/mms/ss8/img/H323_SIP_IWG.pdf

特集：IP電話を徹底解剖する 5回シリーズ
技術から見る「IP電話で110番」の進捗度
http://www.zdnet.co.jp/broadband/0305/29/lp12.html
保存版・キャリア相互接続「相関図」
http://www.zdnet.co.jp/broadband/0305/28/lp13.html

SIPももうちょっと有名になりゃあなぁ・・・・

充分有名だと思うよ
ただ最近どこもボロが出始めてるかんじ
だめなとこは（シグナリングを変えても）だめ

SIPがダメだといいたいのか、ダメな日本のメーカーを指しているのかどっちだ？

前者ならばこの板では具体的に問題をのべるべきだと思うが。後者はううむ・・

DNS を扱ったことないやつらが SIP 扱ってる時点で駄目ぽ。

NAPTRが理解できない香具師ハケーソ

Partysip って statefull だったんだ・・・、ちょっと驚き。

http://www.nongnu.org/partysip/FAQ-partysip.html#whatispartysip3