SIP SDP

Overview

참조 원문은 이곳<ref>http://www.nexpert.net/497</ref><ref>http://www.nexpert.net/142</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와 같이 텍스트 기반으로 구성된다.

Session Description

v= protocal version.
o= owner/creator and session identification.
s= session name.
i= (optional) session information.
u= (optional) URI of description.
e= (optional) email address - contact detail.
p= (optional) phone number - contact detail.
c= (optional) connection information - not required if included in media description.
b= (optional) session bandwidth information.
z= (optional) time zone adjustments.
k= (optional) encryption key.
a= (optional) zero or more session attribute lines.

• v=<version>

Specifies the version of Session Description Protocol. As specified in RFC 4566, up to now there is only one version, which is Version 0. No minor versions exist.

• o=<username><sess-id><sess-version><nettype><addrtype><unicast-address>

Details about the originator and identification of the session.

<username>: The user's login. The MUST NOT contain spaces.

<sess-id>: A numeric string used as unique identifier for the session.

<sess-version>: A numeric string used as version number for this session description.

Time description

t= time the session is active.
r= (optional) repeat times.

• Media description

m= media name/transport address.
i= (optional) media title
c= (optional) connection information - not required if included in session description.
b= (optional) bandwidth information.
k= (optional) encryption key.
a= (optional) zero or more media attribute lines.

Example

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= (필수)

세션 이름을 표시한다.

• i=(optional)

Session information.

• u=(optional)

URI of description.

• e=(optional)

Email address - contact detail.

• p=(optional)

Phone number - contact detail.

• c=IN IP4 10.1.3.33 (optional)

순서대로 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 단계로 마무리된다.

Early Media in SDP (RFC 3959, RFC 3960)

Early Media 란, 실제 통화가 이루어 지기 전 전송되는 Media 를 의미한다. 대표적인 예로 컬러링이 있다.

Early Media 의 개요

아래 그림은 일반적인 SIP 호 설정 시나리오이다. 앨리스는 수화기를 들어 전화번호를 누르면 INVITE 메시지와 함께 Offer가 이루어진다. 밥의 전화기는 Ringing (따르릉)하게되며, 180 Ringing 메시지가 앨리스에게 전달된다. 180 Ringing을 받은 앨리스는 Local Ringback을 들으면서 밥의 전화기가 울리고 있다고 인지한다. 밥은 Ringing 소리를 듣고 전화가 왔음을 인지하게 되어 전화기로 다가가 수화기를 드는 순간 200 OK 메시지와 Answer가 앨리스에게 전달된다. 200 OK를 받은 앨리스는 ACK를 밥에게 전송하며 통화가 시작된다.

그런데 일반적인 SIP 통화 시나리오 상에서 다음 두 가지 문제가 발생하게 된다.

• Remote Ringback

180 Ringing 메시지를 전달받은 앨리스의 전화기는 자체적으로 Ringback tone을 발생시킨다. 그러나, 현실에서는 컬러링이나 Remote Ringback tone을 들을 수 있어야 한다.

• Media Clipping

보통 사람들은 수화기를 들면서 "여보세요"라고 말한다. 위의 시나리오는 200 OK를 보내고 ACK를 받을 때까지의 이야기는 전달할 수 없게 된다. 따라서 Media Clipping이 발생할 수 밖에 없어 밥의 "여보세요"가 앨리스에게는 "세요"라고 들릴 것이다.

이러한 문제점은 SDP의 일반적인 Offer/Answer 절차 이전에 Media가 전송되어져야 한다는 것을 의미한다. 즉, Early Media는 정규 Offer/Answer 절차 이전에 전송되는 RTP를 가리킨다. 그렇다면, Early Media의 발생시점은 INVITE의 생성에서부터 ACK 신호까지이다. ACK 이후에는 정상적인 Media가 전송된다.

SDP 협상의 방식

기본적으로 Early Media가 동작하기 위해서는 위의 그림과 같이 INVITE with SDP로 Initial Offer 가 발생되어야 한다. 위에서 언급한 Media Clipping의 경우, Invite with SDP (offer)로 보내지는 대부분의 경우 이러한 Media Clipping은 발생되지 않는다. UAC(송신자)는 200 OK의 수신 여부와는 상관없이 Offer를 하자마자 자기 스스로 들어오는 Media에 대해 재생할 준비를 하도록 되어 있다. 그러나, 이렇게 Invite with SDP 만 있는 것이 아니다.

아래와 같이 200 OK에 밥이 먼저 Offer를 할 수도 있으며, Update 메소드를 이용하여 SDP를 교환할 수도 있다.

Early Media 의 두 가지 모델

RFC 3960에 의하면, Early Media는 다음과 같이 두 가지 모델로 구분할 수 있다.

• Gateway Model

이 모델은 SIP 시그널링 상에서 Early Media에 대한 특별한 언급없이 동작한다. 180 Ringing 메시지를 받으면, Local Ringback Tone을 발생시키고, 상대방으로부터 RTP(Early Media)가 전송되면, Local Ringback Tone 발생을 중단하고, RTP를 재생한다. 이 Gateway 모델의 문제점은 Forking 및 Security 문제가 있다.

• Application Server Model

SIP 시그널시 Early Media에 대한 Offer/Answer를 가능하게 한다. RFC 3959에 정의된 Content-Disposition 헤더에 Session 또는 Early-session의 새로운 Disposition Type을 설정하여 Early-Media가 가능하게 한다.

Ringback Tone 재생 정책

PSTN 상에서 수신자가 Alert 메시지를 보내면 Ringback Tone은 PBX에 의해 재생된다. SIP의 경우 UAS(수신자)에 의해 Ringback 이 재생되지 않으면, UAC에서 자체적으로 Ringback tone을 재생하기로 되어 있다. 만일, Announcement 또는 Special Ringing Tone이 UAS에 재생이 되면, UAC는 자체적인 재생을 중단하고 UAS로 부터 오는 Media를 재생하는 것이 일반적이다. 그러나, UAS가 Early Media 를 전송하려는 의도 없이 Early Offer를 진행하기도 하고, Reliable Provisional Response 없이 Ealry Media를 전송하기도 하기 때문에 UAC는 쉽게 Local Ringback Tone을 재생해야할 지 말아야할 지를 결정할 수 없다.

Local Ringback Tone 재생에 관련해서 다음과 같은 정책을 구현해야 한다.

- 180 Ringing 을 받지 않았다면, Local Ringing 을 재생하지 않는다.
- 180 Ringing 을 받았으나 수신되는 Media 패킷이 없다면, Local Ringing을 재생한다.
- 180 Ringing 을 받았으면서 Media 패킷이 수신된다면, Media를 재생하고 Local Ringing을 재생하지 않는다.

180 Ringing은 수신측이 전화기가 울리고 있음을 의미한다.

Application Server Model 상에서의 Early media

Early Media Session 은 지금까지 이야기한 Regual Session에서 함께 처리된다. 그러나, Application Server Model은 Early Media를 위한 별도의 절차를 수행한다. 따라서, 하나의 호 시그널링에서 Early Media Session과 Regular Session 을 동시에 Offer/Answer를 수행한 후 전환한다. 이 때, Content-Disposition Header 에 Session 과 Early-session 이라고 하여 각각의 쓰임새를 구분한다.

Early session 이 Regular session 으로 전환될 때, 코덱을 변경할 필요가 없도록 하기 위하여 Early Media session 과 Media session은 같은 코덱을 사용하는 것을 권장한다. RFC 3959의 예제를 보자.

앨리스는 밥에게 Contect-Disposition: session 헤더를 INVITE에 추가해서 전송한다. 이 헤더의 의미는 INVITE에 포함된 Offer는 Regular session 에 대한 것임을 표시한다.

Content-Type: application/sdp
Content-Disposition: session

v=0
o=alice 2890844730 2890844731 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0

이후 밥은 183 Session Progress를 앨리스에게 전송한다. 이때, 다중 메시지가 포함되었음을 의미하는 Content-Type:multipart/mixed 라는 정보를 함께 보낸다. Content-Disposition 헤더를 보면 session과 early-session 두가지가 있는데, 첫번째 바운더리인 Content-Disposition:Session은 Regular session에 대한 것으로 기존의 INVITE with offer에 대한 answer의 내용이다. 두번째 바운더리인 Content-Disposition:early-session은 Early Media를 위한 Offer이다.

Content-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
--boundary1
Content-Type: application/sdp
Content-Disposition: session

v=0
o=Bob 2890844725 2890844725 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30000 RTP/AVP 0

--boundary1
Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=Bob 2890844714 2890844714 IN IP4 host.sip.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30002 RTP/AVP 0

--boundary1--

앨리스는 INVITE에 대한 200 OK (수화기를 드는 행동)를 밥으로 받기 전까지 Early-Offer에 대한 Answer를 할 수 있는 방법이 없다. 따라서 이때 PRACK 이 필요하다. 이 메소드를 통해 아래와 같이 Early Offer 에 대한 Answer 를 수행한다.

Content-Type: application/sdp
Content-Disposition: early-session

v=0
o=alice 2890844717 2890744717 IN IP4 host.sip.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20002 RTP/AVP 0

PRACK에 대한 200 OK 를 받게 되면, Early Media를 통해 대화가 가능하다. 이미 Regular session 과 Early session 에 대한 Offer / Answer가 완료되었다.

밥이 수화기를 들어 200 OK 를 전송할 때, Early session 은 Regular session 으로 전환이 이루어진다.

See also

• https://www.3cx.com/blog/voip-howto/sdp-voip/

References

<references />