7장. 주요 SIP 헤더 이해하기
1. SIP 헤더 분석을 해야 하는 이유
SIP 호 절차를 정확히 이해하기 위해서는 SIP 메시지에 포함된 SIP헤더의 의미를 파악해야 합니다. 어떤 엔지니어들은 설치 가이드를 따라 IP 전화기를 IP PBX에 등록한 후 통화가 정상적으로 이루어지면 SIP 공부를 중단합니다. 누군가가 SIP 전화나 인터넷 전화의 원리를 물어보면 "저는 그냥 설치 가이드대로 하니까 되더라고요"라는 대답을 합니다. 일반 사용자와 엔지니어의 차이는 원리와 표준을 알고 있는 지로 나뉩니다. 이 글은 바로 SIP의 동작 원리가 궁금한 엔지니어를 위한 것입니다.
특히, 이기종 장비 간 SIP Trunk 연동을 할 경우 SIP 패킷을 수집하여 분석하는 과정이 필요합니다. SIP 헤더를 이해하지 못하면 수집된 패킷은 난해한 암호문일 뿐입니다. 또한, 개발자와 엔지니어들이 SIP 헤더에 대해 논의를 하지 못한다면 좋은 해결책을 제시할 수 없습니다.
2. SIP 주소 체계
PTSN 전화망은 E.164 주소 체계를 사용하고, 인터넷망은 IP 주소 체계를 사용합니다. 사람들은 전화번호인 E.164 주소 체계에는 익숙하지만, 32비트의 IP주소 체계는 낯설어합니다. 그래서, 사람들은 인터넷 웹브라우저로 유튜브나 네이버에 접속하기 위해 IP주소보다는 www.youtube.com이나 www.naver.com과 같은 도메인 네임 주소 체계를 이용합니다. 이메일의 주소체계도 기억하기 쉬운 도메인 네임 체계를 씁니다.
SIP는 처음부터 다양한 환경에서 사용할 수 있도록 여러 가지 주소체계를 지원합니다.
FQDN (Fully-Qualified Domain Names)
웹브라우저에서 입력하는 도메인 주소 체계
도메인의 앞자리에 사용자명 또는 단말기의 호스트명을 붙여서 사용합니다.
예) sip:bob.cisco.com 또는 sip:alice.abc.com
URI (Unified Resource Identifier)
RFC2368 The mailto URL Scheme에 정의된 주소체계
이메일 주소 체계
웹브라우저에서 사용하는 URL (Unified Resource Locator) 주소체계도 포함
예) sip:bob@cisco.com 또는 sip:alice@abc.com
E.164 주소를 포함한 URI 주소 체계
사용자 이름 부분에 전화번호를 사용하는 URI 주소
예) sip:14085551234@cisco.com; user=phone 또는 sip:1001@abc.com; user=phone
IP 주소를 포함한 URI 주소체계
도메인 네임 부분에 IP 주소를 사용하는 URI 주소
예) sip:14085551234@10.1.1.1; user=phone 또는 sip: alice@10.1.1.1
2018년 현재는 SIP와 H.323 단말들 모두 다양한 형태의 URI 주소 체계를 지원합니다. 그러나 특별한 경우가 아니라면 사람들이 이해하기 쉬운 alice@abc.com이나 1000@abc.com과 같은 URI 주소체계를 가장 많이 사용합니다. DNS (Domain Name Server)가 SRV(Servie) 레코드를 지원하면서 전 세계 호제어 서버 간 연결이 가능해졌기 때문입니다. SRV 레코드는 DNS 요청에 특정 프로토콜이나 서비스가 대한 정보를 제공합니다. 예를 들어, 이메일 서버가 SMTP 프로토콜로 bob@abc.com으로 메일을 보내기 위해 abc.com 기업의 IP 주소를 요청하면 이메일 서버의 IP주소를 알려줍니다. SIP 프락시 서버가 SIP 프로토콜로 bob@abc.com으로 통화하기 위해 abc.com기업의 IP주소를 요청하면 SIP 프락시 서버의 IP 주소를 알려줍니다.
전화망은 KT와 같은 통신 사업자를 거쳐야만 다른 기업이나 전화기로 통화가 가능합니다만, 인터넷망은 DNS 서버의 주소만 알면 도메인 주소를 이용하여 전 세계 어디와도 전화 또는 영상 통화가 가능합니다. 물론, 클라우드 서비스에 가입하지 않았다면 방화벽을 투과하기 위한 장비들이 필요합니다.
3. 주요 SIP Header 분석
SIP 주소 체계를 이해하였으니 편지봉투의 주소를 읽을 수 있게 되었습니다. 이제 SIP 주소를 헤더에 포함되는 정보는 다음과 같습니다.
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 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 헤더는 앨리스가 밥에게 보내는 SIP INVITE 메시지입니다. 위에 열거된 헤더는 기본적인 SIP헤더이며 SIP 메쏘드에 따른 추가적인 헤더는 따로 설명합니다.
1) INVITE sip:bob@biloxi.com SIP/2.0
메시지의 첫 줄에는 Method와 메시지를 수신하는 최종 단말의 주소와 버전이 명기됩니다. SIP Method는 이 메시지의 목적이 무엇인지를 설명합니다. 첫 줄은 세 부분으로 되어 있습니다.
- INVITE : 요청한 메쏘드
- sip:bob@biloxi.com : Request URI (요청 메시지의 최종 목적지)
- SIP/2.0: 버전
Request-URI는 일반적으로 To 필드의 URI값을 참조하고, Biloxi.com 도메인에 있는 밥에게 전화를 걸기 위해 INVITE 요청을 보낸 것입니다.
2) Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Via 헤더는 INVITE 요청에 대한 응답을 위한 경로를 나타냅니다. branch는 시공간에서 유일한 값을 가지는 트랜잭션 식별자입니다. 트랜잭션은 호 설정 또는 호 종료와 같은 단위작업을 의미하며 User Agent 간에 생성됩니다.
이 줄은 SIP INVITE 요청에 대한 응답인 200 OK를 앨리스에게 바로 전송하지 말고 pc33.atlanta.com을 경유할 것을 요청합니다.
3) Max-Forwards: 70
시그널링 경로 상에 SIP 서버의 최대 홉 수로 IP 네트워크의 TTL (Time to Live)과 같습니다.
4) To: Bob <sip:bob@biloxi.com>
SIP 트랜잭션의 출발지를 나타내지만, 실제 SIP 메시지의 라우팅에 사용되지 않으며 Display Name의 의미를 가집니다.
5) From: Alice <sip:alice@atlanta.com>;tag=1928301774
SIP 트랜잭션의 목적지를 나타내지만, 실제 SIP 메시지의 라우팅에 사용되지 않으며 Display Name의 의미를 가집니다.
To 헤더와 From 헤더를 통해 앨리스가 밥에게 세션 설립을 요청하는 다이얼로그라는 것을 알 수 있습니다. From과 To 헤더는 현재 세션의 진행방향을 의미하는 것으로 현재 메시지의 발신자와 수신자를 의미하는 것이 아닙니다. 따라서 SIP INVITE 요청의 응답인 200 OK 메시지에서 From과 To 헤더의 내용이 바뀌지 않습니다. From과 To 헤더는 SIP 메시지의 라우팅에 관여하지 않으므로 잘못된 값을 가지더라도 세션 설립에 문제가 없지만, 보안이 강화되면서 From과 To 헤더의 값이 올바르지 않을 경우 호가 취소되기도 합니다.
6) Call-ID: a84b4c76e66710@pc33.atlanta.com
세션에 대한 global unique identifier로 사용하며, 호스트 네임 또는 IP address와 시간을 조합하여 생성됩니다. To/ From/ Call-ID가 결합으로 엘리스와 밥 간의 Pee-to-peer SIP 관계를 정의합니다. Call-ID가 같을 경우 하나의 다이얼로그로 인식하므로 세션의 설립과 종료 사이의 모든 SIP 메시지는 동일한 Call-ID를 가집니다.
SIP 패킷 수집 시 다수의 호가 썩여 있더라도 Call-ID를 기준으로 필터링을 하면 호별로 분석이 가능합니다. 다이얼로그는 다수의 트랜잭션으로 이루질 수 있고, 각 트랜잭션의 식별은 Via헤더의 branch 값으로 추적합니다. 다이얼로그의 식별은 Call-ID와 From 및 To의 Tag로 추적합니다.
7) CSeq: 314159 INVITE
Commnad Sequence 또는 Sequence Number는 정수와 메쏘드 이름으로 나타냅니다. 새로운 요청을 생성할 때마다 1씩 증가시킵니다. 이 요청에 대한 응답인 200 OK에서도 같은 값을 확인할 수 있습니다. 하나의 트랜잭션인 요청과 응답은 같은 CSeq값을 가집니다.
8) Contact: <sip:alice@pc33.atlanta.com>
Contact 헤더는 요청을 보낸 사용자에 대한 직접적인 경로를 나타내며, FQDN (Fully qualified domain name)나 IP주소를 선호합니다.
Via 헤더 필드가 요청에 대한 응답 경로를 나타내고, Contact 헤더 필드는 새로운 요청을 송신할 경로를 나타냅니다. 예를 들어, INVITE 요청에 대한 응답은 Via 헤더 필드를 참조하고, 호를 종료하기 위한 BYE 요청은 Contact 헤더를 참조합니다.
9) Content-Type: application/sdp
SIP 메시지 바디가 포함될 경우 메시지 바디의 타입을 정의합니다. applicaiton/sdp 이므로 SIP 메시지 바디는 SDP 메시지로 구성되었습니다.
10) Content-Length: 142
메시지 바디의 크기를 옥텟 (바이트)으로 표시합니다. 메시지 바디가 142 바이트로 구성되습니다.
'엔지니어를 위한 인터넷 전화와 SIP의 이해'를 책으로 만들다
https://brunch.co.kr/@linecard/188
