폴리콤 화상 회의 코덱을 통해 영상회의를 할 경우 어떻게 호가 설정되는 지 궁금했습니다. 그래서, Ehtereal을 통해 패킷을 캡쳐하여 분석하였습니다. 시간이 날 때 정리한다고 하다가 보니 지금 올리게 되었습니다. 그리고, 지금 진행되는 연재도 마무리해야 하는 데 갈길이 멀어서 큰일입니다. 관심있게 보시는 글에 답글 달아 주시는 글 위주로 해서 연재 마무리 하겠습니다. 답글이 없는 글들이 많아서 제가 너무 관심이 적은 글만 쓰는 것이 아닌가하는 생각이 듭니다. 헐헐..
이글을 이해하기 위해서는 SIP 및 RTP에 대한 기본 지식 정도는 있어야 합니다. 제가 주석은 달겠지만, 기본지식이 없으면 이해하기 어렵습니다. 따라서, RFC 3261 와 RFC 3550 , RFC 3551 정도는 같이 열어서 보시면 쉽게 이해할 수 있을 것입니다. 구성도는 아래와 같습니다.
PVX에서 HDX 8000으로 일대일 영상회의를 시도하는 구성입니다. 그림을 8000으로 했는 데 분석하다 보니 HDX 9000입니다. 그러나, 같은 프로시져일 것이므로 HDX 8000으로 그냥 적어 나갔습니다. 간단하게 PVX는 소프트웨어 기반의 개인 화상회의 프로그램으로, 시스코 사용자에게는 CUVA (Cisco Unified Video Advantage)로 이해하시면 될 듯합니다. 실제는 음성 및 IM 기능까지 가지고 있어서 CUPC에 더 가깝습니다. HDX 시리즈는 HD 화상회의 시스템으로 8000 및 9000은 회의실 용입니다. 제품에 대해 알고 싶으신 분은 "폴리콤 HD 화상회의란?" 블로그를 참조하시기 바랍니다.
호 프로시져는 아래와 같습니다. 이더리얼로 보면 두개의 호로 표현이 됩니다. 서로다른 SIP Proxy에 의해 서로다른 호로 인식되며, 다른 Call-ID를 사용합니다.
최초에 PVX에서 Invite with SDP 메세지를 전송하며, SIP Header만을 먼저 살펴보도록 하겠습니다.
Request-Line : INVITE sip:0047@broadsoft.com SIP/2.0
- Request-Line = Method SP Request-URl SO SIP-Version CRLF
- Method 는 SIP 매소드를 나타내며, Request-URL 는 사용자나 서비스를 의미하며, 여기에서는 broadsoft.com 도메인의 0047을 향해는 Invite로 SIP 버전 2.0임을 의미합니다
via : SIP/2.0/UDP 58.101.3.54:5060;branch=
- UAC의 모든 Request에는 via 필드가 반드시 포함되어야 함
- UAS는 이 필드를 참조하여 Request에 대한 응답을 수행함
- 여기에서는 58.101.3.54:5060으로 Request에 대한 응답을 수행할 것을 나타냄
Max-Forwards: 70
- Hop을 지날 때 마다 감소하며, 0이 될때까지 목적지에 도달하지 못하면 "483 Too many hops" Error을 생성
- 일반적으로 최초 값은 70으로 설정
- 여기서 홉은 라우터가 아닌 sip procy 또는 user agent 이다.
Allow
현재 User Agent에 의해 지원되는 매소드를 정의
Supported : timers, replaces, 100rel
- User Agent 에서 지원하는 Option tag를 나타냄
From :
- 이 Request를 생성한 User agent를 나타냄
- "Display Name" 부분에 실제 사용자의 정보가 들어올수 있음
To:
- 이 Request의 수령자를 나타냄
- 사용되는 상대방의 이름은 네이밍 규칙에 의해 표현됩니다.
Call-ID :
- 한 단말의 모든 등록요청은 하나의 Call-ID를 가짐
- 하나의 호에는 하나의 Call-ID가 할당됩니다.
Cseq : 1 INVITE
- 트랜잭션마다 하나씩 증가합니다. 재전송된 요청의 경우에도 CSeq는 하나씪 증가합니다.
Session-Expire : 90
- RFC 3261에 딱히 설명이 없습니다.
Contact
- 이요청에 대한 응답을 받고자 하는 User Agent의 URL이 기록됩니다.
User-Agent
- 실제 요청을 보내는 소프트웨어 또는 단말에 대한 정보를 표시
Content-Length
- "Message Body"의 사이즈를 나타냄
Content-Type : application/sdp
-"Media-Type"을 정의하며, 여기에서는 SDP에 명시되어 있음을 의미
Invite 메세지에 대한 정보를 살펴보았습니다. Invite메세지에는 여러 다양한 정보가 있지만, 일반적으로 Via와 Contact 필드를 보면, UAS가 응답을 어디로 해 오겠구나를 알수 있습니다. 아직 User agent는 07070000047의 IP address를 알수가 없습니다. 이부분은 SIP Proxy 서버가 알아서 relay를 해 줄 것입니다.
Invite 메세지에 함께 실려가는 SDP 메세지에 대해 살펴보겠습니다.
v=0
- Session Description Protocol Version을 의미하며 현재 0임
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
- Session Originator를 나타냄, 즉 Invite 요청을 하는 User Agent
- "IN"은 Internet을 의미하여 네트워크 타잎을 표시
- IP Address Type은 IPv4 이며, IP 주소를 나타냄
s=
- Session Name을 나타내며, 반드시 정의되어야 합니다. 여기에서는 "-"로 표시
c= <nettype> <addrtype> <connection-address>
- Connection Information 또는 Connection Data
b=<bwtype>:<bandwidth>
- bandwidth Information
- AS:384 는 어플리케이션에서 설정된 Bandwidth 정보를 줍니다. 일반적으로 conference를 할 경우 주요 대역폭에 대한 계산을 위해 제공됩니다.
m=<media> <port> <proto> <fmt>
- 다수의 media description을 포함하며, 하위 속성(a) 필드를 나타냅니다.
- <media> 는 audio, video, text, message 등을 나타냄
- <port> 는 Media Stream이 보내지는 RTP의 Layer 4 포트입니다.
- <proto>가 RTP/AVP이면 RFC 3551에 의한 RTP 프로파일을 사용
- 나머지는 payload Type을 나타내며 아래 (a=)와 매치가 됩니다 .처음에 나오면 payload Type이 Default Value입니다. 여기서는 음성은 Siren14가 기본 코덱이며, 영상은 H.263 코덱입니다.
-
a=<attribute>:<value>
- Payload Type 및 속성에 대해 나타냅니다.
-"a=rtpmap 99 Siren14/16000 "이면, 16Khz sampling을 사용하는 Siren 14 코덱을 쓰며, Paylaod Tyoe 99로 전송되도록 RTP를 설정함을 의미합니다.
이렇게 하여 SDP를 살펴보았습니다. 여기서 관심가져야 할 항목은 아무래도 m과 a 입니다. 실제 capability negotiation을 할 때 어떤 코덱으로 가져가며, RTP에서 사용할 Port번호등에 대한 정보를 확인할 수가 있습니다.
다음은 100 Trying입니다. 일반적으로 SIP Procy가 Invite메세지를 받아서 처리함을 나타냅니다. 따라서, 100 Trying을 받은 송신자는 다음 메세지를 자동으로 대기하게 됩니다.
이 메세지는 단순히 진행됨을 의미하는 것이며, Via, From, To를 살펴보면 아시겠지만, 자기자신이 자기 자신에게 보내는 것으로 되어 있습니다. 당연히 Call-ID는 동일해야 할 것입니다.
다음은 SIP Proxy가 HDX 8000 으로 Invite 메세지를 Relay하는 메세지입니다.
Request-Line
- 18.181.3.52 수신 HDX 8000으로 07070000047번으로 Invite 메세지가 전송됨을 확인
Via
- 58.181.3.11 SIP Proxy Server로 이 요청에 대한 응답을 수행할 것으로 예상
From 과 To
- 송신자는 "49 Test"인 07070000049번이며, 수신자는 "47 Test"07070000047"번임을 알수 있음
- 즉, 현재 진행되고 있는 호는 PVX에서 HDX 8000으로 진행되는 호임을 의미
Call-ID
- call-ID를 보면 알수 있듯이 SIP Proxy를 기준으로 각각이 서로 다른 세션임을 확인할 수 있습니다. 즉, PVX랑 SIP Proxy가 한 세션, SIP Proxy랑 HDX 8000 이 한 세션이렇게 진행되는 것을 알수 있으며, 따라서 Ethereal에서 녹색과 파란색으로 구분해주는 것입니다.
Contact
- HDX 8000의 입장에서는 SIP Proxy랑 통신하는 프로세스이며, Contact에도 그렇게 나와 있습니다. 그러나, Request-Line을 통해 PVX에서 Relay된 것을 확인할 수 있습니다.
여기에서는 정확하게 상대방에게 Relay되었음을 확인하면되고, SDP의 경우 그대로 전송되었는 지를 알면됩니다. SDP에 대해서는 따로 명기하지 않겠습니다.
다음은 180 Ringing 메세지이며, HDX 8000에서 발생된 메세지가 그대로 상대방에게 Relay되므로 하나만 살펴보겠습니다.
From과 To
- 이 두 부분을 보면 "49 Test"에서 "47 test"로 보내진다는 것을 알 수 있습니다.
Contact-Lenth : 0
이 부분이 제로인 것은 Message-body가 없기 때문입니다.
이 메세지에서 명심해야 될 부분은 현재 호의 흐름은 원 발신자 "49 Test"또는 07070000049번이 "47 Test" 또는 07070000047로 전화를 건 프로세스임을 명심해야 합니다. 여기 Ringing만을 보고 From과 To가 혼동되면 않됩니다. 이메세지는 58.181.3.11을 경유하여 58.181.3.52 PVX로 들어가는 메세지입니다. 이메세지를 받은 PVX는 RTP 채널을 개방하여 Ringback을 받을 수 가 있는 것입니다. 실제 Invite에서 오는 From과 To를 나타내는 방식이 틀립니다.
다음 메세지는 200 OK입니다. Connection의 의미이며, 상대방이 Off-hook를 진행했음을 나타냅니다.
HDX 8000에서 SIP Proxy Server로 연결되었음을 알리기 위한 메세지입니다. 여기에서는 별반 도움이 되는 필드는 없습니다. 200 OK에서 중요한 것은 SDP 메세지 입니다. 아래 그림은 SDP 메세지를 나타낸 것입니다.
일반적인 메세지의 의미는 이미 다 설명했습니다. 여기에서는 m과 a만을 살펴보겠습니다. 음성의 경우, Payload Type은 9, G.722/8000 이 기본 코덱으로 선정되었으며, IP Address 및 UDP port는 58.181.3.52/49226으로 보내며, 양방향으로 소통할 것임을 나타냅니다.
영상의 경우, Paylaod Type은 34, H.263/90000이 기본 코덱으로 선정되었으며, IP Address는 동일하고, UDP Port는 49228을 사용할 것이며, 양방향입니다. 영상은 384Kbps를 기준으로 전송될 것이며, 최대 화질은 4CIF일 것입니다.
이즈음 살펴보았으면, 대충 보고도 알 수 있어야 겠습니다. 잘 모르시겠다면, 위의 Invite with SDP 부분을 다시 한 번 살펴보시기 바랍니다.
아래 그림은 ACK 메세지 입니다. 200 OK 메세지를 정확하게 수신했음을 의미합니다.
이렇게 하여 호 프로시져가 완료되었습니다. 그럼 어떻게 Capability Negotiation이 된 것일까? 맨 처음 제공된 그림을 보면 답을 알수가 있습니다. 즉, 각자가 자신이 원하는 것을 말하였습니다. 따라서, 각자의 패킷을 보내주는 주는 것이 폴리콤 장비의 기본 정석입니다. 아무래도 HDX 와 PVX는 Transcoding 기능을 이용하여 각자 Transcoding을 수행하는 듯합니다.
즉, HDX 8000은 H.263 영상과 Siren14 음성 코덱을 이용하여 데이타보내고, PVX는 H.263 영상과 G.722 음성을 전송합니다. 실제 각자가 원하는 것을 선택한 결과입니다. 일반적으로 동일한 포맷을 전송하기 위해 ACK 전송시 ACK with SDP를 전송하는 경우는 200 OK with SDP 메세지를 준용하여 그 결과에 따라 같은 값을 선택합니다.
영상통신을 SIP 프로토콜로 할 경우에 대한 패킷 분석을 해 보았습니다. 이 것을 확인하면서 특이 한점은 PVX와 HDX 8000 간에 서로 다른 코덱을 통해 음성과 영상을 전송한다는 것이 좀 특이했습니다. 그래서 표준을 뒤져보다가 귀차니즘이 발동해서 그만두었습니다. 어쨌든 일반적으로 같은 코덱으로 통신하는 것이구요 폴리콤의 경우에는 서로 다른 코덱으로 정보를 주고 받을 수 도 있다고 이해하시면 될 듯합니다.
