저자 : Ross Carter 개요 이 문서는 실시간 통신의 개념, 프로토콜 및 기술을 이해하고자 하는 IT 전문가와 개발자를 대상으로 하며, IETF(Internet Engineering Task Force) SIP(Session Initiation Protocol), SIMPLE(SIP Instant Messaging and Presence Language Extensions), RTP(Real-time Transport Protocol)와 같은 프로토콜에 대해 설명합니다. Microsoft는 이러한 프로토콜과 관련 기술을 사용하여, 음성 및 비디오 통신, 인스턴트 메시징, 응용 프로그램 공유, 그리고 공동 작업을 포함하는 기업의 다중 형태 통신을 위한 실시간 통신(RTC) 플랫폼을 제공합니다. 이 문서에서는 음성 통신과 Microsoft Windows XP 운영 체제에서 음성 통신을 지원하는 방식을 사용하여 기본 기술의 작동 방법에 대해 설명합니다.
Microsoft 실시간 통신 플랫폼은 업계 통신 table준을 지원하고자 하는 Microsoft의 노력에 기반 하여 제작되었습니다. Windows XP는 IETF(Internet Engineering Task Force) SIP(Session Initiation Protocol), SIMPLE(SIP Instant Messaging and Presence Language Extensions) 및 RTP(Real-time Transport Protocol)를 지원합니다. 이러한 프로토콜 및 관련 기술은 통신 형태(음성, 비디오 또는 인스턴트 메시징)에 상관 없이 패킷 교환 네트워크를 통한 실시간 통신의 특정 요구를 충족하도록 설계되었습니다. 이 문서에서는 회선 교환 음성 네트워크에서 사용되는 음성 통신 프로세스에 대해 간략하게 살펴 본 다음, RTC 음성 통신을 중점적으로 살펴 봄으로써, 기본 기술을 사용하여 패킷 교환 네트워크에서 실시간 통신을 어떻게 실행하는지 설명합니다.
특정 지점에서 다른 지점으로 실시간 통신을 전송하려면 여러 단계를 거쳐야 하며, 여기에는 다양한 프로토콜이 사용됩니다. 우선, 호출을 설정, 수정 그리고 종료하기 위한 몇 가지 유형의 신호 및 호출 제어가 필요합니다. 회선 교환 네트워크인 PSTN(Public Switched Telephone Network)에서는 SS7(Signaling System 7)을 사용하여 호출을 설정, 종료합니다. 패킷 기반 네트워크의 경우에는 SIP 및 H.323 프로토콜을 통해 호출을 제어합니다. SIP에 대한 자세한 내용은 문서 후반부의 SIP(Session Initiation Protocol)를 참조하십시오. H.323에 대한 자세한 내용은 'Microsoft Windows 2000 Server Resource Kit'의 'Windows 2000 Internetworking Guide'에서 전화 통신 통합 및 회의 를 참조하십시오. 호출 세션이 설정되면, 오디오 또는 비디오 입력을 샘플링하여 디지털 형식으로 변환해야 합니다. 그런 다음, 샘플링된 데이터를 RTP(Real-time Transport Protocol) 패킷으로 캡슐화 합니다. RTP는 특별히 패킷 기반 네트워크를 통한 실시간 통신 요구를 충족하도록 설계되었습니다. 이어서 RTP 패킷은 네트워크 전송 프로토콜(대부분의 경우 UDP(User Datagram Protocol))로 캡슐화 됩니다. TCP(Transmission Control Protocol)를 캡슐화에 사용할 수도 있지만, TCP는 보장된 전송 수준 프로토콜이므로 종종 TCP 패킷을 재전송하는 데 추가 시간을 필요로 하는데, 이는 전송 대기 시간(패킷의 송수신 간에 걸리는 시간)이 늘어나서 수신된 오디오를 알아들을 수 없음을 의미합니다. RTR 패킷을 전송하는 동안 RTP 세션의 품질을 모니터링하기 위해 RTCP(Real-time Control Protocol)가 사용됩니다. RTP 및 RTCP에 대한 자세한 내용은 문서 뒷부분의 'RTP 및 RTCP'를 참조하십시오. 다음으로, 네트워크 전송 프로토콜(UDP 또는 TCP)이 IP 패킷으로 캡슐화 되고, 다시 연결 계층 프로토콜(예: 이더넷)로 캡슐화 됩니다. 그런 다음 연결 계층 패킷은 대상 컴퓨터로 전송됩니다. 그림 1은 RTP 패킷 캡슐화에서 연결 계층 패킷 캡슐화에 이르는 캡슐화 과정을 보여 줍니다.
그림 1 실시간 통신 프로토콜 캡슐화
SIP(Session Initiation Protocol)는 텍스트 기반의 응용 프로그램 계층 신호 및 호출 제어 프로토콜로, HTTP(HyperText Transfer Protocol)와 유사합니다. SIP는 SIP 세션을 작성, 수정, 종료하는 데 사용되며, 유니캐스트 및 멀티캐스트 통신을 모두 지원합니다. SIP는 텍스트 기반이기 때문에 구현, 개발 및 디버깅이 H.323보다 간단합니다. 참고 Windows Messenger는 SIP 기반 응용 프로그램입니다. Windows XP는 TAPI(Telephony Application Programming Interface)를 통해 SIP를 지원하지 않습니다. Windows Messenger에 대한 자세한 내용은 Windows XP Professional 도움말 및 지원 센터의 'Windows Messenger 사용'과 'Microsoft Windows XP Professional Resource Kit 설명서의 '전화 통신 및 회의 구성' 을 참조하십시오. SIP 구성요소주요 SIP 환경 구성 요소는 두 가지 기본 범주인 SIP 서버와 SIP 사용자 에이전트로 구분됩니다. SIP 서버SIP 서버에는 프록시, 레지스터 및 리디렉션의 세 가지 유형이 있습니다. table 1에서와 같이 각 서버 유형은 다른 기능을 수행합니다. 서버가 수행하는 기능에 따라 처리되는 SIP 요청이 결정됩니다. 표 1 SIP 서버
SIP 서버(프록시, 레지스터 및 리디렉션)는 별도의 응용 프로그램으로 개발되거나, 모든 서버 기능을 결합하는 단일 응용 프로그램으로 개발될 수 있습니다. 레지스터 및 프록시 서버가 결합된 것을 종종 랑데부 서버라 합니다. SIP 사용자 에이전트표 2 에는 두 가지 유형의 SIP 사용자 에이전트와 그 기능이 나열되어 있습니다. 표 2 SIP 사용자 에이전트
각 사용자 에이전트는 SIP 주소와 연관됩니다. SIP 호출 흐름SIP 세션의 호출 흐름은 SIP 세션이 SIP 사용자 에이전트 간에 직접 설정되었는지 아니면 SIP 서버(프록시, 레지스터 또는 리디렉션)가 SIP 사용자 에이전트 사이에 있는지 여부에 따라 달라집니다. 그림 2는 두 사용자 에이전트 간의 일반적인 호출 흐름을 보여 주며 각 단계는 괄호로 되어 있습니다. 우선 사용자 에이전트 A는 호출을 시작하기 위해 INVITE 요청을 보냅니다. 그러면 사용자 에이전트 B는 호출 요청이 처리 중임을 나타내는 시도 중 응답 코드(100)로 응답합니다. 사용자 에이전트 B가 호출을 수락했음을 나타내는 확인 응답 코드(200)로 응답하면 사용자 에이전트 A는 사용자 에이전트 B의 최종 응답 코드를 사용자 에이전트 A가 수신했음을 나타내는 승인(ACK) 요청으로 사용자 에이전트 B에 응답합니다. 문서 뒷부분에 나오는 'RTP 및 RTCP'에서 설명하는 바와 같이, 실시간 데이터가 RTP 패킷으로 캡슐화 되어 사용자 에이전트 A와 B 사이에 전송되고 나면, 사용자 에이전트 A 또는 B는 사용자 에이전트가 세션을 종료하고자 함을 나타내는 BYE 요청을 보낼 수 있습니다. 그러면 사용자 에이전트 B는 요청 성공을 나타내는 확인 응답 코드(200)를 사용자 에이전트 A에게 보냅니다.
그림 2 사용자 에이전트 SIP 호출 흐름 그림 3은 두 사용자 에이전트 경로 사이에 프록시 서버가 있을 경우의 일반적인 호출 흐름을 보여 줍니다. 프록시 서버는 기본적으로 사용자 서버 및 사용자 에이전트의 기능을 모두 수행하는 통신 중간 지점으로 사용됩니다. 사용자 서버로 작동할 경우 프록시는 SIP 요청을 수신하여 대상 사용자 에이전트로 전달하고, 사용자 에이전트로 작동할 경우 SIP 응답을 수신하여 대상 사용자 에이전트로 전달합니다.
그림 3 프록시 서버 SIP 호출 흐름 그림 4는 사용자 에이전트와 레지스터 서버 간의 일반적인 호출 흐름을 보여 줍니다. 레지스터 서버는 사용자 에이전트가 도달할 수 있는 주소를 나타내는 사용자 에이전트의 REGISTER 요청을 수락합니다. 레지스터 서버는 일반적으로 프록시 또는 리디렉션 서버와 함께 위치합니다.
그림 4 관리자 서버 SIP 호출 흐름 그림 5는 리디렉션 서버가 두 사용자 에이전트 사이에 있을 경우의 일반적인 호출 흐름을 보여 줍니다. 사용자 에이전트 A가 호출을 시작하기 위해 INVITE 요청을 보내면, 리디렉션 서버는 사용자 에이전트 B가 일시적으로 이동했음을 나타내는 이동됨 응답 코드(302)로 응답합니다. 이어서 사용자 에이전트 A는 리디렉션 서버의 응답 코드를 사용자 에이전트 A가 수신했음을 나타내는 ACK 요청으로 응답합니다. 그러면 사용자 에이전트 A는 사용자 에이전트 B의 새로 얻은 주소로 또 다른 INVITE 요청을 바로 보냅니다.
그림 5 리디렉션 서버 SIP 호출 흐름 샘플 SIP 아키텍처그림 6은 샘플 SIP 아키텍처를 사용하여, SIP 구성 요소 간 통신이 처리되는 방법 및 SIP 구성 요소를 네트워크 환경에 맞추는 방법을 설명합니다.
그림 6 샘플 SIP 아키텍처 A. Datum Corporation은 회사 내 도메인 간에 SIP 요청을 전달하는 두 개의 SIP 프록시 서버를 가지고 있습니다. 방화벽에 연결된 SIP 프록시 서버는 회사 외부의 수신자에게 보내지는 모든 SIP 메시지와 회사 외부에서 내부의 수신자에게 보내지는 모든 메시지를 처리합니다. 예를 들어, A. Datum Corporation의 SIP 클라이언트에서 Fabrikam, Inc.의 SIP 클라이언트에게 전송되는 SIP INVITE 메시지는 Fabrikam, Inc.의 SIP 프록시 서버로 보내집니다. 그런 다음 SIP 프록시 서버는 SIP INVITE 요청을 Fabrikam, Inc.의 SIP 프록시 서버 도메인에 있는 대상 SIP 클라이언트 컴퓨터나 SIP IP 전화로 전달합니다. 예를 들어, Fabrikam, Inc.의 SIP 서버는 국제 전화 번호 형식으로 SIP URL과 함께 보내진 SIP INVITE 요청을 수신할 수 있습니다. 국제 전화 번호에 Fabrikam, Inc.의 SIP IP 전화 대상이 있을 경우 SIP INVITE 요청은 SIP IP 전화로 바로 전달됩니다. 반면, 국제 전화 번호에 아날로그 전화와 같은 SIP IP 전화 외의 대상이 있을 경우 SIP INVITE 요청은 PSTN에 맞게 SIP INVITE 요청의 서식을 지정하는 SIP/PSTN 게이트웨이로 전달됩니다. 회사의 PBX(Private Branch Exchange)는 국제 전화 번호를 사용하여 호출을 회사 내의 아날로그 전화로 라우팅할 것인지 아니면 회사 외부의 아날로그 전화용 PSTN으로 라우팅할 것인지를 결정합니다. SIP 프로토콜SIP 메시지는 RFC 822, 'Standard for the Format of ARPA Internet Text Messages'에 설명되어 있는 바와 같이 table준 인터넷 메시지 형식에 기초합니다. (http://www.microsoft.com/windows/reskits/webresources/ 의 웹 리소스 페이지 참조) SIP 메시지는 클라이언트에서 서버로 보내지는 요청이나 서버에서 클라이언트로 보내지는 응답입니다. 각 SIP 메시지는 표 3에서 보는 바와 같이 세 부분으로 구성됩니다. 표 3 SIP 메시지 부분
SIP는 시작 줄과 헤더의 값을 정의하며 SDP(Session Description Protocol)는 메시지 본문 값을 정의합니다. SIP 메시지 시작 줄표 4에 설명되어 있는 바와 같이 시작 줄 구문은 메시지가 요청인지 응답인지에 따라 달라집니다. 표 4 시작 줄 구문
요청 메서드요청 시작 줄의 첫 번째 항목은 신호 명령인 SIP 메서드입니다. table 5에 나열된 SIP 메서드는 RFC 3261, 인터넷 초안 'SIP Extensions for Presence' 및 'SIP Extensions for Instant Messaging'에 정의되어 있습니다. 표 5 SIP 메서드 및 그 기능
요청 URI요청 시작 줄의 두 번째 항목은 수신자 URL을 포함하는 요청 URI(Uniform Resource Identifier)입니다. 일반적으로 이 URI는 여러 형식 중 하나를 가질 수 있는 SIP URL입니다. table 6에는 지원되는 형식 중 일부가 나열되어 있습니다. 사용할 수 있는 SIP URL 형식과 구문의 전체 목록은 http://www.microsoft.com/windows/reskits/webresources/ 의 웹 리소스 페이지 에서 RFC 3261, 'SIP: Session Initiation Protocol'을 참조하십시오. 표 6 SIP 요청 URL 형식의 일부 목록
요청 또는 응답 버전요청 시작 줄의 마지막 항목이자 응답 시작 줄의 첫 번째 항목은 SIP 버전(현재 2.0)입니다. Windows Messenger 세션에서 가져온 다음 샘플 SIP 요청 메시지는 일반적인 SIP 요청 줄을 보여 줍니다.
응답 상태 코드 상태 코드에는 정보, 성공, 리디렉션, 클라이언트 오류, 서버 오류 및 전역 실패의 6개 범주가 있습니다. table 7에 나온 것처럼 상태 코드의 맨 왼쪽 숫자는 코드의 범주를 나타냅니다. 표 7 SIP 응답 상태 코드
응답구 표 8에는 SIP 버전 2.0에 정의된 모든 SIP 응답 코드와 해당 범주 및 응답구가 나열되어 있습니다. 표 8 SIP 응답 상태 코드 및 응답구
SIP 메시지 헤더SIP 메시지의 시작 줄 다음에는 하나 이상의 헤더가 옵니다. 포함된 헤더는 메시지가 응답인지, 요청인지에 따라 다릅니다. 헤더는 RFC 3261, 'SIP: Session Initiation Protocol'에 정의되어 있습니다. (http://www.microsoft.com/windows/reskits/webresources/ 의 웹 리소스 페이지 참조) 표 9에 나온 것처럼 헤더는 일반, 요청, 응답 및 엔터티의 네 가지 범주로 구분됩니다. 일반 범주의 헤더는 요청 및 응답 메시지 모두에 사용할 수 있습니다. 표 9 SIP 헤더
Windows Messenger 세션에서 가져온 다음의 샘플 SIP 요청에서는 SIP 헤더가 강조 table시되어 있습니다.
SIP 메시지 본문은 SDP(Session Description Protocol)에 의해 정의됩니다.
SDP(Session Description Protocol)는 멀티미디어 회의를 알리고 설명하기 위한 IETF table준입니다. SIP 메시지 본문에는 SDP에 의해 정의된 바와 같이 세션 설명이 포함되어 있습니다. 세션 설명은 단일 세션 설명, 0개 이상의 시간 설명 및 0개 이상의 미디어 설명의 세 부분으로 구성됩니다. 세션 설명은 전체 회의나 모든 미디어 스트림에 적용되는 전역 특성을 포함하고, 시간 설명은 회의 시작, 중지 및 반복 시간 정보를 포함하며, 미디어 설명은 특정 미디어 스트림에 대한 세부 정보를 포함합니다. table 10에는 SDP 메시지의 각 부분에서 사용할 수 있는 SDP 유형과 관련 설명 값이 나열되어 있습니다. 표 10 SDP 설명
Windows Messenger 세션에서 가져온 다음의 샘플 SIP 요청 메시지에서는 SIP 메시지 본문이 강조 table시되어 있습니다.
SIP로 호출이 설정된 후에는 데이터를 디지털화하고 압축해야 합니다. 아날로그 형식의 오디오 및 비디오 데이터를 패킷 기반 네트워크를 통해 유선으로 전송하려면 아날로그 파형을 디지털 값으로 변환해야 합니다. 데이터가 디지털 형식이 되면, 소프트웨어 기반 코덱(코더 및 디코더)을 사용하여 데이터를 압축합니다. 이렇게 하면 네트워크 이용률과 음질을 향상할 수 있습니다. 오디오 디지털화오디오 신호는 여러 단계를 거쳐 디지털 형식으로 변환됩니다. 우선, 그림 7에서와 같이 오디오 입력을 나타내는 파형이 일정한 간격으로 샘플링됩니다.
그림 7 주기적 파형 샘플링 샘플링 속도(샘플을 수집하는 빈도)는 샘플링하려는 오디오 미디어의 유형과 사용되는 코텍 및 관련 코딩 알고리즘에 따라 달라집니다. 예를 들어, 복합 PCM(Pulse Code Modulation) 코딩 알고리즘을 사용하는 PSTN은 8kHz의 음성 샘플링 속도를 갖습니다(여기에서 Hz는 초당 1사이클에 해당). 샘플링 속도는 다음과 같은 Nyquist 기준을 통해 계산됩니다. Fs > 2×BWFs = sampling frequencyBW = bandwidth of input analog voice signal Nyquist 기준은 샘플링되는 최대 주기를 나타내는 수의 두 배 이상으로 샘플링이 발생해야 한다고 규정합니다. 거의 모든 아날로그 음성 신호가 4kHz의 대역폭 범위 내에 들어가기 때문에, 샘플링 속도 8kHz은 대부분의 음성 통신에 대해 충분할 것으로 간주됩니다. 데이터 샘플링의 다음 단계는 각 파형 샘플링이 속하는 간격을 식별하는 것입니다. 그림 8이 보여 주는 이 프로세스를 양자화라고 부릅니다.
그림 8 양자화 데이터가 샘플링 및 양자화 되면, 전송을 위해 각 샘플에 8비트 코드 단어가 할당되며 각각의 8비트 코드 단어는 네트워크를 통해 전송됩니다. 그림 9는 그림 8에 나온 양자화의 처음 세 개 샘플이 전송되는 모습을 보여 줍니다..
그림 9 디지털 신호 전송 따라서 PSTN SCN(Switched Circuit Network)을 통한 아날로그 전송(음성 또는 데이터)에 필요한 64Kbps 대역폭(8kHz x 샘플 당 8비트)이 파생됩니다. 오디오 및 비디오 압축오디오 및 비디오 코덱은 알고리즘을 사용해서 디지털화된 오디오/비디오 신호를 압축한 후 전송하고, 수신 컴퓨터에서 압축을 푼 다음 재생합니다. 코덱을 사용한 압축 및 압축 풀기는 네트워크 대역폭 이용률을 줄여주고 네트워크 트래픽 로드를 최소화합니다. 아날로그에서 디지털 형태로, 디지털에서 다시 아날로그 형태로 변환하는 작업은 하드웨어에서 수행됩니다. 예를 들어, 원본 필터에서 수신되는 시점의 데이터는 디지털화 되었지만 덜 압축된 형식을 가집니다. 그림 10은 비디오 압축 및 압축 풀기에 어떻게 코덱이 사용되는지를 보여 줍니다.
그림 10 비디오 압축 및 압축 풀기 표 11에서 보는 바와 같이 Windows XP는 SIP 및 H.323 IP 전화 통신 응용 프로그램용 오디오 코덱을 모두 지원합니다. 표 11 Audio Codecs Supported by Windows XP
표 12에서 보는 바와 같이 Windows XP는 SIP 및 H.323 IP 전화 통신 응용 프로그램용 비디오 코덱을 모두 지원합니다. 표 12 Windows XP에서 지원하는 비디오 코덱
오디오 대역폭 용량사용하는 코덱, 지원되는 양자화 및 압축 알고리즘에 의해 음성 및 비디오 데이터를 전송하는 데 필요한 대역폭이 결정됩니다. 예를 들어, PSTN을 사용하는 아날로그 음성 호출의 경우에는 64Kbs의 대역폭이 필요한데, 이 대역폭은 고품질의 음성 및 데이터를 제공하는 복합 PCM과 함께 사용되는 압축 알고리즘 및 인코딩에 의해 결정된 것입니다. IP 전화 통신을 사용함으로써 얻을 수 있는 여러 가지 이점 중 하나는 최신 코덱 기술을 활용할 수 있다는 것입니다. 위에서 언급한 바와 같이 PSTN을 통한 단일 음성 호출에는 64Kbs의 비트 전송률이 사용됩니다. CELP(Code Excited Linear Predictive) 인코딩 알고리즘을 사용하는 G.723.1 코덱을 사용하면, 패킷 교환 네트워크에서 약 10개의 음성 호출이 동일한 비트 전송률을 가질 수 있습니다. 이 외에도, IP 전화 통신은 8비트 PSTN 코덱보다 품질이 우수하고 PSTN 호출보다 적은 대역폭을 필요로 하는 코덱(예: 16kHz 코덱)을 제공합니다. 참고 16kHz 샘플링 속도를 사용할 경우 네트워크 요구 사항이 128Kbps로 증가합니다. 그러나 오디오 코덱 및 네트워크 토폴로지 기술 향상으로 인해, 많은 비용을 들이지 않고도 IP 네트워크에서 16kHz 샘플링 속도를 사용할 수 있습니다.
데이터는 디지털화 및 압축을 통해 패킷 기반 네트워크를 통한 전송에 맞게 최적화 된 후, RTP 내에서 캡슐화 됩니다. RTP는 실시간 전송 프로토콜이며 RTCP는 RTP 세션을 모니터링하는데 사용되는 제어 프로토콜입니다. RFC 1889, 'RTP: A Transport Protocol for Real-time Communications'에 정의된 RTP와 RTCP는 패킷 기반 네트워크를 통한 실시간 통신 요구를 충족하도록 IETF에 의해 특별히 설계되었습니다. RTP와 RTCP에 대한 자세한 내용은http://www.microsoft.com/windows/reskits/webresources/ 의 웹 리소스 페이지 에서 RFC 1889를 참조하십시오. SIP와 H.323은 RTP를 사용하여 호출에 참가하는 여러 당사자들 간에 디지털화 된 오디오 및 비디오 데이터를 전송합니다. 각 RTP 패킷은 하나 이상의 미디어 페이로드와 기타 관련 정보(예: 타임스탬프 및 시퀀스 번호)를 포함합니다. 일반적으로 RTP와 RTCP는 UDP와 함께 기본 전송 계층으로 사용되고, IP와 함께 기본 네트워크 계층으로 사용됩니다. RTP는 특정 미디어 스트림의 송신자와 수신자 간에 협상된 동적 UDP 포트를 사용합니다. 그러나 RTP와 RTCP는 기본 전송 및 네트워크 계층과 무관하며, 전송 및 네트워크 프로토콜로서 UDP 및 IP와 함께 사용할 필요가 없습니다. RTPRTP는 Windows Messenger 및 전화 걸기와 같은 실시간 응용 프로그램을 위한 종단 간 네트워크 전송 기능을 제공합니다. RTP에는 실시간 세션에 관한 정보가 포함되어 있으므로 응용 프로그램은 지터, 잘못된 패킷 순서 및 삭제된 패킷을 쉽게 조정할 수 있습니다. 대부분의 실시간 세션 관련 정보는 RTP 헤더에 포함됩니다. 그림 11은 RTP 패킷의 구조를 보여 줍니다.
그림 11 RTP 패킷 구조
RTCPRTCP 패킷에는 RTP 세션 품질과 세션에 참가하는 개인에 대한 정보가 포함되어 있습니다. 송신자와 수신자는 모두 RTCP 패킷을 RTP 세션의 각 참가자에게 정기적으로 전송합니다. 실시간 응용 프로그램은 이 정보를 사용하여 RTP 세션의 품질을 모니터링할 수 있습니다(예를 들어, 지터 및 패킷 손실 모니터링). 표 13에서 보는 바와 같이 RTCP 패킷에는 다섯 가지 유형이 있습니다. 표 13 패킷 유형
RTP 세션의 참가자는 RR 패킷 유형을 보내는데, 활성 송신자인 경우에는 SR 패킷 유형을 보냅니다. 그림 12에서 보는 바와 같이 RR 패킷은 헤더와 보고서 블록을 갖습니다. 보고서 블록은 각 소스에 대해 하나씩 존재합니다.
그림 12 패킷 구조 그림 13의 SR 패킷 구조는 20바이트의 송신자 정보 섹션을 포함한다는 점을 제외하고 RR 패킷과 형식이 동일합니다.
그림 13 패킷 구조 수신자 보고서 및 송신자 보고서 헤더 구조 그림 14에는 RR 및 SR 헤더 구조가 나와 있습니다. 두 헤더간 유일한 차이점은 다른 패킷 유형 값을 갖는다는 것입니다.
그림 14 RTCP RR 및 SR 헤더 구조
그림 15는 SR 패킷에 포함된 20바이트의 추가 송신자 정보를 보여 줍니다.
그림 15 RTCP SR 정보
보고서 블록 구조 SR 및 RR 패킷은 0개 이상의 보고서 블록을 포함할 수 있습니다. 수신자가 마지막 보고서를 받은 이후 수신된 RTP 데이터 패킷에 포함되어 있는 각 SSRC에 대해, 보고서 블록이 수신됩니다. 이 보고서 블록은 RTCP 헤더 바로 뒤에 추가됩니다. 그림 16에 보는 바와 같이 SR 및 RR 패킷은 동일한 보고서 블록 구조를 갖습니다.
그림 16 RTCP 보고서 블록 구조
RTP와 RTCP는 패킷 기반 네트워크를 통한 실시간 통신 요구를 충족하도록 특별히 설계되었으나, 서비스 품질 메커니즘을 제공하지는 않습니다. 그 대신 RTP및 RTCP와 관련된 서비스 품질 문제는 기본 네트워크 및 데이터 링크 계층에서 고려됩니다.
PSTN과 같은 회선 교환 네트워크는 두개의 최종 스테이션 사이에 전용 통신 경로를 제공합니다. 데이터그램 기반의 패킷 교환 네트워크는 원래 데이터를 여러 패킷으로 세그먼트화하며 이러한 패킷은 네트워크를 통해 개별적으로 라우팅됩니다. 기본적으로 데이터그램 기반의 패킷 교환 네트워크에는 전용 경로나 대역폭이 존재하지 않습니다. 이러한 차이점과 실시간 통신의 낮은 대기 시간으로 인해, 패킷 교환 네트워크에서 톨 품질(toll-quality) 음성 전송을 얻으려면 다음과 같은 문제를 먼저 해결해야 합니다.
Windows XP는 지터 제어, 음향 반향 제거 및 서비스 품질(QoS) 프로토콜을 비롯한 여러 서비스 품질 메커니즘을 제공합니다. 지터 제어RTP 및 RTCP는 실시간 통신 응용 프로그램이 세션 도중 지터를 보정하는 데 사용할 수 있는 타임스탬프, 도착 간 지터 값 등의 정보를 제공합니다. 응용 프로그램의 지터 버퍼는 타임스탬프 및 도착 간 지터 값을 사용하여 부드럽고 일관된 흐름의 패킷이 수신되도록 조정을 수행합니다. 응용 프로그램은 RTP와 RTCP 패킷에서 수신된 정보를 사용하여 두 패킷의 전송 시간 간 차이를 계산합니다. 계산 방법은 다음과 같습니다. D(n,n-1)=[R(n)-S(n)]-[R(n-1)-S(n-1)] 여기에서 D(n,n-1)은 패킷 n과 n-1의 전송 시간 간 차이이고, S는 패킷(n,n-1)이 송신된 시간을, R은 패킷(n,n-1)이 수신된 시간을 나타냅니다. 그런 다음, 전송 시간 간 차이인 D(n,n-1)이 RFC 1889, 'RTP: A Transport Protocol for Real-Time Communications'에서 설명하는 바와 같이, 부드럽게 실행되는 RTP 세션의 값으로서 도착 간 패킷 지터 J(n)을 결정하기 위해 다음 수식에서 사용됩니다. J(n)=J(n-1)+(|D(n,n-1)|- J(n-1))/16 자세한 내용은 http://www.microsoft.com/windows/reskits/webresources/ 의 웹 리소스 페이지 에서 RFC 1889를 참조하십시오. 참고 Windows Messenger와 전화 걸기의 경우 지터 버퍼가 기본으로 제공됩니다. 음향 반향 제거기컴퓨터가 음성 호출 같은 실시간 통신에 사용될 경우 호출 참가자는 음향 반향을 경험할 수 있습니다. 통합 마이크와 스피커가 있는 헤드셋을 사용하면 별개의 마이크와 스피커를 사용할 때와 달리 음향 반향을 일부 제거할 수 있습니다. 음향 반향을 보다 잘 제어하려면 음향 반향 제거기(AEC)가 필요합니다. 참고 Windows XP는 Windows Messenger 클라이언트 및 Windows TAPI 버전 3.1 모두에서 AEC를 지원합니다. 서비스 품질RTP 및 RTCP 프로토콜, 지터 제어 메커니즘 및 음향 반향 제거기는 실시간 통신의 품질을 모니터링 및 개선하기 위한 정보와 도구를 응용 프로그램에 제공합니다. 그러나 이러한 프로토콜이나 기술은 기본 네트워킹 환경을 제어하지 않습니다. Diff-Serv(Differentiated Services) 및 802.1p 같은 IETF 정의 프로토콜이 결합된 QoS는 기본 네트워킹 환경을 통해 여러 가지 수준의 제어를 제공하고 다양한 등급의 서비스 품질을 제공하는 데 사용됩니다. 참고 Windows XP는 Windows XP QoS API를 호출하기 위해 특별히 작성된 QoS를 사용하는 모든 응용 프로그램을 지원합니다. 음질 측정MOS(Mean Opinion Score) 등급은 음질을 주관적으로 측정 및 평가하기 위한 도구를 제공합니다. MOS 등급의 범위는 1에서 5까지이며, 1은 가장 낮은 품질을 5는 최상의 품질을 나타냅니다. 톨 품질(toll-quality)이라고도 부르는 PSTN의 음질은 일반적으로 MOS 등급의 4 ~ 5 범위 사이에 존재합니다. SIREN 및 G.722.1과 같이 16kHz 샘플링 속도를 가진 오디오 코덱의 MOS 등급은 약 4이지만, 코덱에 서로 다른 샘플링 속도가 사용되기 때문에 사용자 경험에는 차이가 있을 수 있으므로, MOS 등급에서 얻은 값을 비교하는 것은 바람직하지 않습니다. 이러한 코덱은 광범위한 주파수를 캡처하기 때문에 실제로 보다 자연스러운 사운드를 렌더링함으로써 더 매력적인 사용자 경험을 제공합니다. 이제 패킷 기반 IP 네트워크를 통한 음성 전송은 PSTN 네트워크를 통한 음성 전송보다 뛰어난 품질의 사운드를 제공할 수 있습니다. 참고 패킷 교환 네트워크를 통한 음성 전송에서는 대기 시간이 200ms 미만인 경우에만 톨 품질(toll-quality)을 얻을 수 있습니다. 그러나 대기 시간이 200 ~ 400ms 사이인 경우에도 전송은 허용되며, 대기 시간이 400ms를 초과할 경우에는 오디오 연결이 더 이상 허용되지 않습니다. 그림 17은 8kHz 샘플링 속도를 사용하는 Windows XP에서 지원되는 오디오 코덱의 MOS 등급을 보여 줍니다.
그림 17 Windows XP 8kHz 샘플링 속도 오디오 코덱 MOS 등급
SIMPLE(SIP Instant Messaging and Presence Language Extensions)를 사용하면 인스턴트 실시간 메시지(일반적으로 텍스트 메시지)를 송수신하고 다른 사용자의 현재 가용성이나 상태를 확인할 수 있습니다. SIMPLE의 일반 모델은 http://www.microsoft.com/windows/reskits/webresources/ 의 웹 리소스 페이지 에 있는 RFC 2778, 'A Model for Presence and Instant Messaging'에 설명되어 있습니다. RFC 2778에 설명되어 있는 인스턴트 메시징 모델은 Instant Message Service로 정의된 서버와 Sender 또는 Instant Inbox로 정의된 클라이언트 간의 통신을 정의합니다. 그림 18에서와 같이 Sender 클라이언트로부터 Instant Message Service로 메시지가 보내지면 Instant Message Service는 해당 메시지를 Instant Inbox 클라이언트로 전달합니다.
그림 18 인스턴트 메시지 통신 흐름 RFC 2778은 교환 및 통신에 관련된 개체를 정의하지만 상태 및 인스턴트 메시징 정보를 통신하는 데 사용되는 프로토콜은 지정하지 않습니다. RFC 2778에 설명된 상태 모델은 Presence Service로 정의된 서버와 Presentity 또는 Watcher로 정의된 클라이언트 간의 통신을 정의합니다. Presentity는 상태 정보를 Presence Service에 제공하고 Watcher는 Presence Service로부터 상태 정보를 받습니다. Watcher 클라이언트에는 Fetcher와 Subscriber, 두 가지 유형이 있습니다. Fetcher는 Presence Service로부터 Presentity의 상태 정보에 대한 현재 값만 요청합니다. Subscriber는 Presentity의 상태 정보가 변경될 때마다 업데이트를 요청합니다. 그림 19는 상태 클라이언트 간 관계를 보여 줍니다.
그림 19 상태 클라이언트 SIP는 몇 가지 상태 정보를 제공합니다. 예를 들어, SIP 사용자 에이전트가 SIP 관리자 서버에 등록되면 SIP 사용자 에이전트의 상태 또는 위치를 SIP 관리자 서버에서 얻을 수 있습니다. 이와 같은 상태 인식 수준으로 인해 SIP 기반의 호출 설정은 가능하나, SIP 사용자 에이전트는 다른 SIP 사용자 에이전트에 가입하여 상태 정보를 얻을 수 없습니다. 상태 및 인스턴트 메시징 기능을 SIP에 제공하기 위해 두 개의 추가 인터넷 초안인 'SIP Extensions for Presence' 및 'SIP Extensions for Instant Messaging'이 작성되었습니다. 'SIP Extensions for Presence' 초안에는 SIP 프로토콜에서 상태 기능을 제공하는 SUBSCRIBE 및 NOTIFY라는 새로운 SIP 메서드 두 개가 정의되어 있고, 'SIP Extensions for Instant Messaging' 초안에는 SIP 프로토콜에서 인스턴트 메시징 기능을 허용하는 MESSAGE라는 새 SIP 메서드가 정의되어 있습니다. SIP 메서드에 대한 자세한 내용은 문서의 앞부분의 'SIP 프로토콜'을 참조하십시오.
Microsoft 실시간 통신 플랫폼은 업계 표준에 기초하며 음성 및 비디오 통신, 인스턴트 메시징, 응용 프로그램 공유, 공동 작업 등과 같은 기업의 다중 형태 통신에 맞게 설계되었습니다. Windows XP는 호출 세션의 작성과 종료에 사용되는 SIP, 음성 및 비디오 신호를 디지털 형식으로 변환하고 신호의 효율적인 전송을 위해 압축/압축 해제를 실행하는 코덱, 멀티미디어 세션을 설명하는 SDP, 그리고 통신 세션을 모니터링하는 RTP 및 RTCP를 지원합니다. Windows XP에는 패킷 교환 네트워크를 통한 음성 통신의 품질을 향상하기 위한 여러 가지 음질 기술이 포함되어 있습니다. 이 외에도 Windows XP는 SIMPLE을 지원함으로써 상태 및 인스턴트 메시징 기능을 제공합니다. |
Microsoft 실시간 통신 : 프로토콜 및 기술 펀글(VoIP)
2007/07/19 09:00 |
원문: http://korper.egloos.com/1312050
Microsoft 실시간 통신 : 프로토콜 및 기술
'내밥줄 > VoIP' 카테고리의 다른 글
[펌][Installation] Asterisk 서버 구성 (0) | 2009.01.23 |
---|---|
[스크랩] 4. IP-PBX 기능과 역할 (0) | 2009.01.13 |
[펌] asterisk를 통한 외부통화 (0) | 2009.01.12 |
[펌] asterisk를 이용한 내선통화 (0) | 2009.01.12 |
[펌] Asterisk 설치 (0) | 2009.01.12 |