この “ブログ” では，情報通信技術を中心とする各種のみじかい調査結果や解説をとりあげます．
この “ブログ” の目的については 「SIP によって管理されるセッションにおける IntServ (Integrated Services, 統合サービス) 型の資源管理の方法の基本については 2002 年 10 月に発行された IETF 標準である RFC 3312 (G. Camarillo, W. Marshall ed., J. Rosenberg: Integration of Resource Management and SIP) に記述されている．
この方法においては SIP のメッセージ上に SDP による QoS 情報をのせて通信相手と交渉し，その結果に従って「IntServ と RSVP」において示した RSVP (Resource ReSerVation Protocol, 資源予約プロトコル) の Path および Resv メッセージを交換して資源を確保する． この RFC においてはこの方法における SIP のシーケンスおよび SIP メッセージにのせる SDP メッセージの内容などについて規定している．前記の RFC 3312 から基本の SIP シーケンスを引用する (図 1)．
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
図 1 資源管理をともなう基本の SIP シーケンス
このシーケンスにおいてはまず A から B に対して INVITE 要求を送信しているが，このメッセージは資源確保のための SDP メッセージ (SDP1) を含んでいる．SDP メッセージの例を前記の RFC 3312 から引用する．
m=audio 20000 RTP/AVP 0
a=curr:qos e2e send
a=des:qos optional e2e send
a=des:qos mandatory e2e recv
m=audio 20002 RTP/AVP 0
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos mandatory remote sendrecv
B は INVITE 要求に対して仮の応答 183 Session Progress をかえす．この時点から RSVP を使用した資源予約が開始される． 上記の応答に対して A は PRACK (仮の ack) をかえし，B はそれに 200 OK の応答をかえす． 資源が予約された時点で A は B に UPDATE 要求を送信するが，このメッセージのなかに実際に確保された資源に関する情報が SDP の形式で含まれている．以下の部分の説明は省略する．
上記の SDP メッセージにおいては通信帯域幅については指定されていないが，それを指定する方法については 2003 年 7 月に発行された IETF 標準である RFC 3556 (S. Casner: Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth) において規定されている． 前記の RFC 3556 から SDP メッセージの例を引用する．
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
b=AS:64
b=RS:800
b=RR:2400
m=video 51372 RTP/AVP 31
b=AS:256
b=RS:800
b=RR:2400
太字で示したのが帯域幅の指定であるが，AS はアプリケーションが使用する帯域幅，RS および RR は RTCP が使用する帯域幅であるが，詳細は省略する．
1 個の INVITE 要求によって複数個のメディア・ストリーミングが開始される場合があるが，このような場合に 1 個の RSVP メッセージングを使用するのか複数個のそれを使用するのかという問題がある． この問題に関しては 2003 年 4 月に発行された IETF 標準である RFC 3524 (G. Camarillo, A. Monrad: Mapping of Media Streams to Resource Reservation Flows) において答えられている． 簡単にいうと，SDP メッセージにおいてたばねられているストリームについては 1 個の RSVP メッセージングが適用され，たばねられていないストリームについては個別の RSVP メッセージングが適用される． SDP 上でストリームをたばねる機構については 2002 年 12 月に発行された IETF 標準である RFC 3388 (G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne: Grouping of Media Lines in the Session Description Protocol (SDP)) において規定されている．
前記の RFC 3388 におけるオーディオとビデオのストリームをたばねて lip synchronization (音声とビデオにおける唇の動きを同期させること) させるための SDP メッセージの例を示す．
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t=0 0
c=IN IP4 224.2.17.12/127
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation
a=mid:3
ここで太字で示した行においてストリーム 1 (オーディオ) とストリーム 2 (ビデオ) との lip synchronization (LS) をともなうグルーピングが指定されている． この SDP メッセージにおいては 2 個のオーディオ・ストリームが記述されているが，ストリーム 3 はグルーピングされていない． なお，インターネット・ドラフト draft-ietf-mmusic-sdp-bwparam-05 においては IPv4 と IPv6 が共存するようなネットワークにおける帯域パラメータの指定法が議論されている．
RFC 3521 においてはさらにポリシーによって管理された資源予約と認可の方法が記述されているが，これについてはポリシー管理の調査結果とあわせて報告する．
