Chapter 5. SDP
SDP는 코덱협상과 같은 Capability Exchange를 수행하는 프로토콜로 SIP 뿐만 아니라 MGCP와 Megaco에서도 사용합니다. 기술적으로는 SIP와 SDP 프로토콜을 구분해서 사용하지만, SIP를 살펴볼 때 SDP는 자연스럽게 언급됩니다. SIP와 SDP는 어떤 관계에 있는 지 살펴보겠습니다.
1.SDP의 개요
SDP는 Session Description Protocol 의 약어로 멀티미디어 세션 파라미터를 협상하는 프로토콜입니다. SDP는 RFC 2327을 개정한 RFC 4566으로 권고되었습니다. H.323에 대한 이해가 있으신 분들은 SDP가 H.323 프로토콜의 H.245와 비슷한 역할을 수행한다고 생각하면 됩니다.
SIP를 요청과 응답 모델 (Request & Response Model)로 정의하였듯이 SDP는 제안과 수락 모델 (Offer & Answer Model) 로 정의합니다. SDP의 Offer / Answer Model로의 동작에 대해서는 RFC 3264 An Offer/Answer Model with the SDP 에서 자세히 설명되었습니다.
SDP는 Capability를 협상하기 위해 기존의 호 처리 프로토콜을 이용합니다. 위의 그림에서 처럼 SDP는 SIP 메세지와 함께 전달됩니다. SIP INVITE 메세지에 SDP Offer가 포함되거나 200 OK 응답 메세지에 때 SDP Answer가 포함됩니다.
2. SDP 메세지 분석
SDP는 멀티미디어를 전달하는 RTP 프로토콜에 대한 세부적인 내용을 협상합니다. SDP는 아래와 같이 SIP와 다른 메세지 포맷을 유지하지만, SIP와 같이 텍스트 기반으로 구성됩니다.
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.com
s=
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
각 라인의 의미는 다음과 같습니다.
- v=0 (필수)
SDP 프로토콜의 버전을 표시합니다. SDP 버전은 0 입니다. - o=alice 2890844526 2890844526 IN IP4 atlanta.com (필수)
SDP 메세지를 생성한 Owner/creator 를 표시합니다. 순서대로Username, Session-ID, Session Version, Network Type, Address Type, Unicast Address를 표시합니다.
- s= (필수)
세션 이름을 표시합니다. - c=IN IP4 10.1.3.33 (옵션)
순서대로Network Type, Address Type, Connection-Address를 나타내며 미디어의 주소를 정의합니다. - t=0 0 (필수)
Timing으로 start-time과 stop-time을 표시합니다. 0 0 은 고정 세션을 의미합니다.
SDP의 Capability Exchange를 주도하는 라인은 m= 와 a= 로 RTP가 사용할 코덱, IP 주소, 포트넘버가 자세히 명기됩니다. SDP 메세지를 생성하는 UA는 자신이 지원가능한 모든 코덱과 능력을 아래와 같이 명기합니다.
m=audio 16444 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
- m= (미디어 설명)
Media Description으로 Media, Port, Protocol, Format을 정의합니다.
- Media : audio, video, text, application, message로 표시
- Port : 미디어가 전송될 전송포트(Transport port) 표시
- Protocol : UDP, RTP/AVP, RTP/SAVP로 표시하며 AVP는 Audio VIdeo Profile의 약자
- Format : 미디어의 포맷을 서브필드 (a=)로 표시함을 의미
Payload Type 0 8 18의 순서는 코덱협상의 우선순위를 나타내며, Payload Type 101은 DTMF 이벤트를 정의합니다. 각 포맷에 대한 상세 설명은 a=에 표시됩니다.
- a= (미디어 속성)
미디어 속성(attribute)을 정의합니다.
- a=rtpmap : payload type, encoding name/clock rate를 표시
- a=ptime : paket time으로 미디어 패킷 한 개가 포함한 시간 정보로 ms로 표시 (보통 20ms)
- a=fmtp : 미디어 포맷에 대한 파미미터를 정의 - a= (미디어의 방향)
미디어 속성 뿐만 아니라 미디어 방향도 표시합니다. 미디어의 방향은 아래와 같이 4가지로 나타냅니다.
- a=sendrecv : 단말은 미디어를 송신 및 수신할 수 있음
- a=recvonly : 단말은 수신만을 할 수 있으며 송신하지 않음
- a=sendonly : 단말은 송신만을 할 수 있으며 수신하지 않음
- a=inactive : 단말은 송신 및 수신을 할 수 없음 (Hold 버튼을 누를 경우)
별도의 업급이 없을 경우에는 a=sendrecv로 설정되었다고 가정합니다. 미디어의 방향은 다양한 부가서비스 구현 시 유용합니다.
- a= (DTMF 협상)
DTMF 전달에 관한 협상도 진행합니다.
- a=rtpmap:101 telephone-event.8000 (RFC 2833에 의한 In-band DTMF를 의미)
- a=fmtp 101 0-15 (DTMF Tone은 0,1,2,3,4,5,6,7,8,9,0,*,#,A,B,C,D 총 15가지를 송수신함)
3. RFC 3264의 기본 SDP 협상 (Offer / Answer Model)
RFC 3264 An Offer/ Answer Model Session Description Protocol 권고안에 나와 있는 10.1 Basic Exchange 부분을 살펴보면서 Offer / Answer 모델의 동작 방식을 살펴보겠습니다.
- 엘리스의 “Offer”
엘리스는 한 개의 음성 스트림과 두 개의 영상 스트림을 제안합니다.
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
SDP의 Owner이자 Creator인 엘리스는 음성 스트림은 G.711 ulaw 코덱과 49170 UDP 포트를 사용하며, 영상 스트림은 H.261 코덱과 51372 UDP 포트를, 또 하나의 영상 스트림은 MPEG 코덱과 53000 UDP 포트를 사용한다고 제안합니다.
- 밥의 “Answer”
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
밥은 음성 스트림에 대해 G.711ulaw 코덱과 49920 UDP 포트를 사용하고, 첫번째 영상에 대한 미디어 속성(a=) 정의를 포함하지 않고, 두 번째 영상 스트림에 대해서만 미디어 속성을 포함하고 있습니다. 일반적으로 미디어 속성(a=)를 포함하지 않으면 미디어 스트림이 개방되지 않습니다.
- 밥의 협상 변경 요청 “Offer”
밥은 Answer 후에 협상 내용의 변경을 요청합니다.
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonly
밥은 음성 스트림에 대한 UDP 포트 넘버를 49920에서 65422로 변경하는 것과 DTMF 수신을 위한 (receive-only) 방법을 추가하였습니다. 일반적으로 DTMF 이벤트 처리를 위한 RTP Payload Type 110 입니다.
- 앨리스의 “Answer”
앨리스는 밥의 제안을 승인하고, 다음과 같이 응답합니다.
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly
밥의 요청을 모두 수락합니다.
4. RFC 3264의 One of N Codec Selection
IP Phone과 Gateway는 음성이나 영상 압축을 위해 DSP (Digital Signal DSP)라는 칩을 사용합니다. DSP는 다수의 코덱을 지원하지만, 한 번에 하나의 코덱만을 지원합니다. SDP Offer에 다수의 코덱을 전송하더라도 Answer에서는 하나의 코덱만을 선택할 수 있을 뿐입니다. 다수 코덱을 제안할 경우에 선택하는 방식에 대해 살펴보겠습니다.
- 앨리스의 “Offer”
Offer의 Creator인 엘리스는 음성 스트림 하나를 제안하면서 자신의 DSP가 지원하는 G.711ulaw, G.723, G.729 코덱을 나열합니다. G.711ulaw가 가장 우선 순위가 높으며 코덱 협상 완료전까지는 미디어를 받아 들일 수 없으므로 미디어의 방향을 "a=inactive"로 합니다.
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
- 밥의 “Answer”
밥은 자신의 DSP가 G.711ulaw 와 G.723 코덱만을 지원하며, G.711ulaw를 우선적으로 선택합니다.
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
- 앨리스의 "Offer"
앨리스는 밥이 제안한 두 개의 코덱 모두를 지원할 수 있지만 G.723코덱을 선택하면서 "a=sendrecv" 로 양방향 통화 채널을 활성화 합니다. 일반적으로 우선순위가 높은 G.711ulaw를 선택하지만, 예제에서는 G.723을 선택하는 것을 가정합니다.
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
- 밥의 "Answer"
밥은 앨리스가 제안한 G.711 코덱을 받아 들이고 a=sendrecv로 양방향 통화 채널을 활성화합니다.
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
처음 inactive 상태를 sendrecv로 전환하기 위해 4번에 걸친 Offer 와 Answer를 교환합니다. 일반적으로는 처음부터 a=sendrecv로 교환하고, 처음 제시되는 코덱이 우선순위가 높으므로 선택됩니다. 위의 과정은 Offer / Answer Model을 기반으로 설명드리는 것입니다만, 실제로는 INVITE with SDP로 제안이 되면 200 OK with SDP 또는 180 Ringing with SDP로 2 단계로 마무리됩니다.
마치며
실제 SIP 패킷을 캡쳐해 보면 INVITE with SDP 뿐만 아니라 INVITE without SDP 메세지도 보입니다. SIP 표준은 두 경우를 모두 허용하고 있으므로 각각의 상황에 따른 SDP 협상 방식을 다음글에서 살펴보겠습니다.
여담
2015년 새해에도 지치않는 블로깅을 다짐합니다. 쓰고 싶은 글은 많은 데 시간이 부족합니다.
"다시쓰는 SIP의 이해" 연재의 다른 글
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method
2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method
2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method
2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method
2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method
2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method
2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method
2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method
2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP
2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP
2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP
2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response
2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261
2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261
2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261
2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview
2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview
2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)
2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)
2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)
라인하트 유씨누스 (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________
