Chapter 3. SIP Method on RFC 3261
SIP 호 절차를 이해하기 위해서는 SIP 메세지에 포함된 SIP헤더를 잘 알아야 합니다. SIP헤더에 대한 기본적인 내용만 알고 있어도 쉽게 호절차를 분석할 수 있습니다. 특히, 이기종 장비간 SIP Trunk 연동이나 단말 연동 시 장애가 발생할 경우에 SIP 패킷을 수집하여 분석하는 과정을 거치게 됩니다. SIP 헤더를 알지 못하면 수집된 패킷은 암호문일 뿐입니다. UC 엔지니어들의 SIP에 대한 피상적인 곁눈질를 넘어 체계적으로 SIP 기술을 이해할 수 있를 도록 SIP 헤더를 살펴보겠습니다.
1. SIP주소 체계
PTSN 전화망은 E.164 주소 체계를 사용하고, 인터넷망은 IP 주소 체계를 사용합니다. E.164 주소체계는 사람이 인식하기 쉬운 주소 체계이지만, IP 주소체계는 어렵습니다. 인터넷에서 유트브나 네이버를 접속하기 위해 IP주소를 웹브라우저에 입력하여 접속할 수 있지만, 사람들은 도메인 네임인 www.youtube.com 이나 www.naver.com이라는 도메인 네임 주소로 접속합니다. IP 주소 체계보다 도메인 네임 체계가 훨씬 이해하기 쉽기 때문입니다. 전자메일도 마찬가지입니다.
SIP를 이용한 통화를 위한 주소체계는 다양한 형식의 주소 방식을 지원합니다.
FQDN (Fully-Qualified Domain Names)
인터넷 서핑을 할 때 웹브라우저에 입력하는 도메인 주소 체계입니다. 도메인의 앞 자리에 사용자명 또는 단말기명을 붙여서 사용합니다.
예)sip:bob.cisco.comSMTP와 같은 Domain Names (RFC2368)
메일 주소와 같은 방식을 사용합니다.
예) sip:bob@cisco.comE.164와 같은 주소
사용자이름 부분에 전화번호를 넣어서 사용합니다.
예) sip:14085551234@gateway.com; user=phone혼합된 주소 체계
IP 주소를 함께 사용할 수 있습니다.
예) sip:14085551234@10.1.1.1; user=phone
sip:bob@10.1.1.1
6. 주요 SIP Header 분석
일반적으로 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헤더를 살펴보면서 이해해보겠습니다.
INVITE sip:bob@biloxi.com SIP/2.0
메세지의 첫 줄에는 Method와 메세지를 수신하는 최종 단말의 주소와 버전이 명기되므로 메세지가 생성된 목적을 확인할 수 있습니다.
- INVITE : 요청한 메쏘드
- sip:bob@biloxi.com : Request URI
- SIP/2.0: 버전
Request-URI는일반적으로는 To 필드의 URI값을 이용하여 표시합니다.
이 줄은 Biloxi.com 도메인에 속해 있는 밥에게 전화를 걸고 싶다는 의미입니다.Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Via 헤더는 요청에 대한 응답을 위한 경로를 나타냅니다. branch는 시공간에서 유일한 값을 가지며, 트랜잭션 식별자입니다. 트랜잭션은 호 설정 또는 호 종료와 같은 단위작업을 의미하며 User Agent 간에 생성됩니다.
이 줄은 SIP INVITE요청에 대한 응답인 200 OK를 앨리스에게 바로 전송하지 말고 pc33.atlanta.com을 경유할 것을 요청한다는 의미입니다.Max-Forwards: 70
시그널링 경로 상에 SIP 서버의 최대 홉 수를 나타냅니다. IP네트워크의 TTL (Time to Live)과 같습니다.To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
SIP 메세지의 출발지와 목적지를 나타내지만, 실제 메세지의 라우팅에 사용되지 않으며 Display Name의 의미를 가집니다.
이 줄은 앨리스가 밥에게 세션 설립을 요청하는 다이얼로그라는 의미입니다.
From과 To 헤더는 현재 세션의 진행방향을 의미하는 것으로 현재 메세지의 발신자와 수신자를 의미하는 것이 아닙니다. 따라서 SIP INVITE 메세지의 응답인 200 OK에서 From 과 To 헤더의 내용이 바뀌지 않습니다. From과 To의 값이 엉뚱하게 적혀있어도 SIP 프로토콜이 진행되는 데는 문제가 없습니다만, 요즘에는 SIP 보안이 강화가 되면서 From 과 To 헤더가 잘못 명기되면 호가 진행되지 않기도 합니다.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로 추적합니다.CSeq: 314159 INVITE
Commnad Sequence또는 Sequence Number는 정수와 메쏘드 이름으로 나타냅니다. 새로운 요청을 생성할 때마다 1씩 증가시킵니다. 이 요청에 대한 응답인200 OK에서도 같은 값을 확인할 수 있습니다.
하나의 요청과 응답은 같은 CSeq값을 가집니다.Contact: <sip:alice@pc33.atlanta.com>
SIP URI 포맷으로 되어 있으며, 요청을 보낸 사용자에 대한 직접적인 경로를 나타냅니다.
일반적으로 FQDN (Fully qualified domain name)나 IP주소를 선호합니다. Via 헤더 필드가 요청에 대한 응답 경로를 나타내고, Contact 헤더 필드는 미래의 요청을 보낼 경로를 말합니다. 요청에 대한 응답은 Via 헤더 필드를 참조하며, 신규 요청을 생성할 경우는 Contact 헤더 필드를 참조한다는 것입니다.Content-Type: application/sdp
메세지 바디가 있을 경우 메세지 바디에 대한 설명입니다.applicaiton/sdp는 SIP 메세지 바디가 SDP 메세지로 구성되었다는 의미입니다.Content-Length: 142
메세지 바디의 크기를 옥텟 (바이트)로 표시합니다. 메세지 바디가 142 바이트로 구성되었다는 의미입니다.
지금까지 기본적인 SIP Header를 살펴보았습니다. 이 후에 나오는 SIP Method별로 추가되는 헤더가 무엇인지를 살펴볼 것입니다.
3. SIP 헤더 분석하기 - SIP Proxy가 없는 경우
지금까지 살펴본 SIP 헤더를 기준으로 SIP 호 절차를 분석해 보겠습니다. 실제 구현되는 일반적인 사례는 아니지만, SIP메세지를 이해하기 쉽도록 SIP 전화기 두 대 사이에 SIP Proxy가 존재하지 않고, 앨리스의 전화기는 밥의 전화기 IP주소를 알고 있다고 가정합니다.
- 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 헤더를 보니 앨리스가 밥에게 보내는 INVITE 요청입니다. INVITE의 요청에 대한 응답은 Via 헤더에서 표시한 pc33.atlanta.com을 경유하라고 표시되어 있으며, CSeq를 보니 314159 번의 INVITE 메세지입니다. Content-Type 헤더에 메세지를 보니 SIP 메세지에 SDP가 포함되어 있음을 알수 있습니다. SDP는 나중에 다루겠습니다.
- 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 헤더는 현재 메세지의 출발지와 목적지가 아닌 호의 진행방향을 나타내는 것으로 INVITE 메세지의 From과 To헤더와 동일합니다.
CSeq 헤더는 314159 INVITE 요청에 대한 응답임을 나타냅니다. 패킷 분석 시 여러 호가 동시에 진행될 때 어떤 호에 대한 응답인지를 판단할 때 CSeq를 통해 확인합니다.
- 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임을 확인합니다. - 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 헤더를 보니 세션의 진행방향은 밥이 앨리스에게 요청하는 다이얼로그이므로 밥이 먼저 수화기를 내려놓았습니다. - 200 OK
CSeq를 보니 BYE 에 대한 200 OK임을 알 수 있습니다.
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
SIP 패킷을 캡쳐하여 분석할 경우에 유용합니다. 이제 본격적으로 SIP 네트워크에 SIP Proxy가 있는 경우를 살펴보겠습니다.
3. SIP 헤더 분석하기 - SIP Proxy가 있는 경우
실제 SIP망을 구성할 때는 SIP Proxy 서버나 IP PBX가 항상 존재합니다. IP PBX는 제품에 따라 SIP Proxy로 구현하거나 B2BUA로 구현됩니다. 앨리스의 전화기는 밥의 전화기 주소를 알지 못하므로INVITE 메세지를 SIP Proxy로 전송하는 과정부터 살펴보겠습니다.
앞에서 설명 부분과 다른 SIP헤더를 위주로 살펴보겠습니다.
- INVITE (앨리스가 SIP Proxy 서버로 보내는 것)
앨리스는 밥에게 전송할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
- INVITE (SIP Proxy 서버가 밥에게 보내는 것)
SIP Proxy 서버를 경유한 INVITE 메세지는 다음과 같이 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 요청에 관한 응답이 SIP Proxy를 경유하도록 요청합니다. Max-Forwards 헤더가 70에서 69로 줄었습니다. 한 개의 SIP 서버를 지날 때마다 1씩 줄어듭니다.
CSeq 와 Call-ID가 SIP Proxy를 지나가지만 변경되지 않았습니다. SIP Proxy 서버는 제한적으로 메세지를 추가 삭제할 수 있지만, 새로운 세션을 생성하지 않는다는 것을 의미합니다.
- 200 OK (밥이 SIP Proxy 서버로 보내는 것)
밥은 INVITE의 Via 헤더를 그대로 복사하여 200 OK에 포함하였으므로 200 OK가 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
- 200 OK (SIP Proxy 서버가 앨리스로 보내는 것)
Via 헤더가 하나 줄었습니다. SIP Proxy 서버가 임의로 삽입한 Via헤더는 엘리스의 전화기에는 필요가 없으므로 SIP Proxy가 삭제합니다.
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 - ACK
앨리스의 전화기는 밥의 200 OK를 정확히 수신했음을 확인하는 ACK를 밥의 전화기로 바로 보냅니다. ACK는 새로운 신규 요청이므로 다이얼로그 상의 Contact 헤더를 따라 직접 전달됩니다.
모든 SIP 메세지를 SIP Proxy서버를 경유하게 하기
Via 헤더를 통해 INVITE에 대한 200 OK는 SIP Proxy서버를 경유하지만, ACK 이하의 모든 신규 요청 메세지는 Contact 헤더를 참조하여 단말끼리 직접 송수신합니다.
기업의 IP PBX는 호의 상태를 관리 및 과금 데이타 생성을 위해 호 절차의 따른 모든 시그널링 메세지가 IP PBX 를 경유하도록 합니다. B2BUA가 아닌 SIP Proxy 서버가 자신에게 등록된 모든 단말의 시그널링이 경유되도록 하기 위해서는 기존 SIP 헤더를 변경하거나 새로운 SIP 헤더가 필요합니다.
질문
모든 시그널링 메세지가 SIP Proxy 서버를 경유하도록 하기 위해 INVITE 메세지가 SIP Proxy 서버를 경유할 때 새로운 SIP 헤더를 삽입해야 합니다. 어떤 헤더가 필요할까요?
"다시쓰는 SIP의 이해" 연재의 다른 글
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해
2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method
2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method
2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method
2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method
2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method
2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method
2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method
2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method
2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP
2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP
2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP
2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response
2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261
2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261
2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261
2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview
2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview
2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)
2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)
2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)
라인하트 유씨누스 (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________