SIP 프로토콜 입문: INVITE부터 BYE까지 전화 한 통이 연결되는 과정

SIP(Session Initiation Protocol)는 인터넷전화에서 통화를 시작하고, 음성 조건을 협상하고, 끝내는 신호 프로토콜입니다. IETF 표준 RFC 3261로 정의되어 있으며, 발신 측이 INVITE를 보내고 수신 측이 200 OK로 응답한 뒤 발신 측이 ACK로 확인하면 통화가 성립하고, BYE로 종료됩니다. KAT Cloud는 표준 SIP/2.0으로 기존 PBX와 자체 음성 서버를 연결할 수 있게 합니다.

SIP가 하는 일: 신호와 음성의 분리

전화 한 통에는 두 종류의 데이터가 오갑니다. 하나는 "걸겠다", "받았다", "끊겠다" 같은 신호이고, 다른 하나는 실제 목소리입니다. SIP는 이 가운데 신호만 다룹니다. 목소리는 SIP가 협상해 둔 조건에 따라 RTP라는 별도 프로토콜로 흐릅니다.

SIP 메시지는 HTTP처럼 사람이 읽을 수 있는 텍스트입니다. 첫 줄에 요청 메서드나 응답 코드가 오고, 그 아래에 헤더가, 빈 줄 다음에 본문이 붙습니다. 본문에는 보통 음성 조건을 적은 SDP가 들어갑니다. 전송 계층으로는 UDP, TCP, TLS를 쓸 수 있고, 표준 기본 포트는 UDP·TCP 5060, TLS 5061입니다. 다만 실제 서비스는 사업자마다 포트와 전송 방식이 다를 수 있으므로 안내받은 값을 따라야 합니다.

SIP를 이루는 구성 요소

• UA(User Agent): 통화의 끝점입니다. 요청을 보내는 쪽을 UAC, 받는 쪽을 UAS라고 부르며 한 단말이 상황에 따라 두 역할을 모두 합니다.
• 프록시 서버: 요청을 받아 목적지 방향으로 전달하고, 라우팅과 인증을 맡습니다.
• 레지스트라: REGISTER 요청을 받아 "이 사용자는 지금 이 주소에 있다"는 위치 정보를 저장합니다.
• B2BUA: 양쪽 통화를 각각 따로 끝내고 중간에서 다시 잇는 장비입니다. PBX와 SBC(Session Border Controller)가 대표적이며, 사업자 간 경계에서 주소 변환과 보안을 맡습니다.

SIP에서 통화 상대는 sip:alice@example.com 같은 SIP URI로 표현합니다. 전화번호로 거는 경우에는 사용자 부분에 번호를 넣습니다.

주요 메서드와 응답 코드

SIP 요청은 메서드로 구분합니다. RFC 3261의 기본 메서드 6개와 자주 쓰는 확장 메서드는 다음과 같습니다.

응답은 HTTP처럼 세 자리 숫자로, 첫 자리가 분류를 나타냅니다.

INVITE부터 BYE까지: 전화 한 통의 흐름

1. 1발신 측이 INVITE를 보냅니다. 본문의 SDP에는 자신이 쓸 수 있는 코덱과 음성을 받을 주소·포트를 적습니다(제안, offer).
2. 2수신 측이나 중간 프록시는 요청을 받았다는 뜻으로 100 Trying을 보내고, 벨이 울리기 시작하면 180 Ringing을 보냅니다. 연결 전에 안내 음성을 들려줘야 하면 SDP를 담은 183 Session Progress로 early media를 엽니다.
3. 3상대가 받으면 200 OK를 보냅니다. 본문의 SDP에는 제안 가운데 고른 코덱과 자신의 음성 주소가 담깁니다(응답, answer).
4. 4발신 측이 ACK를 보내 200 OK를 받았음을 확인합니다. 이 세 단계가 끝나면 다이얼로그가 확정됩니다.
5. 5양쪽이 협상한 주소로 RTP 음성 패킷을 주고받습니다.
6. 6어느 한쪽이 BYE를 보내면 상대가 200 OK로 답하고 통화가 끝납니다.

벨이 울리는 도중 발신 측이 끊으면 BYE 대신 CANCEL을 보냅니다. 수신 측은 CANCEL에 200 OK로, 원래 INVITE에는 487 Request Terminated로 응답합니다.

아래는 RFC 예시 형식을 따른 INVITE 요청입니다. 도메인과 IP는 문서용 예시 값이며 KAT Cloud의 실제 접속 정보가 아닙니다.

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: "Alice" <sip:alice@example.org>;tag=1928301774
To: <sip:bob@example.com>
Call-ID: a84b4c76e66710@192.0.2.10
CSeq: 314159 INVITE
Contact: <sip:alice@192.0.2.10:5060>
Content-Type: application/sdp
Content-Length: 226

v=0
o=alice 2890844526 2890844526 IN IP4 192.0.2.10
s=-
c=IN IP4 192.0.2.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

From의 tag, 200 OK에서 To에 붙는 tag, Call-ID가 합쳐져 하나의 다이얼로그(통화)를 식별합니다. CSeq는 다이얼로그 안에서 요청 순서를, Via의 branch 값은 개별 트랜잭션을 구분합니다.

SDP 제안·응답으로 음성 조건 맞추기

SDP(Session Description Protocol)는 음성 세션의 조건을 적는 형식이고, RFC 3264의 제안·응답(offer/answer) 모델로 양쪽 조건을 맞춥니다. 위 예시의 m=audio 49170 RTP/AVP 0 8 101은 "49170번 포트로 음성을 받으며 페이로드 타입 0(PCMU), 8(PCMA), 101(telephone-event)을 쓸 수 있다"는 뜻입니다. 0과 8은 G.711 μ-law와 A-law에 미리 정해진 정적 번호이고, 96~127 범위는 a=rtpmap으로 의미를 정하는 동적 번호입니다. c= 줄은 음성을 받을 IP 주소, a=ptime:20은 패킷 하나에 20ms 분량의 음성을 담는다는 뜻입니다.

응답 측은 제안 목록에서 지원하는 것만 남겨 200 OK에 담습니다. 겹치는 코덱이 하나도 없으면 488 Not Acceptable Here로 거절합니다. INVITE에 SDP를 넣지 않는 방식(delayed offer)도 있는데, 이때는 200 OK에 제안이, ACK에 응답이 담깁니다.

통화 중 조건을 바꿀 때는 같은 다이얼로그 안에서 INVITE를 다시 보내는 re-INVITE를 씁니다. 보류는 SDP 방향 속성을 a=sendonly나 a=inactive로 바꿔 표현하는 것이 일반적입니다. 코덱과 RTP 패킷 구조는 RTP와 음성 코덱에서, telephone-event가 키패드 입력을 나르는 방식은 DTMF란?에서 자세히 다룹니다.

자주 만나는 문제와 KAT Cloud 연동

• 연결 후 약 32초 만에 끊김: 200 OK를 보낸 쪽이 64×T1(기본 32초) 동안 ACK를 받지 못해 통화를 끝내는 증상입니다. NAT나 방화벽 때문에 ACK가 돌아오지 못하는 경우가 대표적입니다.
• 한쪽만 들리는 단방향 음성: SDP의 c= 줄에 사설 IP가 적혀 상대가 그 주소로 음성을 보낼 수 없을 때 자주 생깁니다. SBC, 대칭 RTP, STUN 같은 NAT 대응이 필요합니다.
• 401·407 응답 반복: 서버가 인증을 요구한다는 뜻입니다. 인증 정보를 담아 다시 보내도 반복되면 계정 정보가 맞지 않는 경우입니다.
• 488 Not Acceptable Here: 코덱이나 암호화 조건이 서로 맞지 않는 경우입니다.

KAT Cloud는 표준 SIP/2.0·RTP·DTMF로 기존 PBX와 자체 음성 서버를 연결하며, SIP 직접 연결은 모든 플랜에서 무료입니다. 서버 주소, 포트, 전송 방식, 인증 방식 같은 SIP 접속 정보는 KAT Cloud 콘솔 또는 도입 문의로 안내받습니다. 발신 통화는 SIP로 연결한 내 음성 서버나 PBX가 KAT Cloud 회선으로 거는 구조입니다. 실제 연동 준비 항목은 SIP 연동 준비 체크리스트에 정리했습니다.

자주 묻는 질문

SIP와 RTP는 어떻게 다른가요?

SIP는 통화를 시작·응답·종료하고 음성 조건을 협상하는 신호 프로토콜이고, RTP는 협상된 조건에 따라 실제 음성 패킷을 실어 나르는 프로토콜입니다. 그래서 SIP 메시지가 프록시를 거쳐 가더라도 RTP 음성은 다른 경로로 흐를 수 있습니다.

SIP 통화가 연결되고 32초 뒤에 끊기는 이유는 무엇인가요?

SIP에서 200 OK를 보낸 쪽은 ACK를 받을 때까지 응답을 재전송하다가, 기본 타이머 기준 32초 안에 ACK를 받지 못하면 통화를 끝냅니다. NAT·방화벽 설정이나 잘못된 Contact 주소 때문에 ACK가 도달하지 못하는 경우가 많습니다.

KAT Cloud에 SIP로 연결하려면 어떤 정보가 필요한가요?

KAT Cloud에 SIP로 연결할 때 필요한 서버 주소, 포트, 전송 방식, 인증 방식 등 접속 정보는 KAT Cloud 콘솔 또는 도입 문의로 안내받습니다. 연결하는 PBX나 음성 서버 쪽에서는 방화벽, NAT, 코덱, DTMF 설정을 함께 확인해야 합니다.