HTTPトンネリングではRTSPヘッダーはbase64Encodeされてくるのでbase64Decodeします。trimTrailingZeros);}このオプションはbase64Encode過程で追加されたpadding-bitをトリミングします。}逆にbase64Encodeする場合は入力文字数によって,padding文字”=”を詰めることが必要です。(RFC4648)続いて,GETハンドリング時を行うhandleHTTPCmd_TunnelingGETでHashTableクラスからsessionCookieを生成しています。(void*)this);これをPOST時に参照してoverHTTPの手続きを踏んでいるか確認しているようです。Allowedを返しています。RTCP.cppはRTCPというRTPでデータを送受信するためのセッションを制御するプロトコルの実装クラスです。ここではonReceiveとsendReportが中心的な機能です。(RTSPServer::RTSPClientConnection*)(fOurServer.fClientConnectionsForHTTPTunneling->Lookup(sessionCookie));RTCP/RTPポートの設定はOnDemandServerMediaSubsession.cppで行っています。設定を行うgetStreamParametersメソッドが呼ばれるタイミングはSETUPコマンドのハンドリング中です。RTCPのポートはRTPの+1で設定しています。fOurServer.fClientConnectionsForHTTPTunneling->Remove(fOurSessionCookie);RTSPClientSessionではRTSPメソッドのハンドリングをしています。POSTの中ではBASE64でエンコード化されたRTSPメソッドがクライアントから投げられるので、POST自体のコネクションを閉じずにRTSPレスポンスを返す必要があります。これをHTTPサーバをベースに実装しようとするとクライアントからエンティティボディが32767という最大サイズで来て、リクエストが終了する前からリクエストパース処理を開始するという仕組みが必要になるので,TCPベースのプロトコルであるHTTPサーバとUDPベースのRTP/RTSPサーバでは思想が違う点で難しいかもしれません。RTSPサーバを改造した方が,HTTPベースの配信はそもそもoptionであるという点からもスマートだと言えるかもしれません。RTSPはRFC2326で定義されています。POSTの流れが必要であることの理解が早いと思います。liveMediaではさらにh264やMPEGなどの様々なフォーマットのハンドリング、TCPStreamSinkなどのストリーム機能、Digest認証の機能があります。mediaServer基本となるアプリケーションの雛形が含まれています。testProgsサンプル用のテストプログラム群です。通信プロトコルの手続き確認や自分でアプリケーションを作るときの参考になります。wis-streamerLive555を活用したRTSPサーバのアプリケーションです。Live555のサイトから別途ダウンロードできます。wis-streamer.cppでは配信Portの設定やoverHTTPのEnable設定が行えます。先頭の方でコンストラクタを取得しています。}UDPベースの配信はUnicast,overHTTPはMulticast対応みたいですね。authDB)でRTSPサーバをインスタンス化しています。デフォルトで65秒に設定されます。これはクライアントの生存確認を行う機能のようで,TEARDOWN以外でセッションが閉じられた時にサーバは知る由がないですが65秒経過したときにチェックが入りこの時点でセッションは破棄されます。タイムアウトを指定しない場合は明示的にNULLを指定します。先ほどのWISInputクラスのインスタンスをsetupUnicastStreamingもしくはsetupMulticastStreamingに渡しています。}ServerMediaSessionのインスタンスをRTSPserverクラスのaddServerMediaSessionメソッド内でstreamNameを取得しfServerMediaSessionsにAddしています。(void*)serverMediaSession);}最後にRTSPサーバのイベントループに入りクライアントからの接続を待ちます。クラスの継承による拡張性に重点をおいた設計になっています。Elmastudio。