Chapter 3. SIP Method on RFC 3261
4. 모든 SIP 메세지를 SIP Proxy서버를 경유하게 하기
Via 헤더를 통해 INVITE에 대한 200 OK는 SIP Proxy서버를 경유하지만, ACK 이하의 모든 신규 요청 메세지는 Contact 헤더를 참조하여 단말끼리 직접 송수신합니다.
기업의 IP PBX는 호의 상태를 관리 및 과금 데이타 생성을 위해 호 절차의 따른 모든 시그널링 메세지가 IP PBX 를 경유하도록 합니다. B2BUA가 아닌 SIP Proxy 서버가 자신에게 등록된 모든 단말의 시그널링이 경유되도록 하기 위해서는 기존 SIP 헤더를 변경하거나 새로운 SIP 헤더가 필요합니다.
개발자들은 두 개의 새로운 헤더를 추가하는 것으로 문제를 해결하였습니다.
- Record-Route Header
옵션 SIP 헤더로 SIP Message를 확인하려는 모든 SIP Proxy에 의해 삽입됩니다. SIP Proxy를 통해 경유되는 다이얼로그 (같은 Call-ID)에 대한 요청과 응답에 사용됩니다. 여러 대의 SIP Proxy를 경유해야 하는 경우에는 ","를 이용하여 계속 추가합니다.
예) Record-Route: server10.biloxi.com
Record-Route: server10.biloxi.com, bigbox3.atlanta.com
- Route Header
같은 Call-ID 의 응답 메세지의 Record-Route Header로 부터 생성됩니다. 같은 다이얼로그 내의 첫번째 Transaction이 완료되면, 이후 트랜잭션은 Record-Route Header의 값을 복사하여 Route 헤더로 사용합니다.
예) Route: server10.biloxi.com
특히, 모든 SIP 메세지가 경유되는 SIP Proxy를 Dialog Stateful SIP Proxy 서버라고 합니다. Record-Route와 Route Header의 사용 방식에 대해 살펴보겠습니다.
앨리스의 전화기가 INVITE 메세지를 송신하면 SIP Proxy는 Record-Route 헤더를 삽입하여 밥에게 전송합니다. 이를 통해 밥의 전화기는 동일한 Call-ID를 가진 다이얼로그 내의 신규 요청을 SIP Proxy로 보내게 됩니다.
INVITE sip:bob@biloxi.com/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
Record-Route: server10.biloxi.com
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
밥의 전화기는 INVITE에 대한 응답인 200 OK 에 기존의 Record-Route 헤더를 복사하여 전송합니다. ACK 는 세션 설립을 위한 마지막 메세지이므로 SIP Proxy는 Route 헤더를 제거한 후에 밥에게 전송합니다. 호 종료를 위한 BYE는 기존 다이얼로그의 Record-Route 헤더를 복사하여 전송하고, 200 OK는 Via 헤더를 따라 전송되므로 Route 헤더를 삽입하거나 않하거나 상관없습니다.
RFC 3261에는 6개의 메쏘드가 정의되어 있으며, 지금까지는 기본 호 절차에 관련된 INVITE, ACK, BYE에 대해 설명하였으며, 나머지 3 개 메쏘드를 차례대로 살펴보겠습니다.
5. REGISTER의 개요
지금까지 SIP Proxy 가 등록된 모든 전화기들의 주소를 안다고 가정하였습니다. REGISTRER 메쏘드를 설명하면서 SIP Proxy 서버가 어떻게 알고 있는 지를 생각해 보겠습니다.
서로 통화를 해야 하는 전화기의 숫자가 증가할수록 SIP Proxy 서버나 IP PBX를 이용한 중앙집중식 관리가 효과적입니다. 단말의 등록은 SIP 컴포넌트인 REGISTRAR 서버가 담당하지만, 기업에서 사용하는 SIP Proxy 와 논리적 기능을 같이 구현합니다.
전화기는 SIP Registrar 서버에 REGISTER 메쏘드를 이용하여 전송하면 SIP Registrar 서버는 200 OK를 응답하므로써 등록이 이루어집니다.
등록과정의 메세지를 분석해 보겠습니다.
- REGISTER
Register 메세지의 Request-URI는 SIP Registrar 서버의 주소가 됩니다. From과 To 헤더는 세션의 진행방향을 의미하는 것으로 앨리스가 SIP Proxy 로 보내는 것임을 알수 있습니다.
REGISTER sip:server19.atlanta.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bk2l55n1
To: Alice <sip:alice@atlanta.com>
From: Alice <sip:alice@atlanta.com>;tag=283074
Call-ID: a84b4g96te10@pc33.atlanta.com
CSeq: 31862 REGISTER
Contact: <sip:alice@10.1.3.33>
Expires: 21600
Content-Length: 0
REGISTER 메세지의 Expires 헤더는 SIP Proxy 서버에게 21600초 동안 등록을 유지해 줄것을 요청하는 것입니다.
- 200 OK
SIP Proxy 는 200 OK를 전송하면서 등록을 승인합니다.
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bk2l55n1; received=10.1.3.33
To: Alice <sip:alice@atlanta.com>; tag=a6c85e3
From: Alice <sip:alice@atlanta.com>;tag=283074
Call-ID: a84b4g96te10@pc33.atlanta.com
CSeq: 31862 REGISTER
Contact: <sip:alice@pc33.atlanta.com>
Contact: <sip:alice@cm9013.atlanta.com>
Service-Route: <sip:bigbox3.atlanta.com;lr>
Expires: 3600
Contact-Length: 0
SIP Proxy는 Expires 헤더의 값은 21600초에서 3600초로 변경하였습니다. SIP Proxy 서버는 전화기에게 한시간마다 재등록할 것을 요청하는 것입니다. REGISTER의 재등록 매커니즘은 일정한 간격으로 이루어지므로 SIP Registrar 서버와 단말간의 Keepalive 매커니즘의 기능을 수행합니다
6. REGISTER : 사용자가 다수의 전화기를 사용하는 문제
단말의 등록 과정은 단순하지만 200 OK 메세지에 포함된 두 개의 Contact 헤더를 이해하기 위해 한 가지 더 고려해 보겠습니다. 만일 엘리스의 전화기가 한 대가 아닌 여러 대일 경우입니다. 요즘 직원들은 PC용 소프트폰, 데스크탑 IP Phone, 그리고 스마트폰의 전화앱을 사용합니다. 여러 대의 전화기가 같은 SIP Proxy서버에 등록되어 있다고 가정하면, 발신자는 수신자의 단말을 구분해서 전화를 해야 합니다. 발신자가 수신자가 받을 수 있는 단말을 예측해서 전화를 걸면 되지만 현실적인 방법은 아닙니다.
그러므로 발신자가 엘리스의 주소로 전화를 걸면 SIP Proxy는 자신에게 등록된 여러 대의 단말을 동시에 울려주고 앨리스는 받기 편한 전화기를 선택해서 받으면 됩니다. SIP Proxy 서버가 엘리스가 여러대의 단말을 가지고 있다는 것을 인식하기만 하면 됩니다. Registrar 서버를 위한 새로운 형식의 주소 체계가 필요합니다.
사용자가 여러 대의 단말을 사용하더라도 문제없도록 address-of-record (AOR) URI와 Contact address라는 개념을 이용합니다.
- AOR (Address of Record) 사용자 주소
예)Bob@biloxi.com - Contact Address 등록된 단말의 주소
예) bob@phone66.biloxi.com
새로운 주소 체계를 기반으로 생각해 보면 전화기의 등록과정은 전화기의 IP 주소와 사용자의 SIP 주소를 연결하는 것입니다. 기술적으로는 address-of-record (AOR) URI와 Contact address 를 바인딩하는 것입니다. SIP 네트워크가 단순히 E.164 전화번호와 IP 주소를 바인딩하여 사용한다면, AoR은 전화번호가 되고 Contact address는 IP 주소가 됩니다.
엘리스가 밥과 통화 시도 시 엘리스의 INVITE는 Bob@biloxi.com 주소로 보내집니다. 밥이 몇 개의 단말을 사용중이며 현재 통화 가능한 단말이 무엇인지는 biloxi.com의 SIP Proxy 서버만이 알고 있습니다. 따라서 biloxi.com 도메인 밖에서는 Bob@biloxi.com이 가장 유효한 주소가 되고, biloxi.com의 SIP Proxy 서버는 등록된 단말을 찾을 수 있는 Contact Address 주소가 유효합니다. 이런 AOR과 Contact Address를 바인딩하는 것이 등록 (Registration)입니다.
등록 과정에서 REGISTER 메세지에 대한 200 OK응답에 2개의 Contact 필드가 있었던 것은 SIP Proxy 서버에 바인딩된 모든 Contact address 정보를 표시하기 때문입니다.
7. REGISTER : SIP Proxy 서버 주소 획득의 문제
UA가 SIP Registrar 서버에 등록하는 과정의 전제는 단말이 SIP Registrar 서버의 주소를 알고 있다는 가정이 필요합니다. 또한, 전화기가 등록을 완료한 후에 통화를 위해 INVITE 메세지를 전송할 SIP Proxy 서버의 주소를 획득한다는 가정도 필요합니다. 일반적으로 SIP Registrar 서버와 SIP Proxy 서버는 동일한 시스템에서 구현하므로 같은 문제입니다. 주소를 획득하는 방법은 여러가지가 있습니다.
- 전화기(UA)에 직접 입력
가장 많이 사용했던 방법입니다만 UA 설정 정보 관리와 업데이트에 대한 문제가 있습니다. - HTTP또는 TFTP와 같은 프로토콜 활용
TFTP를 이용한 방법은 가장 널리 사용되는 방법이지만, 방화벽 등으로 인해 관리가 복잡하다는 단점이 있습니다. UA가 SIP 외에 다른 프로토콜 엔진을 구동해야 합니다.
Registrar 서버의 주소를 획득하는 방법은 표준화가 되어 있지 않으므로 각 제조사별로 다양한 방법을 구사합니다. 전화기나 단말에 IP 주소를 할당하는 DHCP 프로토콜은 IP 주소외에 DNS 나 TFTP 서버의 주소를 함께 할당할 수 있습니다. 전화기는 TFTP 서버의 주소를 받은 후 전화기 구성 정보 파일을 다운로드 받으면서 필요한 SIP Proxy 서버나 SIP Registrar 서버의 주소를 획득할 수 있습니다.
Registar 서버의 주소는 다양한 경로를 통해 획득하였다고 가정할 경우 SIP Proxy 서버의 주소를 획득하는 방법을 기술한 문서는 IETF RFC 3608 Service Route Extension Header 입니다. REGISTER 메세지를 받은 SIP Registrar 서버가 등록을 승인한 후 200 OK 응답 전송 시 Service-Route 헤더에 명시적으로 사용할 SIP Proxy 서버를 통지합니다.
위의 REGISTER 메세지에 표시된 Service-Route 헤더의 bigbox3.atlanta.com 이 SIP Proxy서버의 주소가 됩니다.
질문
등록 과정의 이해를 돕기 위해 문제점과 해결책이라는 관점에서 이야기를 풀어보았습니다. REGISTER 메세지에 대한 이야기는 여기서 마무리 하겠습니다. 이번 글에서도 문제를 하나 내볼까요?
발신자가 전화를 걸어서 상대방이 전화를 받을 때 까지의 과정을 항상 설명하였습니다. 그런데 전화를 걸다가 갑자기 수화기를 내려놓는 경우가 간혹있습니다. 전화번호를 잘못 눌렀다던지 상사분이 갑자기 부른다던지 상대방이 전화를 받지 않는다던지 하는 경우입니다. 이 때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를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________
