SDP — 세션 설명 프로토콜의 개념과 WebRTC에서의 역할

SDP(Session Description Protocol)란?

SDP는 텍스트 형식으로 멀티미디어 세션 매개변수를 설명하기 위해 설계된 애플리케이션 계층 프로토콜입니다. IETF의 MMUSIC(Multiparty Multimedia Session Control) 워킹 그룹 내에서 개발되었으며 1998년 RFC 2327에서 처음 표준화되었습니다. 2021년에는 이전 버전인 RFC 4566을 대체하는 현재 명세 RFC 8866이 발표되었습니다.

SDP의 주요 작업은 세션 참가자에게 연결 설정에 필요한 모든 정보를 제공하는 것입니다. 어떤 미디어 스트림이 전송될지, 어떤 코덱이 지원되는지, 어떤 네트워크 주소와 포트를 통해 전송이 이루어질지 등을 제공합니다. SDP는 미디어 데이터 자체를 전송하지 않고 연결이 어떻게 구성되어야 하는지만 설명합니다.

IETF RFC 8866에 따르면, SDP 형식은 각각 한 글자 유형으로 시작하고 등호와 값이 이어지는 일련의 행으로 구성됩니다. 예를 들어, m=audio 5004 RTP/AVP 0 행은 세션에 RTP/AVP 전송 프로토콜과 PCMU 코덱(유형 0)을 사용하는 포트 5004의 오디오 스트림이 포함됨을 의미합니다.

SDP의 역사와 표준화

SDP의 첫 번째 버전은 1998년 4월 MMUSIC 그룹의 작업 결과로 RFC 2327에 게시되었습니다. 이 프로토콜은 원래 Mbone(Multicast Backbone) 내에서 멀티캐스트 세션을 알리기 위해 만들어졌습니다. VoIP와 화상 회의의 발전으로 SDP의 적용 범위가 확장되었고, 2006년에 업데이트된 명세 RFC 4566이 발표되었습니다.

SDP 사용의 진정한 돌파구는 2011년 WebRTC의 등장과 함께 이루어졌습니다. Google은 브라우저 기반 실시간 통신 프레임워크에서 미디어 세션을 설명하는 주요 메커니즘으로 SDP를 통합했습니다. 그 이후로 SDP는 브라우저부터 iOS 및 Android의 모바일 애플리케이션에 이르기까지 모든 WebRTC 구현의 필수 구성 요소가 되었습니다.

2021년 IETF 워킹 그룹은 RFC 4566을 대체하는 현재 SDP 명세 RFC 8866을 발표했습니다. 업데이트된 버전은 ICE(Interactive Connectivity Establishment) 처리를 명확히 하고, DTLS(Datagram Transport Layer Security) 지원을 강화하며, 그룹 세션 설명 기능을 확장했습니다.

SDP와 전송 프로토콜의 차이

SDP는 데이터 전송에 참여하지 않는다는 점에서 전송 프로토콜과 근본적으로 다릅니다. 순수하게 설명적인 기능을 수행하며, 멀티미디어 파일 메타데이터와 유사합니다. RTP(Real-time Transport Protocol)가 오디오 및 비디오 패킷을 전송하고 RTCP가 전송 품질을 제어하는 반면, SDP는 사용할 코덱과 포트만 지정합니다.

웹 개발에서의 비유: SDP는 페이지 구조를 설명하는 HTML 마크업과 같고, RTP는 실제 이미지와 텍스트입니다. SDP가 없으면 네트워크 연결이 이미 설정되어 있더라도 세션 참가자는 서로 연결하는 방법을 알지 못합니다. NAT 트래버설 메커니즘(ICE)도 네트워크 후보에 대한 정보를 전송하기 위해 SDP에 의존합니다.

SDP 구조

SDP 구조는 텍스트 행의 시퀀스로 구성되며, 각 행은 type=value 형식을 따릅니다. 한 글자 유형은 행의 목적을 정의하고 값은 해당 값을 포함합니다. 모든 행은 CRLF 문자로 구분됩니다.

RFC 8866 표준은 여러 필수 및 선택적 필드를 정의합니다. 필수 필드에는 프로토콜 버전(v=), 세션 이름(s=), 세션 시작 및 종료 시간(t=)이 포함됩니다. 나머지 필드는 선택 사항이지만 WebRTC 세션의 경우 미디어 설명(m=), 속성(a=) 및 네트워크 정보(c=)도 필요합니다.

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

위의 예는 WebRTC 세션의 일반적인 SDP 세그먼트를 보여줍니다. v=0 행은 프로토콜 버전을 나타냅니다. o= 필드에는 세션 소유자의 식별자와 버전이 포함됩니다. s=- 행은 세션 이름을 지정합니다(하이픈은 빈 이름을 의미). t=0 0 필드는 세션에 시간 제한이 없음을 나타냅니다.

a=group:BUNDLE audio video 필드는 여러 미디어 스트림을 하나의 전송 채널로 그룹화하는 속성입니다. BUNDLE 메커니즘은 단일 연결을 통해 오디오와 비디오를 전송하여 네트워크 리소스를 절약할 수 있게 합니다. 이는 대역폭이 제한된 모바일 장치에서 특히 중요합니다.

SDP 필수 필드

RFC 8866 명세는 필수 및 선택적 필드 집합을 정의합니다. 필수 필드에는 v=(버전), s=(세션 이름), t=(시간)이 포함됩니다. o=(소유자) 필드는 RFC에 따라 엄격히 필수는 아니지만 실제 구현에서는 거의 항상 존재합니다.

m=(media) 필드는 가장 중요한 필드 중 하나입니다. 특정 미디어 스트림을 설명하며 미디어 유형(audio, video, text, application), 포트, 전송 프로토콜 및 지원되는 코덱 목록을 포함합니다. WebRTC에서 가장 일반적으로 사용되는 유형은 audio와 video이며, 전송 프로토콜은 RTP/SAVPF(Secure Audio/Video Profile with Feedback) 또는 UDP/TLS/RTP/SAVPF입니다.

a=(attribute) 필드는 가장 유연하고 확장 가능합니다. rtpmap(코덱 번호와 이름 매핑), fmtp(코덱 매개변수), fingerprint(DTLS 키 지문), ice-ufrag 및 ice-pwd(ICE 자격 증명) 등 많은 속성을 포함할 수 있습니다. 속성을 통해 SDP는 최신 보안 메커니즘과 NAT 트래버설을 지원합니다.

WebRTC에서 SDP 작동 방식

WebRTC 아키텍처에서 SDP는 두 참가자 간의 미디어 세션 매개변수를 설명하고 협상하기 위한 시그널링 프로토콜 역할을 합니다. SDP 자체는 이러한 설명을 전송하는 메커니즘을 정의하지 않으며, 이 작업은 개발자가 WebSocket, HTTP 또는 다른 프로토콜을 통해 독립적으로 구현하는 시그널링 채널이 처리합니다.

프로세스는 발신자(caller)가 SDP Offer를 만들면서 시작됩니다. 이를 위해 브라우저는 RTCPeerConnection 객체에서 createOffer() 메서드를 호출합니다. 생성된 SDP 설명에는 발신자 측의 모든 세션 매개변수(지원되는 코덱, 네트워크 주소, ICE 후보, 보안 요구사항)가 포함됩니다.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// createOffer 전에 미디어 트랙 추가
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// SDP Offer 생성
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// 시그널링 채널을 통해 원격 피어로 SDP 전송
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Offer를 만들고 setLocalDescription()을 통해 로컬 설명을 설정한 후, 발신자는 시그널링 채널을 통해 SDP 문자열을 원격 참가자에게 보냅니다. 원격 참가자는 SDP Offer를 받으면 SDP Answer를 만들어 다시 보냅니다. 이 교환을 시그널링 교환이라고 하며 피어투피어 연결을 설정하기 전의 필수 단계입니다.

W3C WebRTC 명세에 따르면, SDP 교환은 ICE 후보가 시작되기 전에 이루어져야 합니다. 실제로 많은 구현이 ICE trickle 메커니즘을 사용하여 SDP와 병렬로 ICE 후보를 보냅니다. 이는 특히 지연 시간이 긴 모바일 네트워크에서 연결 설정 시간을 단축합니다.

SDP에서 ICE의 역할

ICE(Interactive Connectivity Establishment)는 SDP 속성을 사용하여 네트워크 후보에 대한 정보를 전송하는 메커니즘입니다. ICE 후보는 host(로컬 주소), srflx(NAT 이후 주소, STUN을 통해 획득), relay(TURN 서버 주소) 등 가능한 연결 경로를 설명합니다.

SDP에서 ICE 후보는 a=candidate: 속성을 통해, 그리고 ICE 트래픽 인증을 위한 ice-ufrag 및 ice-pwd 필드를 통해 전송됩니다. 각 후보에는 전송 프로토콜(UDP, TCP), IP 주소, 포트 및 우선순위가 포함됩니다. 성공적인 연결은 연결성 검사를 통과한 첫 번째 후보를 통해 설정됩니다. ICE restart 메커니즘은 네트워크 변경 시 연결을 업데이트할 수 있게 합니다.

모바일 애플리케이션의 경우 장치가 NAT나 기업 방화벽 뒤에 있는 경우가 많기 때문에 ICE 후보가 특히 중요합니다. ICE 메커니즘은 복잡한 네트워크 조건에서도 작동 경로를 찾을 수 있게 하며, SDP는 이 정보의 전송 컨테이너 역할을 합니다.

WebRTC에서 SDP 보안

WebRTC의 SDP에는 필수적으로 보안 속성, 특히 DTLS 지문과 SRTP 매개변수가 포함됩니다. a=fingerprint:sha-256 필드에는 미디어 스트림의 인증 및 암호화에 사용되는 DTLS 인증서의 지문이 포함됩니다. 이 속성이 없으면 WebRTC 연결이 설정되지 않습니다.

추가 보안 메커니즘에는 DTLS 핸드셰이크 역할(active, passive, actpass)을 정의하는 a=setup: 속성과 서버 측의 단순화된 ICE 구현을 위한 a=ice-lite:가 포함됩니다. 이러한 모든 매개변수는 SDP 내에서 전송되며 미디어 데이터 전송이 시작되기 전에 양쪽에서 확인됩니다.

SDP 유형: Offer와 Answer

WebRTC 모델에는 Offer(제안)와 Answer(응답)의 두 가지 SDP 메시지 유형이 있습니다. Offer는 연결 발신자가 만들며 원하는 미디어 세션의 전체 설명을 포함합니다. Answer는 원격 참가자가 Offer에 응답하여 만들며 제안이 부과한 제약 조건을 고려한 자신의 기능을 포함합니다.

Offer와 Answer의 주요 차이점은 속성의 의미에 있습니다. Offer는 발신자가 제안할 수 있는 모든 지원 코덱, 전송 프로토콜 및 네트워크 주소를 나열합니다. Answer는 원격 측이 지원하는 이러한 기능의 하위 집합을 선택합니다. 예를 들어, Offer가 opus, ISAC 및 PCMU를 제안하는 경우, Answer는 가장 선호되는 코덱으로 opus만 선택할 수 있습니다.

교환 프로세스는 W3C WebRTC 명세에 의해 관리되며 RTCPeerConnection의 여러 상태를 포함합니다. createOffer()를 통해 Offer를 만들고 로컬 설명으로 설정한 후, 연결은 have-local-offer 상태가 됩니다. Answer를 수신하고 setRemoteDescription()을 통해 원격 설명으로 설정한 후, 연결은 stable 상태가 되어 미디어 전송 준비가 완료됩니다.

모바일 SDK에서 SDP 사용

WebRTC용 모바일 SDK(Android용 Google WebRTC 및 iOS용 WebRTC.framework)는 Offer와 Answer를 통한 SDP 교환을 완전히 지원합니다. Android에서는 브라우저 API와 유사하게 PeerConnection 클래스와 createOffer() 메서드를 사용하여 Offer를 만듭니다. 결과 SDP 설명은 시그널링 채널을 통해 문자열로 전송됩니다.

iOS에서는 WebRTC 프레임워크의 RTCSessionDescription 클래스를 통해 SDP 작업이 수행됩니다. 초기화 시 유형(RTCSdpTypeOffer 또는 RTCSdpTypeAnswer)과 SDP 문자열이 지정됩니다. 플랫폼은 자동으로 SDP를 구문 분석하고 전달된 매개변수에 따라 연결을 구성합니다.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Android에서 SDP Offer 생성
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // 원격 피어로 SDP 문자열 전송
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

SDP 문자열을 직접 작업할 수 있는 능력은 개발자에게 유연성을 제공합니다. 전송 전에 SDP를 수정하여 특정 코덱을 추가하거나 제거하고, ICE 매개변수를 구성하거나, 사용자 정의 속성을 추가할 수 있습니다. Android 애플리케이션의 경우 네트워크 대역폭이 낮을 때 SDP에서 비디오를 비활성화해야 하는 경우가 많으며, 이는 SDP 설명에서 해당 m= 행을 제거하여 수행됩니다.

모바일 개발에서의 SDP

모바일 개발에서 SDP는 주로 WebRTC 컨텍스트에서 사용되며, 화상 통화, 음성 채팅 및 스트리밍 애플리케이션을 만드는 데 사용됩니다. Android 및 iOS의 모바일 애플리케이션은 SDP 메시지의 발신자와 수신자 모두로 작동할 수 있어 대칭적 피어투피어 연결을 가능하게 합니다.

모바일 애플리케이션의 특징은 가변적인 네트워크 품질 조건에서 SDP로 작업해야 하는 필요성입니다. Wi-Fi와 모바일 인터넷 간 전환 시, 그리고 대역폭이 변경될 때 새로운 SDP 설명 생성이 필요할 수 있습니다. 이는 재협상 메커니즘(createOffer()와 setLocalDescription()을 통한 반복적 SDP 교환)을 사용하여 수행됩니다.

Google WebRTC 팀(2023)에 따르면, 모바일 장치를 위한 SDP 교환 최적화에는 네트워크 변경 시 ICE restart 사용, 낮은 비트레이트 코덱(오디오용 opus, 비디오용 VP8) 우선순위 지정, 불필요한 미디어 스트림 제외를 통한 SDP 문자열 크기 최소화가 포함됩니다. 주요 이점은 모바일 네트워크 조건에서 연결 설정 시 지연 시간 감소입니다.

모바일 네트워크를 위한 SDP 최적화

모바일 장치에서 SDP로 작업할 때 주요 작업 중 하나는 SDP 설명 크기를 최소화하는 것입니다. 오디오와 비디오가 포함된 일반적인 WebRTC 세션의 전체 SDP는 2~5KB를 차지할 수 있으며, 이는 느린 네트워크에서 중요합니다. 최적화에는 BUNDLE(스트림 다중화) 사용, 지원되지 않는 코덱 제거, ICE 후보 압축이 포함됩니다.

모바일 장치의 추가 문제는 SDP 수명이 제한적이라는 점입니다. 불안정한 연결 조건에서 SDP는 원격 참가자가 처리하기 전에 만료될 수 있습니다. 해결책은 Answer 수신을 위한 짧은 시간 제한을 사용하고 필요 시 SDP를 재전송하는 것입니다. ICE restart 메커니즘은 RTCPeerConnection을 완전히 다시 만들지 않고도 연결을 업데이트할 수 있게 합니다. a=ice-lite 속성은 서버 측의 ICE 구현을 단순화합니다.

SDP 작업을 위한 인기 라이브러리

모바일 애플리케이션 개발자는 SDP 작업을 단순화하는 기성 라이브러리에 액세스할 수 있습니다. libjingle_peerconnection(Google WebRTC)은 Android용 주요 라이브러리로, SDP 관리를 위한 완전한 API를 제공합니다. iOS의 경우 유사한 기능을 가진 WebRTC.framework가 사용됩니다. 두 라이브러리 모두 자동으로 SDP를 생성하고 구문 분석하지만 필요 시 원시 SDP 문자열에 대한 액세스를 제공합니다.

SDP를 더 세밀하게 제어하기 위한 타사 솔루션도 있습니다. SDP 구문 분석 및 수정을 위한 sdp-transform(JavaScript 또는 Node.js), ICE 후보 작업을 위한 NICENICE(Java), SDP를 포함한 모든 시그널링 교환을 처리하는 WebRTC 인프라 제공업체의 기성 SDK 등이 있습니다.