2009년 4월에 "SIP의 이해"라는 초특급 대하 울트라 스펙터클 서스펜스 슈퍼 메가톤 어드밴처 에로틱 다큐멘터리 액션 로망 연재를 마무리 짓고 뿌듯했던 기억이 떠오릅니다. ^^ 2010년에는 SIP Security를 정리했고, 이제는 CUCM SIP Trunking에 대해 정리해 보겠습니다. 시스코 SIP Trunking 기술은 지속적으로 진화하여 세세한 부분까지 설정이 가능합니다만, CUCM과 CUBE의 SIP 설정과 개념을 깊게 이해해야 한다는 단점이 있습니다.
SIP 메세지와 CUCM의 설정 부분을 함께 볼 수 있도록 정리하여 원하는 부분을 쉽게 변경하고 확인할 수 있도록 글을 정리하겠습니다. 이 연재는 "SIP의 이해" 연장선 상에 있는 글이므로 필독을 권해드리며, 귀차니즘으로 인해 SIP의 이해와 중복되는 내용은 단순화하고 CUCM의 SIP 구동 방식을 중심으로 설명하겠습니다.
CUCM은 SIP Proxy인가? B2BUA인가?
시스코의 CUCM을 이해하기 위한 첫 질문은 "CUCM은 SIP Proxy인가? B2BUA인가?"입니다. 이 질문에 답을 하신분들은 아래 글을 읽었거나 CUCM 전문가입니다. ^^
2009/04/06 - [Cisco UC Manager] - 시스코 CUCM (Call Manager)과 SIP
SIP는 UA (User Agent)간의 통신으로 클라이언트 서버 기반 프로토콜로 UAC (User Agent Client)와 UAS (User Agent Server) 간 통신을 다룹니다. SIP Proxy는 옵션장비로 다수의 UA간의 통신을 편리하게 해주는 역할을 수행하지만, UA가 보내는 SIP 메세지 전체를 수정 변경 삭제할 수없고, 특정 헤더를 삽입하거나 제한된 방법만을 이용합니다. SIP Proxy는 기업에서 사용되는 수많은 기능을 구현하기에는 제한적일 수 밖에 없습니다.
따라서, CUCM은 SIP Proxy가 제공하는 것보다 더 많은 부가 기능, 직접적인 코덱협상, CAC, VoIP 프로토콜간 상호연동 등의 기능을 수행하기 위해 B2BUA로 동작합니다. B2BUA는 Back-to-Back User Agent의 준말로 CUCM은 UAC 역할과 UAS의 역할을 동시에 수행합니다.
CUCM Trunking의 개요
CUCM과 전화기간의 통신을 Line side라 하고, CUCM과 CUCM간 또는 CUCM과 게이트웨이간 통신을 Trunk side 라 합니다. 기업의 IP PBX에서 외부와의 통신 (게이트웨이나 전화국)을 위해 사용되는 접점을 트렁킹이라고 부릅니다. 트렁킹이라는 의미는 하나의 연결에 다수의 호를 동시에 사용할 수 있다는 것으로 E1 Trunk는 하나의 회선 연결로 동시에 30 개의 호를 사용할 수 있었습니다. IP Trunk는 하나의 회선 연결로 다수의 호를 송수신 할 수 있습니다.
시스코 CUCM은 트렁킹을 위해 아래와 같이 SIP, MGCP, H.323 프로토콜을 사용합니다. MGCP Trunking은 ISDN 백홀을 이용하여 중앙집중식 호 제어를 이용하며, SIP와 H.323은 Peer-to-Peer 프로토콜입니다. H.323 Trunking이 일반적이였지만, SIP 전화기가 일반화되고 상호 운영성이 증가되면서 SIP Trunking을 많이 사용합니다. 시스코는 SIP Trunking을 추천하지만, 수십 대의 게이트웨이를 연결해야 하는 상황에서는 MGCP를 고려해 볼 필요가 있습니다.
SIP Trunking 상의 INVITE 메세지 분석
시스코의 가장 기본적인 SIP Trunking은 아래 그림과 같이 두 개의 CUCM 클러스터간의 통신입니다. 사실 CUCM과 CUCM간 통신에서는 상호 운영및 연동 이슈가 없으므로 기본 설정만으로도 잘 동작합니다만 세부적인 내용과 설정방법을 알고 있어야 타사 장비와 연결할 시 쉽게 연동할 수 있습니다.
아래 메세지는 2002전화기가 1001로 보내는 INVITE 메세지를 CUCM과 CUCM 사이의 Trunk에서 패킷 캡쳐한 것입니다.
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:1001@10.10.199.250>
Date: Wed, 17 Feb 2010 18:37:57 GMT
Call-ID: 8fe4f600-b7c13785-3-fbc712ac@10.10.199.251
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Contact: <sip:2002@10.10.199.251:5060;transport=tcp>
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
Session-Expires: 1800
P-Asserted-Identity: <sip:2002@10.10.199.251>
Remote-Party-ID: <sip:2002@10.10.199.251>;party=calling;screen=yes;privacy=off
Max-Forwards: 70
Content-Length: 0
SIP의 이해를 읽으신 분들은 쉽게 메세지의 내용을 이해할 수 있겠지만, 이해를 돕기 위해 메세지들을 블럭단위로 구분하고 SIP Trunk 설정 옵션과 함께 살펴 보겠습니다.
Route and Transaction 관련 헤더
아래의 세 개 메세지는 이 메세지의 속성과 경로를 나타냅니다.
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
CSeq: 101 INVITE
위의 SIP 헤더에 대한 메세지 정보와 CUCM에서 설정하는 법을 같이 살펴보겠습니다.
- INVITE sip:1001@10.10.199.250:5060 SIP/2.0 (필수)
10.10.199.250:5060 이라는 목적지 IP 주소와 포트는 Trunk의 SIP Information에 설정한 내용에 의해 결정됩니다. 참고로 Destination은 최대 16개까지 목적지를 설정할 수 있습니다.
Destination Address를 IP가 아닌 FQDN으로 설정한다면, 요청 메세지와 To 헤더의 포맷은 다음과 같이 표시됩니다. FQDN은 DNS SRV에 의해 IP address를 확인하므로 반드시 DNS를 구축해야 합니다.
"INVITE sip:1001@cisco.com:5060 SIP/2.0"
"To: <sip:1001@cisco.com>
수신측에서 어떤 URI 형식을 요구하는 지에 따라 변경할 수 있습니다. - Via: SIP/2.0/TCP 10.10.199.251;branch=z9hG4bK3395a5cdb (필수)
Via 헤더는 요청에 대한 응답 (200 OK)이 CUCM을 경유하기 위해 CUCM 직접 삽입한 헤더입니다. 만일 다수의 SIP Proxy를 경유할 경우 Via 헤더는 계속 추가됩니다. "branch"는 트랜잭션 식별자입니다. 트랜잭션은 호 설정 또는 호 종료와 같은 단위작업을 의미하고, User Agent 간에 생성됩니다. - Cseq: 101 INVITE (필수)
Cseq는 Command Sequence Header로 시퀀스 넘버와 메쏘드로 구성됩니다. 여기에서 메쏘드는 INVITE를 의미하고, 시퀀스 넘버는 101이며, 트랜잭션 단위에서 동일합니다. 즉, INVITE 요청과 200 OK 응답은 동일한 Cseq 헤더를 가지므로 트랜잭션을 추적할 때 편리합니다.
아래는 사용자 식별과 다이얼로그에 과련된 헤더입니다.
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:1001@10.10.199.250>
Call-ID: 8fe4f600-b7c13785-3-fbc712ac@10.10.199.251
P-Asserted-Identity: <sip:2002@10.10.199.251>
Remote-Party-ID: <sip:2002@10.10.199.251>;party=calling;screen=yes;privacy=off
Contact: <sip:2002@10.10.199.251:5060;transport=tcp>
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:1001@10.10.199.250> (필수)
사용자 식별과 관련된 가장 대표적인 헤더는 From과 To로 편지의 봉투에 해당합니다. 일반적으로는 Display Name을 표기하며, From 헤더에는 발신자를, To 헤더에는 수신자를 명기합니다. From의 tag는 발신 UA가 추가하고, To의 tag는 착신 UA가 추가합니다. Tag는 통신하는 두 UA간의 다이얼로그를 식별할 때 Call-ID와 함께 사용됩니다.
INVITE 요청과 200 OK응답 메세지에서 From과 To 헤더의 내용은 절대로 바뀌지 않습니다. From과 To 헤더는 Request (요청)의 방향을 나타내는 것이지 개별 메세지의 방향을 나타내는 것이 아닙니다. 많은 분들이 간혹 오해를 하시는 경우가 왕왕 있습니다.
From 헤더를 FQDN으로 설정하기 위해서는 SIP Profile에서 "Use Fully Qualified Domain Name in SIP Request"를 설정한 후 트렁크의 SIP Profile에 적용합니다.
위의 옵션을 설정하면 CUCM은 송신자의 Alphanumeric Host Name을 전송하기 위해 Enterprise Parameter에 설정된 "Organizational Top-Level Domain을 이용합니다. 만일 "Organizational Top-Level Domain을 cisco.com으로 설정하였다면, From, Remte-Party-ID, P-Asserted-Dentity가 모두 아래와같이 변경됩니다.
"From : <sip:2002@cisco.com>- Call-ID: 8fe4f600-b7c13785-3-fbc712ac@10.10.199.251 (필수)
특정 SIP 다이얼로그 (Dialog)를 추적할 때 사용합니다. 다이얼로그는 다수의 트랜잭션으로 이루질 수 있으므로 트랜잭션의 식별은 Via헤더의 branch 값으로 추적하고, 다이얼로그의 식별은 Call-ID와 From 및 To의 Tag로 추적합니다. - P-Asserted-Identity: <sip:2002@10.10.199.251> (옵션)
P-Asserted-Identity와 Privacy 헤더의 상관관계와 P-Preferred-Identity 헤더에 대한 기본적인 매커니즘에 대해서는 아래 글에 자세히 설명되어 있습니다.
2010/09/16 - [SIP의 이해] - [연재] SIP Security (상)
CUCM의 Trunk 설정에서 아래 그림과 같이 PAI 값에 대한 설정을 세세하게 할 수 있습니다.
기본적으로 CUCM의 PAI 및 PPI는 발신 단말 또는 트렁크에 값에 종속됩니다. 만일 "DN = 2002, Name = Bob Jones"라는 단말에서 INVITE가 나와서 트렁크를 경유한다고 가정한다면 Asserted-Type 값에 따라 P-Asserted-Identity 헤더는 다음과 같이 처리됩니다.
- Default : P-Asserted-Identity: "Bob Jones" <sip:2002@10.10.199.251>
- PAI : P-Asserted-Identity: "Bob Jones" <sip:2002@10.10.199.251>
- PPI : P-Asserted-Identity: "Bob Jones" <sip:2002@10.10.199.251>
일반적으로 PAI는 Trusted SIP Domain 내에서 전송되며, PPI는 Untrusted SIP Domain으로 부터 송수신됩니다. 국내 Service Provider와 SIP Trunking을 할 경우에는 주로 PAI값을 사용합니다. ^^
아래그림과 같이CUCM이 PPI를 전송시에 다른 SIP 도메인을 사용하는 트렁크의 상대측은 "Digest Authentication을 요청하지만, CUCM이 PPI를 수신 시에는 Digest Authentication을 요청하지 않습니다. 일반적으로 untrusted SIP 도메인으로의 연결은 SBC를 이용하므로 문제가 될 것은 없습니다. - Remote-Party-ID: <sip:2002@10.10.199.251>;party=calling;screen=yes;privacy=off (옵션)
Remote-Party-ID는 옵션 헤더이지만, CUCM SIP Trunk에서는 기본적으로 제공되도록 체크되어 있습니다. "screen=yes"는 CUCM에 의해 Remote-Party-ID가 확인되었음을 의미합니다. Party는 Calling 또는 Called로 표시되며며, "Privacy"는 Name/URL/Full/Off로 표시됩니다.
Remote-Party-ID는 PAI와 달리 인증 매커니즘을 가지고 있지 않습니다. 사용자 식별에 대해서는 뒤에서 좀더 자세히 다루겠습니다. - Contact: <sip:2002@10.10.199.251:5060;transport=tcp> (필수)
Contact 헤더는 Display Name과 URI 정보를 포함합니다. Request의 Contact 헤더에는 발신측의 주소가 명기되고, Response (응답)에는 수신측의 주소가 명기됩니다. 시스코의 CUCM은 B2BUA이므로 CUCM 서버의 주소가 표기됩니다.
일반적으로 혼동되는 것이 Via와 Contact 헤더입니다. Via는 Request에 대한 응답이 전달되어야 할 주소를 나타내고, Contact 헤더는 BYE나 UPDATE와 같은 신규 요청 생성시에 사용할 상대방의 주소를 나타냅니다.
3. From 헤더
Trunk를 기준으로 Outbound Call에 대해서는 Calling Line ID Presentation과 Calling Name Presentation의 설정에 따라 사용자 식별 정보가 INVITE에 포함되겠지만, Inbound Call에 대해서는 Connected Line ID Presentation과 Connected Name Presenation 설정에 따라 180 또는 200 응답에 포함될 것입니다.
사실 CUCM에서 SIP 헤더 변경을 위해 설정하지 않더라도 CUBE에서 SIP Profiles 설정으로 세세한 변경이 가능합니다. SIP에 대한 개념과 이해를 정확히 하고 있다면, 어느 장비에 변경하던 지는 상황에 따라 결정할 수 있을 것입니다. 아무래도 불필표한 작업을 최소화하는 것은 두 장비에 대해 모두 설정이 가능하다는 것을 이해하는 것이 필요합니다.
연재의 다른 글
SIP 관련 글들은 오른쪽 탭의 "SIP의 이해" 카테고리에 모두 포함되어 있으며, "SIP의 이해 2"는 아래에 링크를 통해 다시 살펴 보시기 바랍니다.
2013/12/19 - [SIP의 이해] - [연재] SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해 (상편)
2013/12/23 - [SIP의 이해] - [연재] SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해 (중편)
2013/12/24 - [SIP의 이해] - [연재] SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해 (하편)
라인하트 유씨누스(UCnus) (CCIEV #18487) --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스)
세상을 이롭게 하는 기술을 지향합니다. ________________________________________________________
