Telephony2026-04-2612분 읽기

시그널링과 미디어의 분리 — RTSP / SIP vs RTP의 통제 평면

SIP·RTSP의 signaling/control message와 RTP·RTCP media 흐름을 분리해 설명합니다. 협상이 성공해도 NAT, firewall, address advertisement, codec 조건 때문에 한쪽 media만 실패할 수 있습니다. packet capture와 SDP를 대조해 control plane과 media plane을 따로 진단하는 순서를 정리했습니다.

RTSPSIPRTPRTCPSDPWebRTCNATAgora SIP Gateway시그널링

"왜 SIP 통화는 연결됐는데 한쪽 음성이 안 들리지?", "왜 RTSP는 TCP인데 RTP는 UDP지?". 둘 다 시그널링과 미디어 평면이 분리되어 있다는 사실 하나만 잡으면 풀립니다. 이 글은 그 분리의 이유와, 분리가 어떻게 트러블슈팅 패턴을 만드는지를 정리합니다.

핵심 관점 — 두 개의 평면

평면	역할	프로토콜 예시
시그널링 (Control Plane)	"통화 시작/멈춤", "코덱 협상", "끊기" — 제어 메시지	RTSP, SIP
연결·세션 기술	후보 경로 탐색과 세션 기술	ICE, SDP
미디어·피드백 평면	영상·음성 운반과 품질 피드백	RTP, SRTP, RTCP

같은 세션에 속해있어도 다른 채널, 다른 포트, 종종 다른 경로로 흐릅니다. 한쪽만 죽어도 다른 쪽은 살아있을 수 있습니다.

┌────────────────────────────────────────────┐
│        하나의 통화 / 스트리밍 세션          │
│                                            │
│   ┌──────────────┐    ┌──────────────┐     │
│   │  시그널링     │    │   미디어      │     │
│   │  RTSP/SIP    │    │   RTP/SRTP   │     │
│   │              │    │              │     │
│   │ TCP/TLS/UDP  │    │ UDP 또는 TCP │     │
│   │ 프록시 경유 가능│   │ P2P/중계 가능│     │
│   └──────────────┘    └──────────────┘     │
└────────────────────────────────────────────┘

RTSP — 카메라용 리모컨

RTSP(Real-Time Streaming Protocol)는 카메라/VOD 서버에 명령을 보내는 프로토콜입니다. RTP는 그 명령에 따라 흘러나오는 영상 패킷을 운반합니다.

RTSP 명령어

DESCRIBE  → "프레젠테이션 설명(SDP 등)을 줘"
ANNOUNCE  → "내가 스트림 보내겠다"
SETUP     → "이 포트로 RTP 받을게"
PLAY      → "재생 시작"
PAUSE     → "잠깐 멈춰"
TEARDOWN  → "끊을게"

표준 흐름

Client                                    Camera
   │                                          │
   │── DESCRIBE rtsp://camera ──────────────►│
   │                                          │
   │◄── 200 OK + SDP ─────────────────────────│   ← 미디어 형식과 제어 URI 등
   │                                          │
   │── SETUP (Transport 제안) ──────────────►│   ← UDP 포트 또는 TCP interleaving 협상
   │                                          │
   │◄── 200 OK ───────────────────────────────│
   │                                          │
   │── PLAY ─────────────────────────────────►│
   │                                          │
   │◄══ RTP 패킷 (port 5000) ═════════════════│   ← 영상 데이터 시작
   │◄══ RTCP 패킷 (port 5001) ════════════════│   ← 품질 정보
   │                                          │
   │── TEARDOWN ─────────────────────────────►│

핵심 분리: RTSP 제어는 신뢰성 있는 연결 위에서 오가며, 미디어 전송 방식은 SETUP의 Transport 헤더로 협상합니다. RTP/UDP를 쓸 수도 있고, RTP/RTCP를 RTSP TCP 연결에 interleaving할 수도 있습니다. 554는 RTSP의 기본 포트이지 모든 배포의 고정값은 아닙니다.

SIP — IP 전화의 신호 체계

SIP(Session Initiation Protocol)는 VoIP 통화 협상용입니다. RTSP가 "리모컨"이라면 SIP은 "IP 전화기의 다이얼링 시스템"입니다.

SIP 메시지

INVITE     → 통화 걸기 (with SDP: "내 코덱은 G.711, 내 RTP 포트는 6000")
100 Trying → 처리중
180 Ringing → 벨 울리는중
200 OK     → 받았어 (with SDP: "내 RTP 포트는 7000")
ACK        → 그래 시작하자
BYE        → 끊을게

통화 흐름

Alice                                    Bob
   │                                      │
   │─── INVITE + SDP ───────────────────►│
   │                                      │
   │◄── 100 Trying ───────────────────────│
   │◄── 180 Ringing ──────────────────────│
   │◄── 200 OK + SDP ─────────────────────│
   │                                      │
   │─── ACK ─────────────────────────────►│
   │                                      │
   │═══ RTP audio ════════════════════════►│   ← 시그널링 끝, 미디어 시작
   │◄══ RTP audio ════════════════════════│
   │                                      │
   │─── BYE ─────────────────────────────►│
   │◄── 200 OK ───────────────────────────│

최종 응답과 ACK 뒤에는 협상된 미디어 경로가 주로 동작합니다. 다만 세션 중에도 re-INVITE 같은 in-dialog 요청으로 코덱·주소·세션 조건을 바꿀 수 있고, 구성에 따라 최종 ACK 전 early media가 흐를 수도 있습니다.

RTP — 실제 미디어 운반

RTP(Real-time Transport Protocol)는 시그널링이 협상한 주소·포트·코덱 조건에 따라 미디어를 운반합니다.

RTP 패킷 헤더에서 중요한 필드

필드	역할
Sequence Number	패킷 순서 (재정렬·손실 검출)
Timestamp	미디어 시각 (#27 참고)
Payload Type	코덱 식별 (G.711, Opus, H.264 등)
SSRC	스트림 식별자

왜 UDP를 흔히 쓰나

UDP는 전송 계층 재전송 대기 없이 애플리케이션이 손실·지연 정책을 선택하기 쉽습니다.
다만 RTP는 UDP 전용이 아닙니다. RFC 4571처럼 TCP 등 연결 지향 전송 위에 RTP/RTCP를 프레이밍하는 표준도 있습니다.

RTCP — RTP의 짝꿍

RTP만으로는 품질을 알 수 없어서 함께 다니는 것이 RTCP(RTP Control Protocol)입니다.

Sender Report: 보낸 패킷 통계
Receiver Report: 수신 손실률, jitter
WebRTC의 PLI/FIR 같은 피드백 메시지도 RTCP 위에서 전달됨 (#27 참고)

왜 굳이 분리했나 — 3가지 이유

1. 책임 분리

시그널링 프로토콜은 통화 제어만, 미디어 프로토콜은 빠른 데이터 전송만. 각자 다른 요구사항을 갖고 진화할 수 있습니다.

2. 다른 경로 가능

시그널링 경로:  Alice ─► SIP Proxy ─► Bob's SIP Server ─► Bob
미디어 경로:    Alice ─────────────────────────────────► Bob   (가능하면 P2P)

미디어가 매번 서버를 거치면 지연 증가 + 서버 비용 증가. 분리되어 있어야 P2P 또는 SFU 라우팅이 자유로움.

3. 다른 전송 프로토콜

시그널링은 신뢰성 우선 → TCP 또는 UDP+재전송
미디어는 저지연 우선 → UDP를 흔히 사용하되, 네트워크 조건에 따라 TCP/TURN 중계도 가능

같은 프로토콜에 묶여 있으면 한쪽 요구를 다른 쪽이 못 만족합니다.

트러블슈팅 패턴 — 두 평면 따로 보기

이 분리 구조 때문에 SIP/RTSP 시스템에서 고전적인 두 가지 실패 모드가 생깁니다.

패턴 A: 시그널링 실패

증상: 전화 걸어도 벨이 안 울림, 또는 RTSP 연결 자체가 안 됨
원인: SIP/RTSP 포트(5060/554)가 막힘, 인증 실패, 코덱 협상 실패
진단: SIP 로그의 응답 코드 (401 Unauthorized, 488 Not Acceptable Here), RTSP의 DESCRIBE 응답

패턴 B: 미디어 실패 (one-way audio가 대표)

증상: 통화 연결은 됐는데 한쪽 음성이 안 들림 (또는 양쪽 다 안 들림)
원인 후보: NAT/방화벽, SDP의 주소·포트, 코덱 불일치, 음소거·디바이스 라우팅
진단: RTCP report에 수신 패킷 0, Wireshark로 RTP 패킷이 도착 안 함을 확인

진단 흐름

       [통화 이슈 보고]
              │
              ▼
    [통화가 연결되긴 했나?]
        │           │
       YES          NO
        │           │
        │       ┌───┴───────┐
        │       │ 시그널링    │
        │       │ 평면 점검   │
        │       │ - SIP 응답  │
        │       │ - 인증/코덱 │
        │       └────────────┘
        ▼
[음성/영상이 흐르는가?]
        │
       NO
        │
   ┌────┴──────────┐
   │ 미디어 평면 점검 │
   │ - NAT 통과 여부 │
   │ - RTP 포트 개방 │
   │ - SDP 협상 IP/Port│
   │ - RTCP 패킷 통계 │
   └────────────────┘

규칙: 통화가 연결됐는데 미디어가 없다면, 시그널링 성공 여부를 확인한 뒤 미디어 경로와 SDP 협상 결과를 먼저 본다.

SIP Gateway 시나리오에서

SIP 단말과 RTC 서비스를 연결하는 게이트웨이 배포도 같은 두 평면으로 나눠 볼 수 있습니다. 실제 토폴로지·지원 코덱·포트 범위는 사용하는 서비스의 현재 계약 문서를 기준으로 확인해야 합니다.

[일반 SIP 전화기]
    │
    │── SIP ───►── [SBC / SIP Gateway] ──── SIP ──── [RTC Gateway]
    │                       │                                │
    │                       │                                │ 변환
    │                       │                                ▼
    │                       └── RTP/SRTP ──────────► [RTC 측 미디어 경로]
    │                                                        │
    │                                                        ▼
                                                      RTC 서비스
                                                             │
                                                             ▼
                                                    [RTC SDK 사용자]

진단 시 두 가지를 분리해서 봅니다.

의심	점검 포인트
시그널링	SIP INVITE 응답, SBC 라우팅, 코덱 협상 (G.711 vs Opus)
미디어	NAT 뒤 RTP 도달성, SBC ↔ RTC 측 미디어 포트, one-way audio 여부

실무 팁: SIP 트러블슈팅에서 가장 시간을 잡아먹는 것이 "시그널링 OK / 미디어만 실패"인 케이스입니다. SIP 로그만 보고 있으면 답이 안 나오고, RTP 흐름(Wireshark·RTCP report)을 잡아야 합니다.

한 줄 비교

항목	RTSP	SIP	RTP
평면	시그널링	시그널링	미디어
무엇을 함?	스트림 제어 (PLAY/PAUSE)	통화 시작/종료 협상	영상·음성 운반
대표 명령/메시지	DESCRIBE, SETUP, PLAY	INVITE, 200 OK, BYE	(헤더에 seq/ts/payload)
전송	TCP/TLS, RTP interleaving 가능	UDP/TCP/SCTP 5060, TLS 5061이 기본	UDP가 흔하지만 연결 지향 전송도 가능
짝꿍	RTP/RTCP	RTP/RTCP	RTCP

#0 WebRTC란? ICE/STUN/NAT/TURN 기초 — WebRTC도 ICE/SDP(시그널링)와 RTP(미디어)가 분리된 같은 구조
#8 왜 P2P가 막히는가 — NAT/STUN/TURN — 미디어 평면(RTP UDP)이 NAT에 막히는 메커니즘
#9 Agora 기업 방화벽 우회 — Cloud Proxy — 미디어 UDP가 막힐 때의 TCP fallback 정책
#23 오디오 파이프라인 해부 — Opus/RTP/Jitter Buffer — RTP 위에서 Opus가 흐르는 미디어 평면 내부
#41 AI 콜봇 멀티콜 — SIP B2BUA vs Bridge — SIP 시그널링을 한 단계 더 들어간 통화 토폴로지

참고 자료

RFC 3261 — SIP: Session Initiation Protocol — SIP 메시지(INVITE/ACK/BYE)와 SDP offer/answer의 표준 정의
RFC 7826 — Real-Time Streaming Protocol Version 2.0 (RTSP 2.0) — RTSP의 DESCRIBE/SETUP/PLAY/TEARDOWN 메서드 표준 (RTSP 1.0은 RFC 2326)
RFC 3550 — RTP: A Transport Protocol for Real-Time Applications — RTP/RTCP 헤더와 Sender/Receiver Report 정의
RFC 4566 — SDP: Session Description Protocol — 코덱·미디어 포트를 협상하는 SDP 본문 포맷
RFC 3711 — The Secure Real-time Transport Protocol (SRTP) — RTP 미디어 암호화(SRTP)와 SRTCP 정의
RFC 4571 — Framing RTP and RTCP Packets over Connection-Oriented Transport — RTP/RTCP가 TCP 같은 연결 지향 전송에서도 동작하는 표준