이번글에서는 H.323 프로토콜을 기반으로 영상 통화에 대한 패킷을 분석해 보겠습니다. 여담으로 말씀드리면 제가 절반정도 작성을 한 상태에서 저장을 하지 않아 지금 다시 작성하고 있습니다. 그러나, 다시 힘을 내서 적어보도록 하겠습니다. 기억이 가물 가물합니다.
우선 이글을 이해하기 위해서는 H.323 기본 Call Flow에 대한 이해를 전제로 합니다. 제가 언제 H.323 및 SIP 프로토콜에 대해 다룰 예정이었습니다만 차일 피일 미루다 보니 아직 블로그에 올리지 못했습니다. 다음에 기회에 글을 올리도록 하겠습니다. 우선 간단하게 기본 호 프로시져에 대해서만 살펴보겠습니다. 아래그림을 보시면, H.323 프로토콜은 호 시그널링 처리를 위한 H.225 와 Capability Negotiation을 수행하는 H.245로 이루어져 있는 것을 알 수 있습니다. 간단하게는 "VoIP 일반"이라는 블로그를 참조하시면 좀 더 쉽게 이해가 가실 것입니다.
아래 그림은 테스트 구성도 입니다. Path Navigator는 Gatekeeper로 이해하시면 됩니다. HDX 9002는 HD급 영상회의를 지원하는 화상회의용 코덱장비입니다.
H.323 Call Flow에 대해 살펴보겠습니다. Ethereal의 호 분석 기능을 이용하여 캡쳐한 것입니다.
아래그림에서 보시면 보시면 212번 HDX 9004 코덱 앞에서 패킷 캡쳐를 수행하였기에 230 HDX 9002 코덱의 정보가 표시되지 못한 면이 있지만, Path Navigator가 기본적으로 패킷 릴레이를 하므로 분석하는 데는 문제가 없을 듯합니다. 또한, Gatekeeper가 있음에도 H.225 RAS 메세지가 보이지 않는 것은 212번 HDX 9004 코덱은 등록되어 있지 않기 때문입니다. 즉, 230번 HDX 9004 코덱은 Path Navigator에 등록되어 있지만, 212번 HDX 9004 코덱은 등록되어 있지않으므로, 실제는 호 발신이 212번에서 이루어지면 최초 호는 release되고 Path Navigator로 호가 재연결되는 과정을 거칩니다.
위 그림에서 보듯이 HDX 두 코덱간에 직접 호가 여결되다가 facility 메세지를 보내고서 Release를 수행합니다. 이는 230번 코덱이 GateKeeper에 등록되어 있기 때문이며, Facility 메세지에 포함된 정보를 확인하도록 하겠습니다.
facility 메세지의 내용 alternativeAddress 에 의해 Setup 메세지를 다시 보낼것을 요구하는 것이며, Reason code에 보시면, "route call to gatekeeper"라는 메세가 있으며, IP address는 172.21.6.45임을 확인할 수가 있습니다. 따라서 Release Compelte 메세지가 전송되어 1차 호를 종료한 후 다음 그림에서 보시는 것처럼 Setup 메세지는 Path Navigator로 전송됩니다.
위의 Call Flow가 분명하지 않아서, H225 및 H245 부분만을 패킷 캡처한 부분을 같이 보겠습니다.
앞서 언급했듯이 230번 코덱에 대해 패킷이 없는 부분은 제가 패킷 캡쳐를 못한 부분이 있으므로 양해부탁드립니다. 그러나 실제 패킷 분석에는 영향이 없을 것입니다. 기본적으로, Slow Start로 진행되므로 Connect 메세지 이후에 H.245 채널을 통해 TCS (Termincal Capability Set) 과 MSD (Master Slave Determination)이 발신측에서 전송되고, 수신측에서도 자신의 TCS 및 MSD를 전송합니다. TCS에 있는 내용을 한 번 살펴보겠습니다. Capability Set의 아이템에 아래와 같이 영상과 음성 등 다양한 부분에 대한 협상을 시도합니다. Item 0~3까지가 일반 제어, Item 4 ~ 19까지가 음성, Item 20 ~28까지가 영상, Item 29 ~31까지가 송수신 데이타 등입니다. 이런 부분에 대해 하나하나 협상을 하므로, 상당한 오버헤드가 걸리는 것이 H.323의 단점이기도 합니다.
양쪽 모두 33개의 아이템이 Sequence Number 1에 다 포함되어 전송됩니다. TCS Ack 메세지를 살펴보겠습니다.
두 코덱 모두 Sequence Number 1을 선택한 것을 알수 있습니다. 모두 가능하다는 의미입니다.
MSD 부분을 분리해서 살펴보면, 다음과 같습니다. 212번과 230번이 보낸 MSD 메세지입니다.
각각의 MSD Ack 메세지를 확인해 보겠습니다. 212번 코덱 송신측이 Master가 되고 45번 Path Navigator를 통해 들어온 230번 코덱은 Slave가 되어 결정되었음을 확인할 수 있습니다.
이렇게 TCS 및 MSD가 처리가 되면 OLC(Open Logical Channel)이 열리게 됩니다. 212번 코덱은 두개의 OLC를 제안합니다. 하나는 음성 하나는 영상입니다. 가장 상위에 있는 TCS 아이템이 선택되어 OLC가 개방됩니다 OLC의 내용을 살펴보겠습니다.
RTP 연결시 사용할 자신의 IP address, Port, RTP Payload Type 값을 확인할 수 가 있습니다.
영상에 대해서도 마찬가지로 RTP 연결시 IP address, Port, RTP Payload Type 값을 확인할 수 가 있습니다.
개방되는 채널은 음성, 영상, 데이타, 제어, 영상확장에 대한 OLC가 모두 설정됩니다. 실제 통신시에는 H.263으로 영상이 Siren14를 통해 음성이 개방되었습니다 .여기서는 RTP Payload Type이 unknown으로 나오는 군요. 제가 가지고 있는 Ethereal이 해석하지 못하는 듯합니다.
실제 RTP를 통해 영상및 음성을 상호교환한후 마지막 즈음에 212번 코덱이 H.245에 의해 endsessionCommand를 보냅니다. 이 것은 호를 종료하기 위한 프로세스이며, 이것을 보낸후 바로 H.225 ReleaseComplete 메세지를 보내 호를 마무리합니다. 이 부분은 일반적인 프로세스이므로 분석하지 않겠습니다.
이렇게 하여 전체적으로 H.323으로 영상회의시에 호 분석에 대해 살펴보았습니다. 이런 기본적인 프로세스를 알고 있다면, 추후 트러블슈팅이나 상호호환성 테스트시에 많은 도움이 되리라 생각됩니다. 너무 기술적인 내용이긴 하지만, 필요한 것이기도 합니다.
