[펌] SIP, SDP

Microsoft 실시간 통신 : 프로토콜 및 기술 펀글(VoIP) 2007/07/19 09:00 http://blog.naver.com/neuroman_/30019984629

원문: http://korper.egloos.com/1312050

Microsoft 실시간 통신 : 프로토콜 및 기술

 

이 페이지의 내용 소개 RTC 호출 처리 SIP(Session Initiation Protocol) SDP(Session Description Protocol) 오디오와 비디오의 디지털화 및 압축 RTP 및 RTCP 음질 기술 SIMPLE(SIP Instant Messaging and Presence Language Extensions) 요약 관련 링크 저자 : 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 음성 통신을 중점적으로 살펴 봄으로써, 기본 기술을 사용하여 패킷 교환 네트워크에서 실시간 통신을 어떻게 실행하는지 설명합니다. 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 패킷 캡슐화에서 연결 계층 패킷 캡슐화에 이르는 캡슐화 과정을 보여 줍니다. 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 클릭하여 별도의 페이지에서 table시하십시오. 그림 1   실시간 통신 프로토콜 캡슐화 SIP(Session Initiation Protocol) 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 사용자 에이전트 클라이언트와 SIP 사용자 에이전트 서버 간의 중간 단계로 사용됩니다. 프록시 서버는 클라이언트와 서버 간의 통신 방향에 따라 SIP 사용자 에이전트 클라이언트나 SIP 사용자 에이전트 서버의 기능을 수행합니다. 프록시 서버는 SIP 요청을 전달하거나, SIP 요청을 전달하기 전에 수정할 수 있습니다. 레지스터 서버 사용자 에이전트의 IP 주소와 SIP 주소, 즉 URL(Uniform Resource Locator)을 포함하는 REGISTER 요청을 수신합니다. 이를 통해 레지스터 서버는 REGISTER 요청을 보낸 사용자 에이전트의 위치를 추적할 수 있습니다. 리디렉션 서버 호출 사용자 에이전트로부터 SIP 세션의 초기화를 SIP INVITE 요청의 형태로 수락하고, 호출된 사용자 에이전트의 올바른 SIP 주소를 검색하며, 해당 SIP 주소로 호출 사용자 에이전트에 응답합니다. 그런 다음 호출 사용자 에이전트는 해당 SIP 주소를 사용하여 호출된 사용자 에이전트와의 SIP 세션을 바로 시작합니다. SIP 서버(프록시, 레지스터 및 리디렉션)는 별도의 응용 프로그램으로 개발되거나, 모든 서버 기능을 결합하는 단일 응용 프로그램으로 개발될 수 있습니다. 레지스터 및 프록시 서버가 결합된 것을 종종 랑데부 서버라 합니다. SIP 사용자 에이전트 표 2 에는 두 가지 유형의 SIP 사용자 에이전트와 그 기능이 나열되어 있습니다. 표 2   SIP 사용자 에이전트 SIP 사용자 에이전트 기능 사용자 에이전트 클라이언트 SIP 요청을 시작합니다. 사용자 에이전트 서버 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 응답을 수신하여 대상 사용자 에이전트로 전달합니다. 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 클릭하여 별도의 페이지에서 table시하십시오. 그림 3   프록시 서버 SIP 호출 흐름 그림 4는 사용자 에이전트와 레지스터 서버 간의 일반적인 호출 흐름을 보여 줍니다. 레지스터 서버는 사용자 에이전트가 도달할 수 있는 주소를 나타내는 사용자 에이전트의 REGISTER 요청을 수락합니다. 레지스터 서버는 일반적으로 프록시 또는 리디렉션 서버와 함께 위치합니다. 그림 4   관리자 서버 SIP 호출 흐름 그림 5는 리디렉션 서버가 두 사용자 에이전트 사이에 있을 경우의 일반적인 호출 흐름을 보여 줍니다. 사용자 에이전트 A가 호출을 시작하기 위해 INVITE 요청을 보내면, 리디렉션 서버는 사용자 에이전트 B가 일시적으로 이동했음을 나타내는 이동됨 응답 코드(302)로 응답합니다. 이어서 사용자 에이전트 A는 리디렉션 서버의 응답 코드를 사용자 에이전트 A가 수신했음을 나타내는 ACK 요청으로 응답합니다. 그러면 사용자 에이전트 A는 사용자 에이전트 B의 새로 얻은 주소로 또 다른 INVITE 요청을 바로 보냅니다. 그림 5   리디렉션 서버 SIP 호출 흐름 샘플 SIP 아키텍처 그림  6은 샘플 SIP 아키텍처를 사용하여, SIP 구성 요소 간 통신이 처리되는 방법 및 SIP 구성 요소를 네트워크 환경에 맞추는 방법을 설명합니다. 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 클릭하여 별도의 페이지에서 table시하십시오. 그림 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 메시지 부분 정의 시작 줄 메시지가 요청인지 아니면 응답인지에 따라 콘텐트가 달라집니다. 요청 및 응답 시작 줄은 모두 SIP 버전을 포함합니다. 또한 요청 시작 줄은 메서드 유형과 요청을 수신하는 대상의 일반 URL 또는 SIP 주소를 포함하며 응답 시작 줄은 요청에 대한 응답을 정의하는 숫자 상태 코드와 응답구를 포함합니다. 헤더 헤더 유형과 관련 변수를 포함합니다. 메시지 본문 SDP(Session Description Protocol)에서 제공한 정보(예: SIP 세션의 미디어 기능에 대한 설명)를 포함합니다. SIP는 시작 줄과 헤더의 값을 정의하며 SDP(Session Description Protocol)는 메시지 본문 값을 정의합니다. SIP 메시지 시작 줄 표 4에 설명되어 있는 바와 같이 시작 줄 구문은 메시지가 요청인지 응답인지에 따라 달라집니다. 표 4   시작 줄 구문 시작 줄 구문 요청 메서드, 요청 URI, SIP 버전 응답 SIP 버전, 상태 코드, 응답구 요청 메서드 요청 시작 줄의 첫 번째 항목은 신호 명령인 SIP 메서드입니다. table 5에 나열된 SIP 메서드는 RFC 3261, 인터넷 초안 'SIP Extensions for Presence' 및 'SIP Extensions for Instant Messaging'에 정의되어 있습니다. 표 5   SIP 메서드 및 그 기능 SIP 메서드 기능 INVITE SIP 세션을 시작하기 위한 요청입니다. INVITE는 발신자로부터 수신자에게 보냅니다. ACK 수신자가 호출을 수락했습니다. ACK는 발신자로부터 수신자에게 보내집니다. OPTIONS 발신자가 수신자에게 자체 기능으로 응답할 것을 요청하고 있습니다. BYE 세션을 종료하기 위한 요청입니다. BYE는 발신자나 수신자가 보낼 수 있습니다. BYE를 수신하는 당사자가 BYE로 응답할 필요는 없습니다. CANCEL 일시 중지된 요청을 취소합니다. REGISTER 발신자가 현재 위치를 관리자 서버에 등록하기를 원합니다. SUBSCRIBE 발신자가 수신자의 상태 정보에 대한 업데이트를 요청합니다. NOTIFY 자신의 업데이트된 상태를 가입한 당사자 자체에 전달합니다. MESSAGE 인스턴트 메시지를 보내는 데 사용됩니다. 요청 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 URL 형식 설명 sip:user@reskit.com 기본 SIP URL입니다. sip:user@reskit.com;transport=TCP TCP의 전송 프로토콜 대상을 포함하는 기본 SIP URL입니다. 전송 프로토콜이 지정되지 않은 경우 기본값은 UDP입니다. sip:user@172.16.20.54 IP 주소를 포함하는 SIP URL입니다. sip:+1-425-707-9796@reskit.com;user=phone 국제 전화 번호를 포함하는 SIP URL입니다. sip:marketing@reskit.com;maddr=225.0.2.1;ttl=64 이전에 지정된 호스트 이름을 무시하는 멀티캐스트 주소를 포함하는 SIP URL입니다. TTL(Time-To-Live) 값은 64(0-255)로 설정됩니다. 멀티캐스트 주소와 UDP를 전송 프로토콜로 사용할 경우 TTL을 설정해야 합니다. 요청 또는 응답 버전 요청 시작 줄의 마지막 항목이자 응답 시작 줄의 첫 번째 항목은 SIP 버전(현재 2.0)입니다. Windows Messenger 세션에서 가져온 다음 샘플 SIP 요청 메시지는 일반적인 SIP 요청 줄을 보여 줍니다. 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 클릭하여 별도의 페이지에서 table시하십시오. 응답 상태 코드 상태 코드에는 정보, 성공, 리디렉션, 클라이언트 오류, 서버 오류 및 전역 실패의 6개 범주가 있습니다. table 7에 나온 것처럼 상태 코드의 맨 왼쪽 숫자는 코드의 범주를 나타냅니다. 표 7   SIP 응답 상태 코드 상태 코드 응답 범주 설명 1xx 정보 요청이 수신되었으며 처리 중입니다. 2xx 성공 요청된 작업을 성공적으로 이해 및 수락했습니다. 3xx 리디렉션 요청을 완료하기 위해 추가 작업이 필요합니다. 4xx 클라이언트 오류 요청에 잘못된 구문이 포함되어 있거나 서버에서 요청을 이행할 수 없습니다. 5xx 서버 오류 서버가 요청을 수신했지만 이를 처리할 수 없으며 다른 서버의 경우에는 요청을 처리할 수도 있습니다. 6xx 전역 실패 요청을 수신하는 서버에서 이를 처리할 수 없으며 다른 서버에서도 요청이 실패할 것입니다. 따라서 요청을 전달해서는 안 됩니다. 응답구 표 8에는 SIP 버전 2.0에 정의된 모든 SIP 응답 코드와 해당 범주 및 응답구가 나열되어 있습니다. 표 8   SIP 응답 상태 코드 및 응답구 상태 코드 응답 범주 응답구 100 정보 시도 중 180 정보 신호가 울림 181 정보 호출 전달 중 182 정보 대기 200 성공 확인 300 리디렉션 다중 선택 301 리디렉션 영구적으로 이동됨 302 리디렉션 임시로 이동됨 303 리디렉션 기타 참조 305 리디렉션 프록시 사용 380 리디렉션 대체 서비스 400 클라이언트 오류 잘못된 요청 401 클라이언트 오류 권한이 없음 402 클라이언트 오류 지불 필요 403 클라이언트 오류 사용할 수 없음 404 클라이언트 오류 없음 405 클라이언트 오류 메서드 허용 안 함 406 클라이언트 오류 받아들일 수 없음 407 클라이언트 오류 프록시 인증 필요 408 클라이언트 오류 요청 시간 초과 409 클라이언트 오류 충돌 410 클라이언트 오류 없음 411 클라이언트 오류 길이 필요 413 클라이언트 오류 요청 엔터티가 너무 큼 414 클라이언트 오류 요청 URI가 너무 김 415 클라이언트 오류 지원되지 않는 미디어 유형 420 클라이언트 오류 잘못된 확장 480 클라이언트 오류 일시적으로 사용할 수 없음 481 클라이언트 오류 호출 레그/트랜잭션 없음 482 클라이언트 오류 검색된 루프 483 클라이언트 오류 홉이 너무 많음 484 클라이언트 오류 주소가 완전하지 않음 485 클라이언트 오류 모호함 486 클라이언트 오류 여기에서 사용 중 500 서버 오류 서버 내부 오류 501 서버 오류 구현되지 않음 502 서버 오류 잘못된 게이트웨이 503 서버 오류 서비스 사용할 수 없음 504 서버 오류 게이트웨이 시간 초과 505 서버 오류 지원되지 않는 SIP 버전 600 전역 실패 모든 곳에서 사용 중 603 전역 실패 적용 안 함 604 전역 실패 어느 곳에도 없음 606 전역 실패 받아들일 수 없음 SIP 메시지 헤더 SIP 메시지의 시작 줄 다음에는 하나 이상의 헤더가 옵니다. 포함된 헤더는 메시지가 응답인지, 요청인지에 따라 다릅니다. 헤더는 RFC 3261, 'SIP: Session Initiation Protocol'에 정의되어 있습니다. (http://www.microsoft.com/windows/reskits/webresources/  의 웹 리소스 페이지   참조) 표 9에 나온 것처럼 헤더는 일반, 요청, 응답 및 엔터티의 네 가지 범주로 구분됩니다. 일반 범주의 헤더는 요청 및 응답 메시지 모두에 사용할 수 있습니다. 표 9   SIP 헤더 일반 요청 응답 엔터티 Accept Authorization Allow Content-encoding Accept-encoding Contact Proxy-authenticate Content-length Accept-language Hide Retry-after Content-type Call-ID Max-forwards Server   Contact Organization Unsupported   Cseq Priority Warning   Date Proxy-authorization WWW-authenticate   Encryption Proxy-require     Expires Route     From Require     Record-route Response-key     Time stamp Subject     To User-agent     Via       Windows Messenger 세션에서 가져온 다음의 샘플 SIP 요청에서는 SIP 헤더가 강조 table시되어 있습니다. 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 클릭하여 별도의 페이지에서 table시하십시오. SIP 메시지 본문은 SDP(Session Description Protocol)에 의해 정의됩니다. SDP(Session Description Protocol) SDP(Session Description Protocol)는 멀티미디어 회의를 알리고 설명하기 위한 IETF table준입니다. SIP 메시지 본문에는 SDP에 의해 정의된 바와 같이 세션 설명이 포함되어 있습니다. 세션 설명은 단일 세션 설명, 0개 이상의 시간 설명 및 0개 이상의 미디어 설명의 세 부분으로 구성됩니다. 세션 설명은 전체 회의나 모든 미디어 스트림에 적용되는 전역 특성을 포함하고, 시간 설명은 회의 시작, 중지 및 반복 시간 정보를 포함하며, 미디어 설명은 특정 미디어 스트림에 대한 세부 정보를 포함합니다. table 10에는 SDP 메시지의 각 부분에서 사용할 수 있는 SDP 유형과 관련 설명 값이 나열되어 있습니다. 표 10   SDP 설명 세션 시간 미디어 유형 값 유형 값 유형 값 v 프로토콜 버전 t 세션이 활성화되는 시간 m 미디어 이름 및 전송 주소 o 소유자/작성자 및 세션 식별자 r 0 이상의 반복 횟수 i 미디어 제목 s 세션 이름     c 연결 정보 i 세션 정보     b 대역폭 정보 u 설명 URI(Uniform Resource Identifier)     k 암호화 키 e 전자 메일 주소     a 0개 이상의 미디어 특성 줄 p 전화 번호         c 연결 정보         b 대역폭 정보         z table준 시간대 조정         a 0개 이상의 세션 특성 줄         Windows Messenger 세션에서 가져온 다음의 샘플 SIP 요청 메시지에서는 SIP 메시지 본문이 강조 table시되어 있습니다. 브라우저가 인라인 프레임을 지원하지 않을 경우, 여기를 클릭하여 별도의 페이지에서 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은 비디오 압축 및 압축 풀기에 어떻게 코덱이 사용되는지를 보여 줍니다. 브라우저가 인라인 프레임을 지원하지 않을 경우 여기를 클릭하여 별도의 페이지에서 table시하십시오. 그림 10   비디오 압축 및 압축 풀기 표 11에서 보는 바와 같이 Windows XP는 SIP 및 H.323 IP 전화 통신 응용 프로그램용 오디오 코덱을 모두 지원합니다. 표 11   Audio Codecs Supported by Windows XP 오디오 코덱 샘플링 속도 비트 전송률 프레임 크기 인코딩 알고리즘 DVI4 8 kHz 32 Kbs 20 ms ADPCM G.711 8 kHz 64 Kbs 20 ms PCM (MuLaw) (aLaw) G.722.1 (SIP에만 해당) 16 kHz 24 Kbs 20 ms 또는 40 ms MLT G.723.1 8 kHz 5.3 Kbs / 6.3 Kbs 30 ms, 60 ms, 또는 90 ms CELP GSM6.10 (SIP에만 해당) 8 kHz 13 Kbs 20 ms RPE-LTP SIREN (SIP에만 해당) 16 kHz 16 Kbs 20 ms 또는 40 ms MLT 표 12에서 보는 바와 같이 Windows XP는 SIP 및 H.323 IP 전화 통신 응용 프로그램용 비디오 코덱을 모두 지원합니다. 표 12   Windows XP에서 지원하는 비디오 코덱 코덱 비트 전송률 인코딩 알고리즘 H.261 64 kbs-256 Kbs DCT H.263 16 kbs-256 Kbs DCT 오디오 대역폭 용량 사용하는 코덱, 지원되는 양자화 및 압축 알고리즘에 의해 음성 및 비디오 데이터를 전송하는 데 필요한 대역폭이 결정됩니다. 예를 들어, 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 및 RTCP 데이터는 디지털화 및 압축을 통해 패킷 기반 네트워크를 통한 전송에 맞게 최적화 된 후, 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와 함께 사용할 필요가 없습니다. RTP RTP는 Windows Messenger 및 전화 걸기와 같은 실시간 응용 프로그램을 위한 종단 간 네트워크 전송 기능을 제공합니다. RTP에는 실시간 세션에 관한 정보가 포함되어 있으므로 응용 프로그램은 지터, 잘못된 패킷 순서 및 삭제된 패킷을 쉽게 조정할 수 있습니다. 대부분의 실시간 세션 관련 정보는 RTP 헤더에 포함됩니다. 그림 11은 RTP 패킷의 구조를 보여 줍니다. 그림 11   RTP 패킷 구조 버전 RTP의 버전을 식별합니다. Windows XP는 버전 2를 지원합니다. 패딩 1로 설정된 경우 하나 이상의 다른 패딩 옥텟이 페이로드의 끝에 추가되었음을 의미합니다. 패딩된 첫 번째 옥텟은 포함된 추가 옥텟의 개수를 나타냅니다. 확장 확장 비트가 설정된 경우 고정 RTP 헤더에 추가된 확장 헤더가 존재합니다. CSRC 개수 고정 RTP 헤더 뒤에 오는 CSRC(Contributing Source) 식별자의 수를 나열합니다. 마커 RTP 프로필에 따라 마커 비트의 정의 및 사용이 결정됩니다. 페이로드 유형 RTP 페이로드 유형을 정의합니다. 시퀀스 번호 초기 시퀀스 번호는 임의 값에서 시작하여 전송된 각 RTP 패킷에 대해 1씩 증가합니다. 실시간 응용 프로그램에서 이 값을 사용하여 패킷 손실을 확인하고 올바른 패킷 순서를 복원할 수 있습니다. 타임스탬프 타임스탬프 값은 RTP 패킷에서 첫 번째 옥텟의 샘플링 순간을 나타냅니다. 사용되는 샘플링 빈도는 데이터 유형에 따라 다릅니다. 예를 들어, Windows XP에서 G.711 음성 코덱을 사용할 경우 샘플링 빈도는 8kHz로 설정됩니다. SSRC(Synchronization Source) 무작위로 선택된 숫자로 시작되는 SSRC 값은 각 RTP 세션에 대해 RTP 스트림의 소스를 식별합니다. CSRC(Contributing source) CSRC 값은 RTP 세션에 기여한 여러 스트림의 소스를 나타내는데, RTP 세션에서 각 소스의 SSRC 값이 RTP 믹서에 의해 CSRC 값에 추가됩니다. RTCP RTCP 패킷에는 RTP 세션 품질과 세션에 참가하는 개인에 대한 정보가 포함되어 있습니다. 송신자와 수신자는 모두 RTCP 패킷을 RTP 세션의 각 참가자에게 정기적으로 전송합니다. 실시간 응용 프로그램은 이 정보를 사용하여 RTP 세션의 품질을 모니터링할 수 있습니다(예를 들어, 지터 및 패킷 손실 모니터링). 표 13에서 보는 바와 같이 RTCP 패킷에는 다섯 가지 유형이 있습니다. 표 13   패킷 유형 SR (Sender Report) RTP 세션의 품질에 대한 정보를 포함합니다. RR (Receiver Report) RTP 세션의 품질에 대한 정보를 포함합니다. SDES (Source Description) RTP 세션에 속한 각 참가자의 ID에 대한 정보를 포함합니다. BYE (Goodbye) RTP 세션에서 하나 이상의 소스가 더 이상 활성화 상태가 아님을 나타냅니다. APP (Application-defined) 새 응용 프로그램에서 실험적으로 사용됩니다. RTP 세션의 참가자는 RR 패킷 유형을 보내는데, 활성 송신자인 경우에는 SR 패킷 유형을 보냅니다. 그림 12에서 보는 바와 같이 RR 패킷은 헤더와 보고서 블록을 갖습니다. 보고서 블록은 각 소스에 대해 하나씩 존재합니다. RTCP RR 패킷 섹션 헤더 보고서 블록 1 보고서 블록…n 그림 12   패킷 구조 그림 13의 SR 패킷 구조는 20바이트의 송신자 정보 섹션을 포함한다는 점을 제외하고 RR 패킷과 형식이 동일합니다. RTCP SR 패킷 섹션 헤더 송신자 정보 보고서 블록 1 보고서 블록…n 그림 13   패킷 구조 수신자 보고서 및 송신자 보고서 헤더 구조 그림 14에는 RR 및 SR 헤더 구조가 나와 있습니다. 두 헤더간 유일한 차이점은 다른 패킷 유형 값을 갖는다는 것입니다. 그림 14   RTCP RR 및 SR 헤더 구조 버전 RTP의 버전을 식별합니다. Windows XP는 버전 2를 지원합니다. 패딩 1로 설정된 경우, 하나 이상의 다른 패딩 옥텟이 페이로드의 끝에 추가되었음을 의미합니다. 패딩된 첫 번째 옥텟은 포함된 추가 패딩 옥텟의 개수를 나타냅니다. 수신 보고서 개수(RC) RTCP 패킷에 포함된 수신 블록의 개수를 나타냅니다. 패킷 유형 RTCP 패킷 유형입니다. RR의 값은 201이고 SR의 값은 200입니다. 길이 1을 뺀 32비트 단어에 RTCP 패킷의 길이를 포함합니다. SSRC RTCP 패킷의 동기화 소스 식별자를 포함합니다. 그림 15는 SR 패킷에 포함된 20바이트의 추가 송신자 정보를 보여 줍니다. 그림 15   RTCP SR 정보 NTP 타임스탬프 NTP(Network Time Protocol) 타임스탬프나 절대 작업 수행 시간을 포함합니다. 작업 수행 시간을 사용할 수 없는 경우 송신자는 RTP 세션에 참가한 이후 경과된 시간을 NTP 타임스탬프 값에 사용할 수 있습니다. 경과된 시간을 사용할 경우 상위 비트가 0으로 설정됩니다. 작업 수행 시간과 경과된 시간을 모두 사용할 수 없는 경우 전체 NTP 타임스탬프 값이 0으로 설정됩니다. RTP 타임스탬프 RTP 타임스탬프는 RTP 패킷의 헤더에 포함된 타임스탬프와 동일한 단위로 제공되면서 동일한 임의 오프셋이 지정된다는 점을 제외하고 NTP 타임스탬프와 동일한 시간을 포함합니다. 송신자의 패킷 수 RTP 세션의 시작부터 해당 SR 패킷의 전송 시점까지 송신자가 보낸 총 RTP 패킷 수를 포함합니다. 어떠한 이유로든 송신자의 SSRC 값이 변경될 경우 이 값은 재설정됩니다. 송신자의 옥텟 수 RTP 세션의 시작부터 해당 SR 패킷의 전송 시점까지 송신자가 보낸 총 옥텟 수를 포함합니다. 어떠한 이유로든 송신자의 SSRC 값이 변경될 경우 이 값은 재설정됩니다. 보고서 블록 구조 SR 및 RR 패킷은 0개 이상의 보고서 블록을 포함할 수 있습니다. 수신자가 마지막 보고서를 받은 이후 수신된 RTP 데이터 패킷에 포함되어 있는 각 SSRC에 대해, 보고서 블록이 수신됩니다. 이 보고서 블록은 RTCP 헤더 바로 뒤에 추가됩니다. 그림 16에 보는 바와 같이 SR 및 RR 패킷은 동일한 보고서 블록 구조를 갖습니다. 그림 16   RTCP 보고서 블록 구조 SSRC_n RTCP 패킷에 포함된 각 보고서 블록의 동기화 소스 식별자를 포함합니다. 손실된 단편 마지막 SR 또는 PR 패킷이 보내진 이후 소스(SSRC_n)에서 손실된 RTP 패킷 단편을 포함합니다. 누적된 손실 패킷 수 세션이 시작된 이후 소스(SSRC_n)에서 손실된 총 패킷 수를 포함합니다. 이 값은 RTP 패킷에서 발견된 시퀀스 번호에서 파생됩니다(삭제된 RTP 패킷은 시퀀스 번호에서 공백으로 표시됨). 수신된 최상위 확장 시퀀스 번호 이 필드는 두 부분으로 구분됩니다. 하위 16비트는 소스(SSRC_n)에서 RTP 패킷으로 수신된 최상위 시퀀스 번호를 포함합니다. 상위 16비트는 시퀀스 번호 주기의 개수를 포함합니다. 도착 간 지터 RTP 패킷의 도착 간 시간에 대한 예상 편차를 포함합니다. 이 값은 RTP 타임스탬프 단위로 측정되며, 두 패킷에 대해 수신자와 송신자가 측정한 패킷 간격 간의 차이로부터 파생됩니다. Last SR Timestamp (LSR) 소스 SSRC_n의 최신 RTCP SR에서 얻은 64비트 NTP 타임스탬프의 중간 32비트를 포함합니다. Delay Since Last SR (DLSR) 소스 SSRC_n에서 마지막 SR 패킷을 수신한 시점과 해당 수신 보고서 블록을 보낸 시점 간의 시간 차이를 포함합니다. 여기에서 카운터의 각 틱은 1/65536초를 나타냅니다. 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(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을 지원함으로써 상태 및 인스턴트 메시징 기능을 제공합니다.