SIP 프로토콜이란? Session Initiation Protocol 해설

SIP(Session Initiation Protocol)는 인터넷에서 전화 통화를 성립시키는 방법입니다. 한 장치가 다른 장치에 전화를 걸고 싶을 때, SIP가 그 협상을 나릅니다. 누가 거는지, 상대방이 어디에서 닿는지, 양쪽이 어떤 오디오 코덱을 지원하는지, 누가 언제 끊는지를요. 음성 자체는 절대 SIP 위를 지나지 않습니다. 양쪽이 합의하면 오디오는 별도의 스트림으로, 거의 항상 RTP로 흐릅니다.

이 분리가 이 가이드에서 가져갈 단 하나의 요점입니다. SIP는 통화에 관한 대화이지, 통화 자체가 아닙니다. 메서드, 응답 코드, 포트 같은 나머지 모든 것은 여기서 따라 나옵니다. 이 가이드는 SIP 통화가 메시지별로 어떻게 동작하는지, 용어가 무슨 뜻인지, 그리고 전화를 받는 것이 AI 음성 에이전트일 때 SIP가 어디에서 모습을 드러내는지를 다룹니다.

SIP란 무엇이고, 무엇이 아닌가

SIP는 IETF가 정의한 애플리케이션 계층 시그널링 프로토콜입니다. 1999년에 RFC 2543으로 처음 등장했고 2002년에 RFC 3261로 개정되었으며, RFC 3261은 지금도 모든 SIP 전화기, PBX, 통신사가 구현하는 표준입니다. 설계자들이 HTTP의 요청-응답 모델과 텍스트 구문을 빌려 왔기 때문에, SIP 메시지는 별도 도구 없이도 패킷 캡처에서 읽을 수 있습니다.

SIP가 아닌 것 세 가지를 들면 다음과 같습니다.

• 오디오가 아니다. SIP는 세션을 협상한 뒤 물러납니다. 음성과 영상은 아래에서 설명하는 RTP 패킷으로 전달됩니다.
• 서비스가 아니다. “SIP” 자체를 팔아 주는 사람은 없습니다. 통신사가 파는 것은 SIP 트렁킹입니다. SIP 프로토콜을 써서 여러분의 전화 시스템을 공중 전화망에 연결하는 서비스입니다.
• 유일한 시그널링 방법이 아니다. H.323은 SIP보다 오래되었고, WebRTC는 브라우저 안의 통화를 처리하며, 독자 프로토콜은 닫힌 앱 안에서 돌아갑니다. SIP가 기업 전화 세계를 차지한 것은 오픈되어 있고, 텍스트 기반이며, 모든 벤더가 구현할 수 있을 만큼 단순했기 때문입니다.

SIP 통화의 동작 방식

SIP 통화는 텍스트 요청과 번호가 붙은 응답의 짧은 교환입니다. 울림부터 종료까지, 전형적인 수신 통화를 따라가 보겠습니다.

1. INVITE. 발신 측이 착신자의 주소로 INVITE를 보냅니다. 본문에는 SDP(Session Description Protocol) 블록이 실려 발신 측의 IP, 오디오를 받고 싶은 포트, 지원하는 코덱이 나열됩니다.
2. 100 Trying. 경로상의 프록시가 수신을 확인해 주므로 발신 측은 재전송을 멈춥니다.
3. 180 Ringing. 착신 장치가 사용자를 호출하고 있습니다. 발신자가 링백 톤을 듣는 시점입니다.
4. 200 OK. 착신자가 전화를 받습니다. 이 응답에는 착신 측 자신의 SDP 블록이 실려 코덱 협상이 완료됩니다.
5. ACK. 발신 측이 최종 응답을 확인합니다. 이제 세션이 성립했고, 양방향으로 RTP 오디오가 흐르기 시작합니다.
6. BYE. 끊는 쪽이 BYE를 보냅니다. 상대방이 200 OK로 답하고 세션은 끝납니다.

통화 중에는 어느 쪽이든 re-INVITE라고 부르는 새 INVITE를 보내 세션을 바꿀 수 있습니다. 보류로 전환하거나, 영상을 추가하거나, 코덱을 바꾸는 식입니다. REFER 요청은 상대방에게 다른 곳으로 전화를 걸어 달라고 요청하는 것으로, 전환은 이렇게 동작합니다.

실제 INVITE가 네트워크에서 어떤 모습인지, 약간 줄여서 보여 드립니다.

INVITE sip:+14155550132@sip.example.com SIP/2.0
Via: SIP/2.0/TLS client.example.com:5061;branch=z9hG4bK74bf9
Max-Forwards: 70
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
To: <sip:+14155550132@sip.example.com>
Call-ID: 3848276298220188511@client.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.example.com;transport=tls>
Content-Type: application/sdp
Content-Length: 213

v=0
o=alice 2890844526 2890844526 IN IP4 client.example.com
s=-
c=IN IP4 client.example.com
t=0 0
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

SDP 오퍼의 마지막 세 줄이 테이블에 올라온 코덱입니다. 페이로드 0은 G.711 mu-law, 페이로드 8은 G.711 A-law, 페이로드 101은 telephone-event로, 오디오 스트림 안에서 DTMF 키 입력을 아웃오브밴드로 보내는 방식입니다. 공중망 통화는 보통 두 G.711 변형 중 하나에 정착하는데, 전화 음성이 그렇게 들리는 이유가 바로 이것입니다.

알아둘 만한 SIP 메서드

SIP 요청에는 메서드라는 이름이 붙습니다. 캡처에서 만나게 될 것들은 다음과 같습니다.

모든 요청에는 세 자리 코드의 응답이 돌아옵니다. 첫 자리 숫자로 분류됩니다.

이 중 둘은 설정 단계에서 제 몫을 합니다. 401이나 407은 실패가 아니라 인증 챌린지로, 발신자는 다이제스트 자격 증명을 붙여 재시도해야 합니다. 488 Not Acceptable Here는 양쪽이 공유하는 코덱이 없다는 뜻으로, 오디오 인코딩 방식에 합의하지 못했다는 것을 통화가 정중하게 알려 주는 방식입니다.

주소, 등록, 그리고 사이에 있는 장비들

SIP 주소는 이메일 주소처럼 생겼습니다. sip:alice@example.com처럼 쓰고, sip:alice@example.com:5061;transport=tls처럼 포트나 전송 방식을 붙일 수 있습니다. 전화번호는 통신사 도메인을 붙이면 SIP URI가 되는데, 그래서 sip:+14155550132@sip.example.com은 완전히 발신 가능한 주소입니다.

장치는 움직이고 NAT 뒤에 있기 때문에, SIP 전화기는 자신이 어디 있는지 네트워크에 알립니다. 레지스트라에 REGISTER를 보내면, 레지스트라는 “alice@example.com은 현재 이 IP에 있다”고 기록합니다. Alice를 향한 INVITE가 도착하면 프록시 서버가 그 기록을 조회해 Alice가 실제로 있는 곳으로 요청을 전달합니다. 실제 배포 대부분의 앞에는 SBC(세션 보더 컨트롤러)가 있습니다. SIP 트래픽의 경비원으로, 시그널링을 종단하고, 내부 네트워크를 숨기고, 보안 정책을 집행하고, 벤더마다 다른 SIP 스택의 이상한 동작을 정규화합니다.

SIP, RTP, SDP 비교

세 개의 프로토콜이 모든 SIP 통화의 일을 나눕니다.

이것이 통화가 완벽하게 울리면서도 침묵만 전달될 수 있는 이유입니다. SIP 절반은 동작해서 양쪽 전화가 통화의 존재에 합의했지만, RTP 절반이 망가진 것입니다. 원인은 보통 시그널링은 통과시키면서 미디어는 버리는 방화벽이나 NAT입니다. 소리가 안 나는 통화를 디버깅할 때는 시그널링이 아니라 미디어 경로를 보세요. 같은 분리가 지터를 RTP의 문제로 만듭니다. RFC 3550이 정의한, 모든 RTP 패킷에 찍힌 시퀀스와 타임스탬프 필드가 바로 수신 측이 지터를 계산하기 위해 재는 것이기 때문입니다.

SIP, VoIP, SIP 트렁킹 비교

세 용어는 혼용되지만 같은 것이 아닙니다.

VoIP가 인터넷으로 전화를 건다는 아이디어라면, SIP는 양끝이 말하는 문법이고, SIP 트렁크는 여러분의 통화를 공중 전화망에 올려 주는 구독입니다. 사업자, 채널, 설정 같은 서비스 측면은 SIP 트렁킹 가이드에서 다룹니다.

전송 방식, 포트, 암호화

SIP 시그널링은 UDP나 TCP의 5060번 포트, 또는 TLS의 5061번 포트에서 돌아갑니다. UDP는 전통적인 기본값으로 헤드오브라인 블로킹을 피하지만, 큰 메시지는 단편화되므로 어느 정도 크기가 있는 것에는 TCP가 일반적입니다. TLS는 시그널링을 암호화하고 상대방을 인증하며, 운영 환경이라면 통신사가 기대하는 방식입니다.

날것의 SIP는 아무것도 암호화하지 않습니다. 경로상의 누구나 시그널링을 읽을 수 있고, 미디어는 암호화되지 않은 RTP로 갑니다. 표준적인 해결책은 시그널링에 TLS를, 미디어에 RFC 3711이 정의한 SRTP를 쓰는 것입니다. 양쪽이 합의해야 합니다. 한쪽만 암호화를 켜는 것은 연결은 되는데 오디오가 없는 통화를 확실하게 만드는 방법이기 때문입니다.

SIP의 모든 시대를 살아남은 경고가 하나 있습니다. 열린 SIP 엔드포인트를 노출하지 마세요. 5060번 포트가 나타나면 몇 분 안에 스캐너가 인터넷을 쓸면서 공짜 통화를 걸어 줄 트렁크를 찾습니다. 다이제스트 자격 증명으로 발신자를 인증하거나, 통신사의 시그널링 IP를 허용 목록에 넣거나, 둘 다 하세요.

SIP가 음성 에이전트를 만나는 곳

AI 음성 에이전트를 전화망에 올린다면, SIP는 통화의 양 가장자리에서 일하는 프로토콜입니다. 통신사는 수신 통화를 SIP INVITE로 에이전트 플랫폼에 전달하고, 플랫폼은 발신 통화와 전환을 같은 방식으로 돌려보냅니다. 그 스택을 직접 운영하는 순간, 몇몇 프로토콜 세부 사항은 더 이상 잡학이 아닙니다.

• 전환은 REFER입니다. 에이전트가 발신자를 사람에게 넘길 때, 플랫폼은 SIP REFER를 보내 통신사에게 새 목적지를 울려 달라고 요청합니다. 날것의 REFER는 콜드 전환입니다. 받는 사람이 먼저 맥락을 듣는 웜 전환으로 만들지는 REFER가 나가기 전 에이전트의 몫입니다.
• 키 입력에는 세 가지 전송 경로가 있습니다. DTMF 숫자는 인밴드로 오디오에 실리거나, 아웃오브밴드로 RFC 4733 telephone-event로(위 INVITE의 페이로드 101), 또는 SIP INFO 메시지 안으로 이동합니다. 전화가 보내는 방식과 에이전트가 듣는 방식이 어긋나는 것이 “1을 누르세요” 메뉴가 소리 없이 숫자를 삼키는 이유입니다.
• 미디어는 8 kHz입니다. 전화 통화는 G.711로 협상하므로, 에이전트의 음성 인식은 좋든 싫든 협대역 오디오를 보게 됩니다. 다른 무엇을 튜닝하기 전에 실제 전화 음성으로 테스트하세요. 코덱이 무엇을 잘라내는지는 G.711 가이드에서 다룹니다.
• 브라우저 통화는 다른 세계입니다. WebRTC에는 시그널링에 구애받지 않는 자체 모델, 의무적인 암호화, 적응형 지터 버퍼가 있습니다. 전화망이 아니라 브라우저에 사는 음성 에이전트를 위한 차이는 WebRTC vs WebSocket 가이드에서 정리해 두었습니다.

Cartesia에서 Managed Agents는 TCP 또는 TLS를 통해 여러분 자신의 SIP 트렁크에서 오는 통화를 받고, SRTP 미디어 암호화는 disabled, allowed, required로 설정하며, 수신 통화는 다이제스트 자격 증명이나 IP 허용 목록으로 인증합니다. 전환은 전화번호나 SIP URI로 나가는 SIP REFER입니다. 통신사를 Cartesia의 SIP 엔드포인트로 향하게 하는 방법은 SIP 트렁킹 연동 (영어)에서 안내하고, API 필드와 장애 표를 포함한 설정 전체는 SIP 트렁킹 가이드에서 다룹니다.

관련 가이드

• SIP 트렁킹이란? 작동 방식과 음성 AI에서 쓰는 법
• G.711 코덱이란? mu-law, A-law와 8kHz 전화 음성
• DTMF란? 톤 주파수와 음성 AI에서의 활용
• VoIP 지터란? 측정과 해결 방법
• WebRTC vs WebSocket: 실시간 음성에는 무엇을 써야 할까
• 웜 트랜스퍼란? 웜 트랜스퍼와 콜드 트랜스퍼의 차이