15장. SDP 개요
1. SDP의 개요
SDP는 Session Description Protocol의 약어로 멀티미디어 세션 파라미터를 협상하는 프로토콜입니다. SDP는 RFC 2327을 개정한 RFC 4566으로 권고되었습니다. H.323 프로토콜 슈트에서 볼 때, H.225가 시그널링에 대해 정의하고, H.245가 Capability Exchange를 정의합니다. 마찬가지로 SIP 프로토콜이 시그널링에 대해 정의하고, SDP가 Capability Exhange를 정의합니다. SDP는 SIP 뿐만 아니라 MGCP와 Megaco에서도 사용합니다.
SIP는 요청과 응답 모델 (Request & Response Model)로 정의하였고, SDP는 제안과 수락 모델 (Offer & Answer Model)로 정의합니다. SDP의 Offer / Answer Model로의 동작에 대해서는 RFC 3264 An Offer/Answer Model with the SDP에서 설명합니다.
<그림 15-1> SDP는 제안과 수락 모델
SDP는 Capability를 협상하기 위해 SIP 호 처리 절차를 활용합니다. SDP는 협상 내용을 SIP의 요청과 응답에서 사용되는 SIP 메시지 바디에 포함되어 전달합니다. 예를 들어, SIP INVITE 메시지에 SDP Offer가 포함되고 200 OK 응답 메시지에 때 SDP Answer가 포함됩니다.
2. SDP 메시지 분석 개요
SDP는 멀티미디어를 전달하는 RTP 프로토콜에 대한 세부적인 내용을 협상합니다. SDP는 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
각 라인의 의미는 다음과 같습니다.
1) v=0 (필수)
SDP 프로토콜의 버전을 표시합니다. SDP 버전은 0입니다.
2) o=alice 2890844526 2890844526 IN IP4 atlanta.com (필수)
SDP 메시지를 생성한 Owner/creator를 표시합니다. 순서대로 Username, Session-ID, Session Version, Network Type, Address Type, Unicast Address를 표시합니다.
3) s= (필수)
세션 이름을 표시합니다.
4) c=IN IP4 10.1.3.33 (옵션)
순서대로 Network Type, Address Type, Connection-Address이며, RTP 프로토콜이 사용할 주소를 정의합니다.
5) t=0 0 (필수)
Timing으로 start-time과 stop-time을 표시합니다. 0 0 은 고정 세션을 의미합니다.
3. SDP 메시지 분석 (m= & a= )
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
1) m=audio 16444 RTP/AVP 0 8 18 101
Media Description으로 Media, Port, Protocol, Format을 정의합니다.
Media (m=audio 16444 RTP/AVP 0 8 18 101)
RTP 프로토콜의 페이로드가 무엇인지를 선언
audio, video, text, application, message 중에서 표시
Port
미디어가 전송될 전송 포트(Transport port) 표시
UDP 16384에서 32767 사이의 번호를 무작위로 선택
Protocol
UDP, RTP/AVP, RTP/SAVP 중에서 표시
AVP는 Audio Video Profile의 약자
Format
미디어의 포맷을 서브 필드 (a=)로 표시함을 의미
Payload Type 0 8 18의 순서는 코덱 협상의 우선순위를 표시
Payload Type 101은 DTMF 이벤트를 정의
2) a=rtpmap:0 PCMU/8000
미디어 속성(attribute)을 정의합니다.
a=rtpmap
payload type, encoding name/clock rate를 표시
a=ptime
packet time으로 미디어 패킷 한 개가 포함한 시간 정보로 ms로 표시
보통 20ms로 표시
a=fmtp
미디어 포맷에 대한 파미 미터를 정의
3) a= (미디어의 방향)
RTP 프로토콜이 전달하는 미디어 속성뿐만 아니라 미디어 방향도 표시합니다.
a=sendrecv
단말은 미디어 송신 및 수신 가능
예) 전화기로 통화가 가능한 채널
a=recvonly
단말은 미디어 수신만 가능
예) 전화기로 링백톤 수신만 가능한 채널
a=sendonly
단말은 미디어 송신만 가능
예) 마이크 기능만 있는 단말로 송신만 가능한 채널
a=inactive
단말은 송신 및 수신이 불가능
예) 전화기에서 Hold 버튼을 누른 상태
별도의 언급이 없을 때는 'a=sendrecv'로 가정합니다. 미디어의 방향은 전화 부가 서비스를 구현 시 유용합니다. 예를 들어, 묵음 버튼을 누르면 SDP 협상을 통해 'a=recvonly'로 설정하면 듣기만 가능합니다.
4) a= (DTMF 협상)
DTMF는 통화 중에 Digit (숫자)을 전달할 수 있도록 하고, 어떤 방식으로 할지를 결정합니다. 여기서는 간단하게만 다루고 뒤에서 자세히 다룹니다.
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가지를 송수신
4. RFC 3264의 기본 SDP 협상의 이해
RFC 3264 An Offer/ Answer Model Session Description Protocol 권고안의 10.1 Basic Exchange 부분에 설명된 예제를 통해 Offer / Answer 모델을 이해해 봅니다. SIP 호처리 절차는 무시합니다.
1) 엘리스의 “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의 제안(Offer)의 Owner이자 Creator인 엘리스의 단말기 주소는 host.anywhere.com입니다. RTP는 이 주소로 보내질 것입니다. 앨리스는 다음과 같이 제안하였습니다.
음성 스트림 채널 1
G.711 ulaw 코덱(PCMU) , 49170 UDP 포트, 별도로 언급이 없으므로 양방향 채널
영상 스트림 채널 1
H.261 코덱 (페이로드 타입 31), 51372 UDP 포트, 별도로 언급이 없으므로 양방향 채널
영상 스트림 채널 2
MPEG 코덱 (페이로드 타입 32), 53000 UDP 포트, 별도로 언급이 없으므로 양방향 채널
2) 밥의 “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
SDP의 제안(Answer)의 Owner이자 Creator인 밥의 단말기 주소는 host.example.com입니다. RTP는 이 주소로 보내질 것입니다. 밥은 다음과 같이 수락하였습니다.
음성 스트림 채널 1
G.711 ulaw (PCMU) 코덱, 49920 UDP 포트, 별도로 언급이 없으므로 양방향 채널
영상 스트림 채널 1
H.261 코덱을 사용하는 영상 스트림 채널의 개방을 원하지 않으므로 미디어 속성(a=)을 정의하지 않음
영상 스트림 채널 2
MPEG 코덱 (페이로드 타입 32), 53000 UDP 포트, 별도로 언급이 없으므로 양방향 채널
여기서, 미디어 속성(a=)을 포함하지 않으면 미디어 스트림이 개방되지 않습니다.
3) 밥의 협상 변경 요청 “Offer”
SDP Offer/Answer 모델로 상호 간에 Capability Exchange가 완료된 후에 밥은 다시 협상 변경을 요청합니다.
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
SDP 재협상 제안 (Offer) 내용은 다음과 같습니다.
음성 스트림 채널 1
G.711 ulaw (PCMU) 코덱, 별도로 언급이 없으므로 양방향 채널
49920 UDP 포트를 65422로 변경할 것을 요청
영상 스트림 채널 1
H.261 코덱을 사용하는 영상 스트림 채널의 개방을 원하지 않으므로 미디어 속성(a=)을 정의하지 않음
영상 스트림 채널 2
MPEG 코덱 (페이로드 타입 32), 53000 UDP 포트, 별도로 언급이 없으므로 양방향 채널
음성 스트림 채널 2
DTMF 이벤트 처리를 위한 수신전용 (receive-only) 채널
일반적으로 DTMF 이벤트 처리는 RTP Payload Type 110을 사용
정리하면, 음성 스트림 채널 1의 UDP 포트 넘버 변경과 DTMF 이벤트 처리를 위한 음성 채널 개방을 요구하였습니다.
4) 앨리스의 “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
앨리스는 자신이 사용하려고 한 음성 스트림 채널 1개와 영상 스트림 채널 2개에 밥이 추가적으로 제한한 DTMT 이벤트용 음성 채널을 송신 전용으로 오픈합니다.
5) 정리
정리하면, SDP Offer와 Answer는 사용할 수 있는 모든 미디어 속성을 정의하는 과정입니다.
<그림 15-2> RFC 3262의 SDP 협상 예제5. RFC 3264의 여러 코덱 중에 하나의 코덱을 선택하기 (One of N Codec Selection)
IP 전화기와 음성 게이트웨이는 음성과 영상을 압축하기 위해 DSP (Digital Signal DSP) 칩을 사용합니다. DSP 칩은 다수의 음성 또는 영상 압축코덱을 지원하지만 전화 통화는 하나의 음성 코덱만을 사용합니다. 영상 통화는 하나의 음성 코덱과 하나의 영상 코덱을 선택합니다. 즉, SDP Offer에 다수의 코덱을 정의하더라도 하나의 미디어 채널은 SDP Answer를 통해 하나의 코덱을 선택합니다.
다수 코덱을 제안하고 우선순위에 따라 하나의 코덱을 선택하는 과정을 정리해봅니다.
1) 앨리스의 제안 (Offer)
앨리스의 SDP Offer는 하나의 음성 스트림 하나를 제안합니다.
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
정리하면, 다음과 같습니다.
음성 스트림 채널 1
G.711 ulaw (PCMU), G.723과 G.729 음성 코덱 지원 가능
'm='에 정의된 순서대로 앨리스는 G.711 ulaw를 선호
코덱 협상 완료 전까지는 통화가 불가능하므로 미디어의 방향을 'a=inactive'로 선택
2) 밥의 수락 (Answer)
밥의 SDP Answer는 하나의 음성 스트림을 수락하고 코덱을 선택합니다.
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
정리하면, 다음과 같습니다.
음성 스트림 채널 1
G.711 ulaw (PCMU), G.723 음성 코덱 지원 가능
'm='에 정의된 순서대로 앨리스는 G.711 ulaw를 선호
코덱 협상 완료 전까지는 통화가 불가능하므로 미디어의 방향을 'a=inactive'로 선택
3) 앨리스의 제안 (Offer)
앨리스는 밥이 제안한 두 개의 코덱 모두를 지원할 수 있지만 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
정리하면, 다음과 같습니다.
음성 스트림 채널 1
G.723 음성 코덱 지원 가능
코덱 협상이 완료되면 사용하기 위해 양방향으로 미디어 채널 오픈
일반적으로, 서로가 가장 높은 우선순위로 G.711 ulaw를 선택하지만 예제는 G.723을 선택하는 것으로 가정합니다.
4) 밥의 수락 (Answer)
밥은 앨리스가 제안한 G.723 코덱을 선택합니다. 들이고 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
정리하면, 다음과 같습니다.
음성 스트림 채널 1
G.723 음성 코덱
코덱 협상이 완료되면 사용하기 위해 양방향으로 미디어 채널 오픈
5) 정리
일반적으로는 처음부터 a=sendrecv로 교환하고 우선순위가 높은 코덱을 선택합니다. 한 번의 SDP Offer / Answer 과정으로 코덱을 선택합니다만, 이 예제는 처음 inactive 상태를 sendrecv로 전환하기 위해 4번에 걸친 Offer와 Answer를 교환하는 과정을 보여줍니다.
<그림 15-3> 여러개의 코덱 중 하나 선택하기SIP와 SDP 관계를 생각해보면, INVITE 발행 시에 SDP Offer 가 전달되고 180 Ringing 도는 200 OK 전달 시에 SDP Answer가 함께 전달된다면 수화기를 들자마자 미디어 속성이 결정되어 통화가 가능합니다.
'엔지니어를 위한 인터넷 전화와 SIP의 이해'를 책으로 만들다
https://brunch.co.kr/@linecard/188
