8장. 기본 SIP Call Flow 분석하기
1. SIP 헤더 분석하기 - SIP Proxy가 없는 경우
주요 SIP 헤더를 기준으로 SIP 호 절차를 분석해 보겠습니다. 실제 현장에서 구현하는 사례는 아니지만, SIP 메시지를 이해하기 쉽도록 단순화했습니다. IP PBX 나 SIP Proxy에 등록되지 않은 SIP 전화기 두 대가 SIP 세션 설립하는 과정을 분석해 봅니다. 앨리스의 전화기는 밥의 전화기의 IP주소를 사전에 알고 있다고 가정합니다.
<그림 8-1> SIP Call Flow without SIP Proxy1) INVITE
앨리스가 수화기를 들고 밥의 전화번호를 누르는 순간 INVITE 메시지가 전송됩니다.
INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
From 헤더와 To 헤더에서 알 수 있듯이 앨리스가 밥에게 보내는 다이얼로그입니다. Via 헤더는 INVITE 요청에 대한 응답은 pc33.atlanta.com로 전송하라고 되어 있습니다. 아마도 밥은 자신의 pc33에서 SIP 통화를 시도한 것으로 보입니다. CSeq 헤더의 값이 314159번이므로 응답도 같은 Cseq 번호를 사용할 것입니다. Content-Type 헤더는 SIP 메시지 바디에 SDP 메시지를 포함하고 있다고 알려 줍니다.
2) 200 OK
밥의 전화기는 INVITE를 수신 후에 벨 소리를 재생하고, 밥이 수화기를 드는 순간 200 OK 응답이 앨리스에게 전달됩니다.
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131
From 헤더와 To 헤더의 값이 바뀌지 않고 SIP INVITE 메시지의 헤더의 값이 동일합니다. 즉, From 헤더와 To 헤더는 각 메시지의 출발지와 목적지를 표시하는 것이 아니라 호의 진행방향을 표시합니다. CSeq 헤더는 INVITE 헤더의 값과 동일한 314159 INVITE입니다. CSeq는 SIP 패킷 캡처 시에 여러 호가 동시에 진행되더라도 어떤 요청에 대한 200 OK 응답인지를 분석할 수 있습니다.
Via 헤더의 값은 기존 INVITE 메시지의 헤더 값을 그대로 복사하였으며, 'received=10.1.3.33'이라는 필드를 추가하여 INVITE 메시지는 10.1.3.33 앨리스로부터 직접 받았다는 것을 명기하였습니다.
3) ACK
앨리스의 전화기가 200 OK를 수신하였음을 확인하는 ACK를 전송합니다
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 ACK
Content-Length: 0
CSeq 헤더의 값이 31459이므로 앞의 200 OK에 대한 ACK 임을 확인합니다.
4) BYE
BYE 세션은 발신자와 수신자 누구나 생성할 수 있습니다. 전화기의 훅 스위치에 수화기를 올려놓는 쪽에서
BYE가 전송됩니다.
BYE sip:alice@10.1.3.33 SIP/2.0
Via: SIP/2.0/TCP 192.168.10.20;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Alice <sip:alice@atlanta.com>;tag=1928301774
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 231 BYE
Content-Length: 0
From 헤더와 To 헤더의 값에서 알 수 있듯이 세션 종료 절차의 진행 방향은 밥이 앨리스에게 요청하는 다이얼로그입니다. 즉, 수화기를 내려놓은 사람은 밥입니다. 세션 종료 절차는 새롭게 시작하는 다이얼로그이자 트랜잭션이므로 CSeq 헤더의 값이 다릅니다.
5) 200 OK
CSeq 헤더의 값에 의해 BYE에 대한 응답으로 확인합니다.
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.10.20
To: Alice <sip:alice@atlanta.com>;tag=1928301774
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 231 BYE
Content-Length: 0
2. SIP 헤더 분석하기 - SIP Proxy가 있는 경우
실제 네트워크에서 VoIP 나 IP Telephony를 구축할 때는 SIP Proxy 서버나 IP PBX가 존재합니다. IP PBX는 제품에 따라 SIP Proxy로 구현하거나 B2BUA로 구현됩니다. 우선, 두 대의 SIP 전화기들은 SIP REGISTER Method를 통해 사전에 IP PBX에 사전 등록되었다고 가정합니다. 앞에서 설명 부분을 제외하고 차이점을 위주로 설명합니다.
<그림 8-2> SIP Call Flow with SIP Proxy1) INVITE (앨리스가 SIP Proxy 서버로 보냄)
앨리스의 전화기는 밥의 전화기의 IP 주소를 알지 못하므로 INVITE 메시지를 SIP Proxy 서버로 전송합니다.
INVITE sip:bob@biloxi.com/TCP SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
엘리스가 밥에게 보내는 SIP INVITE 메시지는 SIP Proxy 서버가 없을 때와 마찬가지로 동일합니다.
2) INVITE (SIP Proxy 서버가 밥에게 보내는 것)
SIP 프락시 서비는 앨리스로 받은 INVITE 메시지를 Request-URI에 적힌 밥의 주소로 전달합니다. 여기서 SIP 프락시 서버는 Via 헤더를 추가하고 Max-Forwards 헤더를 수정하였습니다.
INVITE sip:bob@192.168.10.20/TCP SIP/2.0
Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds;received=10.1.3.33
Max-Forwards: 69
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
추가된 Via 헤더의 값은 SIP Proxy 서버의 주소를 나타내며, INVITE 요청의 응답인 200 OK가 SIP 프락시 서버를 경유할 것을 요청합니다. 만일 밥의 200 OK 응답이 SIP 프락시 서버를 경유하지 않고 바로 앨리스에게 전달된다면, SIP 프락시 서버는 호의 진행 상태를 알 수 없습니다. 또한, 앨리스가 보낸 Via 헤더에는 'received=10.1.3.33'이라는 값을 추가하여 어디서 받았는 지를 명기하였습니다.
Max-Forwards 헤더의 값이 70에서 에서 69로 줄었습니다. 한 개의 SIP 서버를 지날 때마다
1 씩 줄어듭니다.
CSeq와 Call-ID는 변경되지 않았으므로 SIP 호 설립 절차가 하나의 다이얼로그로 진행됩니다. SIP Proxy 서버는 제한적으로 메시지를 추가 또는 삭제할 수는 있어도 새로운 세션을 생성하지 않습니다. B2BUA로 구현된 PBX라면 새로운 다이얼로그를 생성하기 위해 값을 변경하였을 것입니다.
3) 200 OK (밥이 SIP Proxy 서버로 보내는 것)
밥은 200 OK 응답을 INVITE 메시지의 Via 헤더가 가리키는 SIP Proxy 서버의 주소로 전송합니다.
SIP/2.0 200 OK
Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131
두 개의 Via 헤더는 INVITE 메시지에 있던 두 개의 Via 헤더를 그대로 복사하여 추가하였고, SIP Proxy 서버가 추가한 헤더에 SIP Proxy Server의 주소를 'received=192.168.10.1' 필드로 추가하였습니다.
4) 200 OK (SIP Proxy 서버가 앨리스로 보내는 것)
SIP Proxy 서버는 밥으로부터 받은 200 OK 메시지에서 자신이 추가했던 Via 헤더를 삭제한 후 앨리스에게 전송합니다.
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131
5) ACK (앨리가 밥에게 직접 보내는 것)
앨리스의 전화기는 밥의 200 OK를 정확히 수신했음을 확인하는 ACK를 밥의 전화기로 직접 보냅니다. ACK
는 새로운 요청이자 다이얼로그이므로 밥이 보낸 200 OK 메시지의 Contact 헤더의 주소로 전달됩니다. 세부 내용은 중복이므로 생략합니다.
3. 모든 SIP 메시지를 SIP Proxy서버를 경유하게 하기
정리하면 SIP Proxy 서버는 INVITE 요청에 대한 200 OK 응답이 자신을 경유하도록 Via 헤더를 추가하고, ACK를 포함한 신규 요청은 Contact 헤더를 참조합니다.
기업의 IP PBX 또는 SIP Proxy는 호의 상태를 관리하고 과금 데이터를 생성할 목적으로 모든 시그널링이 자신을 경유하도록 설계됩니다. 예를 들어, SIP Proxy 서버가 있는 호 설립 절차에서 ACK가 SIP Proxy 서버를 경유하지 않았으니 SIP Proxy 서버는 호가 정상적으로 완료되었는 지를 알 수 없습니다. 또한, 앨리스나 밥 중에 누군가가 BYE 메시지를 전송하더라도 SIP Proxy 서버는 호가 정상적으로 종료되었는 지를 알지 못합니다. 즉, 현재 상태에서 IP PBX는 과금도 호의 상태 관리도 할 수 없습니다.
B2BUA가 아닌 SIP Proxy 서버가 등록된 모든 단말의 모든 시그널링이 자신을 경유되도록 하기 위해서는 새로운 방법이 필요합니다. 다시 말해서, 모든 시그널링 메시지가 SIP Proxy 서버를 경유하도록 하기 위해 호의 설립 절차의 시작인 INVITE 메시지가 SIP Proxy 서버를 경유할 때 SIP Proxy 서버는 새로운 SIP 헤더를 추가해야 할까요? 아니면 기존 SIP 헤더를 변경만 해도 충분할까요?
'엔지니어를 위한 인터넷 전화와 SIP의 이해'를 책으로 만들다
https://brunch.co.kr/@linecard/188
