Telephony2026-04-2612분 읽기

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

"통화는 멀쩡히 연결됐는데 왜 한쪽 음성만 안 들릴까?" SIP와 RTSP 같은 시그널링은 통화를 걸고 코덱을 협상할 뿐, 실제 음성과 영상은 RTP가 따로 운반합니다. 이 글은 둘이 왜 다른 포트와 경로로 분리됐는지 설명하고, 그 구조 덕에 "신호는 OK, 미디어만 실패" 같은 증상을 어떻게 갈라서 진단하는지까지 짚습니다.

RTSPSIPRTPRTCPSDPWebRTCNATAgora SIP Gateway시그널링

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

핵심 관점 — 두 개의 평면

평면	역할	프로토콜 예시
시그널링 (Control Plane)	"통화 시작/멈춤", "코덱 협상", "끊기" — 제어 메시지	RTSP, SIP, ICE, SDP
미디어 (Media / Data Plane)	실제 영상·음성 패킷 운반	RTP, SRTP, RTCP

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

┌────────────────────────────────────────────┐
│        하나의 통화 / 스트리밍 세션          │
│                                            │
│   ┌──────────────┐    ┌──────────────┐     │
│   │  시그널링     │    │   미디어      │     │
│   │  RTSP/SIP    │    │   RTP/SRTP   │     │
│   │              │    │              │     │
│   │  TCP, 5060   │    │  UDP, 동적   │     │
│   │  서버 경유    │    │  P2P 가능    │     │
│   └──────────────┘    └──────────────┘     │
└────────────────────────────────────────────┘

RTSP — 카메라용 리모컨

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

RTSP 명령어

DESCRIBE  → "스트림 정보 줘 (코덱, 해상도)"
ANNOUNCE  → "내가 스트림 보내겠다"
SETUP     → "이 포트로 RTP 받을게"
PLAY      → "재생 시작"
PAUSE     → "잠깐 멈춰"
TEARDOWN  → "끊을게"

표준 흐름

Client                                    Camera
   │                                          │
   │── DESCRIBE rtsp://camera ──────────────►│
   │                                          │
   │◄── 200 OK + SDP ─────────────────────────│   ← 코덱, 해상도, RTP 포트 등
   │                                          │
   │── SETUP (port 5000-5001) ──────────────►│   ← 클라이언트가 받을 RTP 포트 지정
   │                                          │
   │◄── 200 OK ───────────────────────────────│
   │                                          │
   │── PLAY ─────────────────────────────────►│
   │                                          │
   │◄══ RTP 패킷 (port 5000) ═════════════════│   ← 영상 데이터 시작
   │◄══ RTCP 패킷 (port 5001) ════════════════│   ← 품질 정보
   │                                          │
   │── TEARDOWN ─────────────────────────────►│

핵심 분리: RTSP는 TCP 554에서 명령만 주고받고, 실제 영상 데이터는 SETUP에서 협상한 UDP 포트로 RTP가 흐릅니다.

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 직후부터 SIP는 "옆으로 빠지고", RTP가 실제 음성을 운반합니다. SIP가 다시 등장하는 건 BYE(끊기) 시점입니다.

RTP — 실제 미디어 운반

RTP(Real-time Transport Protocol)는 시그널링과 무관하게 자기 일을 합니다.

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

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

왜 UDP인가

TCP는 손실 시 재전송 → 지연 누적 → 실시간 통신엔 부적합
"패킷 1개 잃어도 잡음 한 번이 전체 끊김보다 낫다"

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

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

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

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

패턴 A: 시그널링 실패

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

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

증상: 통화 연결은 됐는데 한쪽 음성이 안 들림 (또는 양쪽 다 안 들림)
원인: SIP은 통과했지만 RTP UDP 패킷이 NAT/방화벽에 막힘
진단: RTCP report에 수신 패킷 0, Wireshark로 RTP 패킷이 도착 안 함을 확인

진단 흐름

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

규칙: 통화가 연결됐는데 미디어가 없다면, 시그널링이 아니라 미디어를 의심한다.

Agora SIP Gateway 시나리오에서

Agora의 SIP Gateway는 일반 SIP 단말과 Agora SDK 사용자를 연결합니다. 두 평면을 따라가면 이렇게 흘러갑니다.

[일반 SIP 전화기]
    │
    │── SIP ───►── [SBC / SIP Gateway] ──── SIP ──── [Agora SIP Gateway]
    │                       │                                │
    │                       │                                │ 변환
    │                       │                                ▼
    │                       └── RTP ────────────────► [Agora 측 미디어 경로]
    │                                                        │
    │                                                        ▼
                                                      Agora SD-RTN
                                                             │
                                                             ▼
                                                    [Agora SDK 사용자]

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

의심	점검 포인트
시그널링	SIP INVITE 응답, SBC 라우팅, 코덱 협상 (G.711 vs Opus)
미디어	NAT 뒤 RTP 도달성, SBC ↔ Agora 측 RTP 포트 개방, 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 554	TCP/UDP 5060	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 정의
MDN — WebRTC connectivity (ICE/STUN/TURN) — 시그널링과 미디어 평면 분리를 WebRTC 맥락에서 설명