SIP SDP

Overview

원문은 이곳<ref>http://www.nexpert.net/497</ref>에서 확인할 수 있다.

SDP는 코덱 협상과 같은 Capability Exchange 를 수행하는 프로토콜로 SIP 뿐만 아니라 MGCP와 Megaco에서도 사용한다. 기술적으로는 SIP와 SDP 프로토콜을 구분해서 사용하지만, SIP를 살펴볼 때 SDP는 자연스럽게 언급된다.

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 33264 An Offer/Answer Model with the SDP 에서 자세히 설명되어 있다.

SDP는 Capability를 협상하기 위해 기존의 호 처리 프로토콜을 이용한다. 위의 그림에서처럼 SDP는 SIP 메시지와 함께 전달된다. SIP INVITE 메시지에 SDP Offer가 포함되거나 200 OK 응답 메시지에 SDP Answer 가 포함된다.

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과 End-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= (미디어 속성)

미디어 속성(attributer)을 정의한다.

a=rtpmap : Payload type, encoding name/clock rate 를 표시

a=ptime : Packet 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 가지를 송수신 함.

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.711 ulaw 코덱과 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

밥의 요청을 모두 수락한다.

RFC 3264의 One of N Codec Selection

IP Phone과 Gateway는 음성이나 영상 압축을 위해 DSP (Digital Signal Processor)라는 칩을 사용한다. DSP는 다수의 코덱을 지원하지만, 한 번에 하나의 코덱만을 지원한다. SDP Offer에 다수의 코덱을 전송하더라도 Answer 에서는 하나의 코덱만을 선택할 수 있다. 다수 코덱을 제안할 경우에 선택하는 방식에 대해서 알아보자.

앨리스의 "Offer"

Offer이자 Creator인 엘리스는 음성 스트림 하나만을 제안하면서 자신의 DSP가 지원하는 G.711 ulaw, G.723, G.729 코덱을 나역한다. G.711 ulaw 가 가장 우선 순위가 높으며, 코덱 협상 완료 전까지는 미디어를 맏아 들일 수 없으므로 미디어의 방향을 "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.711 ulaw와 G.723 코덱만을 지원하며, G.711 ulaw를 우선적으로 선택한다.

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.711 ulaw를 선택하지만, 예제에서는 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 to sendrecv

처음 inactive 상태를 sendrecv로 전환하기 위해 4번에 걸친 Offer와 Answer를 교환한다. 일반적으로는 처음부터 a=sendrecv로 교환하고, 처음 제시되는 코덱이 우선순위가 높으므로 선택된다. 위의 과정은 Offer/Answer Model을 기반으로 설명하는 것이지만, 실제로는 INVITE with SDP로 제안이 되며, 200 OK with SDP 또는 180 Ringing with SDP로 2 단계로 마무리된다.

References

<references />