통신 및 공동 작업

OCS 2007의 강력한 음성 기능

Rajesh Ramanathan

한 눈에 보기:

• OCS 2007에서 전화 걸기
• 보안 통화
• OCS의 다중 모드 대화
• 음성 메일 지원을 위한 Exchange UM과의 통합

목차

기본 음성 통화
전화 번호 사용
보안 통화
NAT 및 방화벽 트래버스
전화 번호 라우팅
인바운드 라우팅
품질 보고 및 문제 해결
전체 과정
다중 모드 동작 및 대화
음성 메일
맺음말

이 시리즈의 첫 번째 부분에서는 Microsoft Office Communication Server(OCS)가 Live Communication Server(LCS) 2005의 강점을 바탕으로

기업 수준의 인스턴트 메시징(IM), 상태 표시 기능, 그리고 고급 미디어 및 전화 기능을 제공하기 위해 어떻게 설계되었는지 설명하였습니다(TechNet Magazine 2008년 2월호 참조 - technet.microsoft.com/magazine/cc194409).이번에는 이전 내용에 이어서 VoIP 측면을 자세히 설명하려고 합니다.OCS 시스템에서 음성 통화가 얼마나 간단히 이루어지는지 설명하고, 이러한 기술에 대해 차례대로 논의하는 방식으로 각각의 구성 요소를 해당 기능에 따라 추가적으로 설명합니다.

이전 기사에서 밝혔듯이 OCS는 다음과 같은 다양한 구성으로 사용자에게 전화 통신을 제공합니다.

Enterprise Voice PBX 없이 Microsoft® Mediation 서버와 함께 OCS를 사용하는 완전한 통합 통신 솔루션입니다.이 시스템에서는 Exchange UM(통합 메시징)을 사용하여 음성 메일 기능을 제공합니다.이 글에서는 이 서비스를 사용하는 사용자를 "UC 사용자"라고 하고,이 구성을 사용하는 클라이언트를 "UC 끝점"이라고 하겠습니다.

PBX와 통합된 Enterprise Voice 이 구성에서 사용자는 기존 PBX 전화를 그대로 사용하면서 통합 통신의 혜택을 누릴 수 있습니다.OCS와 PBX의 병렬 설치가 가능하므로 Office Communicator와 PBX 끝점에서 동시에 전화를 받을 수 있습니다.PBX는 여전히 통화 라우팅을 담당하고 음성 메일 서비스도 제공합니다.

원격 통화 제어 이 기능은 PBX 전화를 기본 전화로 사용하며 Office Communicator 클라이언트를 통해 전화를 제어할 수 있습니다.

기본 음성 통화

여기서는 Enterprise Voice 사용자의 입장에 초점을 맞추어 설명하겠습니다.OCS 시스템에서는 RFC 3261에 기술된 SIP INVITE 방식을 사용하여 간단한 음성 통화를 설정합니다.OCS 서버는 클라이언트(또는 끝점) 사이에 메시지를 중계하는 전자 메일 관리자와 비슷한 프록시 역할을 담당합니다.통화나 인스턴트 메시징 세션 등의 실시간 세션이 생성될 때마다 새로운 SIP INVITE가 클라이언트에서 발생합니다.INVITE가 응답과 함께 승인되면(원격 끝점에서 200 OK 응답을 보내면), 통화가 연결됩니다(그림 1 참조).

그림 1 INVITE 형식과 200 OK

INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**

그림 2에서, Alice가 Office Communicator(OC) 2007에서 Communicator 통화를 선택하여 Bob에게 전화를 걸면 OC 2007은 Bob의 SIP URI(Uniform Resource Identifier) sip:bob@example.com으로 INVITE를 보냅니다.이 INVITE에는 Alice가 음성을 수신할 수 있는 미디어 끝점에 대한 오디오 세션 설명자인 SDP(Session Description Protocol)가 들어 있습니다.OCS는 INVITE를 Bob에게 등록된 여러 SIP 끝점(예: Communicator Phone Edition 및 Communicator 데스크톱)으로 나누어 보냅니다.INVITE에는 sip:alice@example.com이라는 From 헤더가 포함되어 있으며, Bob의 클라이언트 끝점은 RNL(역방향 이름 조회)에서 이 정보를 사용하여 이름 Alice를 찾고 수신 전화 알림에 표시합니다.

그림 2 여러 끝점에 통화 라우팅(크게 보려면 이미지 클릭)

각 끝점에는 Globally Routable User Agent URI(GRUU)가 표시됩니다.SIP 끝점은 GRUU를 통해 고유하게 식별되며, 이것은 OCS 서버에 등록할 때 부여됩니다.GRUU 주소는 SIP 메시지 라우팅에 사용됩니다. 끝점이 응답하고 나면 통화 중간의 다른 작업을 위한 이후의 SIP 신호는 끝점 간에 GRUU 주소를 사용하여 직접 전달할 수 있습니다.

그림 3은 Bob이 Communicator 데스크톱에서 응답한 경우의 프로세스를 보여 줍니다.Bob의 OC에서 200 OK 메시지가 전송되어 어디서 음성을 수신할 수 있는지 알립니다.OCS 프록시가 한 끝점의 응답을 감지하면 즉시 다른 Communicator Phone Edition 끝점으로의 통화를 취소합니다.200 OK 응답이 Alice의 Communicator 끝점에 도달하면 두 끝점은 미디어를 시작하기 위한 충분한 정보(IP 포트, 암호화 매개 변수 등)를 갖게 됩니다.

그림 3 한 쪽 끝점에서 응답할 경우(크게 보려면 이미지 클릭)

전화 번호 사용

지금까지 사용자가 Communicator 통화를 클릭하여 초대를 만드는 경우를 살펴보았습니다.사용자가 전화 번호를 선택하거나 직접 입력하는 경우에는 처리 과정이 다음과 같이 약간 달라집니다.

• 우선 클라이언트는 전화 번호를 정규화하여 TEL URI로 표현합니다. 이는 전화 번호로 식별되는 리소스를 기술하는 방법으로서 RFC 3966에 지정되어 있습니다.
• OCS 서버가 SIP URI만 인식할 수 있기 때문에, 클라이언트는 TEL URI에 도메인 접미사와 user=phone 태그를 추가하여 SIP URI로 변환합니다.
• 내부 사용자 번호인 경우 OCS가 직접 초대를 보내고외부 번호인 경우에는 가까운 SIP-PSTN 게이트웨이로 초대를 보냅니다.

PSTN(공중 전화망)의 번호로 전화를 걸 때 상대방의 안내 멘트를 듣거나 연결을 위해 숫자를 더 입력해야 하는 경우와 같이 응답을 받기 전에 미디어 경로가 설정되어야 하는 경우가 있습니다.이런 경우에는 PSTN 게이트웨이가 음성 SDP와 함께 183 세션 진행률 표시기를 전송합니다.Communicator는 이 정보를 사용하여 상대방이 전화에 응답하기 전에 대상 끝점과 양방향 미디어 경로를 설정합니다.

초기 미디어 경로가 모두 설정되고 나면 Communicator에서 Dual-Tone Multi-Frequency 또는 DTMF(전화기 신호음) 키패드를 사용할 수 있게 되어 원격 시스템에서 요구하는 추가적인 숫자를 사용자가 입력할 수 있습니다.입력된 DTMF 숫자는 미디어 경로를 통해 RFC 2833 패킷으로 전송되고,PSTN 게이트웨이는 PSTN 쪽에서 해당 DTMF 신호음을 생성합니다.

Bob이 휴대 전화에 동시 신호 울림을 설정한 경우 OCS 프록시는 전화를 게이트웨이와 Bob의 다른 Communicator 끝점에 동시에 보냅니다.이런 경우 OCS 프록시는 183 세션 진행 상태 응답에서 여러 개의 통화 경로가 있음을 나타내며, 이에 따라 Communicator에서 PSTN 게이트웨이를 사용하는 수신 전용 미디어 채널을 설정하게 됩니다.

보안 통화

미디어는 기본적으로 RFC3711에 정의된 SRTP(Secure Real-Time Transport Protocol)로 암호화되며, 이것은 OC에 설정된 음성 통화의 주요 기능 중 하나입니다.SRTP는 RTP 트래픽에 기밀성, 메시지 인증 및 재생 보호 기능을 제공합니다.통화 설정 과정에서 클라이언트 간에 보안 협상이 이루어지며 INVITE 메커니즘의 일부로 암호화 키가 교환됩니다.

OC의 기본 암호화 설정은 "선택적"이며 OC 끝점 사이에 암호화된 미디어 채널을 설정할 수 있습니다.이 설정은 관리자가 조직의 규정 준수 요구 사항에 맞게 조정할 수 있습니다.예를 들어, 모든 통화가 암호화되도록 설정할 수도 있고 암호화를 전혀 사용하지 않을 수도 있습니다.

NAT 및 방화벽 트래버스

OCS 시스템의 클라이언트는 ICE(Interactive Connectivity Establishment) 기술을 사용하여 기존 NAT(Network Address Translation) 구성 요소를 변경하지 않고 NAT 장치 및 방화벽 안쪽에 있는 사용자에게 미디어를 연결할 수 있습니다.ICE 기술은 현재 IETF(Internet Engineering Task Force)에서 표준화를 진행하고 있습니다.각각의 클라이언트는 대역 내 프로비전 메커니즘을 통해 서비스를 제공하는 A/V(오디오/비디오) 에지 서버를 인식하며 로그인하는 동안 A/V 에지 서버와의 인증된 연결을 유지합니다.

클라이언트는 전화를 걸기 전에 A/V 에지 서버(미디어 중계용), NAT, 또는 호스트 클라이언트 자체의 가능한 연결 지점(주소 및 포트, 후보라고도 함)에 리소스를 할당합니다.SIP(Session Initiation Protocol) INVITE를 전송할 때 이 연결 정보도 그 일부로 전송됩니다.마찬가지로 200 OK 응답을 통해 피어의 후보 정보가 전달됩니다.각 끝점에 피어 후보 목록이 전달되면 세심한 순위 지정 및 점검 과정을 통해 두 피어 사이에 미디어를 성공적으로 전송할 수 있는 최적의 경로를 선택하게 됩니다.

전화 번호 라우팅

전화 번호 라우팅은 다음과 같은 요소로 인해 기본 전화 메커니즘을 복잡하게 만듭니다.

• 단축 다이얼을 위해 내부적으로 사용하는 다이얼 플랜이 조직마다 서로 다를 수 있습니다.
• 전화 번호가 비표준 형식으로 저장될 수 있습니다(예: Microsoft Office Outlook®에서 7자리 번호를 저장할 수 있음).
• 외부 전화 번호마다 다른 정책이 적용될 수 있습니다.예를 들어 특정 사용자에게 국제 전화가 금지될 수 있습니다.

OCS 시스템에서 전화 번호 라우팅이 올바르게 동작하려면 전화 번호가 RFC 3966 TEL URI 형식이어야 합니다.이 형식이 아닌 번호는 클라이언트가 INVITE를 실행하기 전에 변환됩니다.그림 4는 OCS 시스템에서 이러한 변환이 어떻게 일어나는지 보여 줍니다.

그림 4 전화 번호 라우팅(크게 보려면 이미지 클릭)

클라이언트에서 사용 가능한 전화 번호는 다양한 출처에서 제공됩니다.미리 정규화된 번호의 출처는 번호를 정규화된 E.164 형식으로 변환할 때 사용하는 관리자가 지정한 정규화 규칙을 가지고 있는 주소록 서비스(ABS)입니다.클라이언트가 SIP INVITE를 정규화된 번호로 보내면 OCS는 내부 사용자와 일치하는 번호가 있는지 알아보기 위해 변환 프로세스를 적용합니다.

• 1단계는 시스템에 들어오는 번호가 고유하거나(정규화되고 E.164 번호 형식을 따름) 위치를 식별하는 전화 컨텍스트가 있는지 보여 줍니다.이러한 번호는 SIP INVITE의 일부로 서버에 전송됩니다.OCS는 이 INVITE를 변환 프로세스로 라우팅합니다.
• 변환 프로세스(2단계)에서는 서버 쪽 RNL을 사용하여 전화 번호를 UC 끝점에 매핑하려고 시도합니다.변환 프로세스에서 해당 번호에 대한 경로는 아웃바운드 라우팅이나 UC 사용자로 식별되고, 번호가 올바르게 변환될 수 없는 경우 4xx 코드와 함께 통화가 실패하게 됩니다.
• 변환된 번호가 UC 사용자가 아니거나 외부 번호인 경우 아웃바운드 라우팅 구성 요소로 전송되며, 번호에 발신자와 관련된 정책을 적용한 후에 INVITE를 적절한 SIP-PSTN 게이트웨이로 재지정합니다(3A단계).아웃바운드 라우팅은 게이트웨이 간의 통화 부하를 분산하며 장애 발생 시 필요한 경우 대체 게이트웨이로 전환하는 역할을 합니다.아웃바운드 라우팅 프로세스는 실패할 수 있으며 또는 특정 번호에 대해 액세스가 금지될 경우 통화 거부를 일으키며 SIP 403 응답 코드를 반환할 수 있습니다.아웃바운드 라우팅은 발신자가 UC 사용자인 경우만 적용됩니다.그렇지 않은 경우 OCS는 해당 URI에 대해 설정된 고정 경로를 사용하여 게이트웨이에 접근을 시도합니다.
• 변환된 전화 번호가 UC 사용자 번호인 경우 INVITE는 해당 사용자의 SIP URI로 전송됩니다(3B단계).인바운드 라우팅은 UC 사용자와 SIP URI가 목적지인 통화에만 적용되는 OCS의 기능입니다.앞으로 자세히 살펴보겠지만 인바운드 라우팅에는 UC 사용자에 대해 벨 울림 시간 제한, 착신 전환 및 음성 메일 전달 규칙이 적용됩니다.

정규화 과정을 거친 번호는 클라이언트의 위치에 따라 달라질 수 있습니다.관리자는 위치 프로필을 구성하고 특정 위치에 맞는 번호 변환 규칙을 지정할 수 있습니다(예: 해당 지역에서 네 자리 다이얼이 작동하는 방식).각 UC 사용자에게는 지정된 위치 프로필이 있으며 시스템의 모든 클라이언트는 각자의 위치 프로필에 맞는 규칙을 대역 내 프로비전을 사용하여 다운로드합니다.다음으로는 인바운드 라우팅에 대해 자세히 알아 보겠습니다.

인바운드 라우팅

인바운드 라우팅 규칙은 시스템에 등록된 클라이언트가 있거나 없을 때 통화를 사용자에게 전달하는 방법을 지정합니다.인바운드 라우팅은 수신 전화에 대해 사용자의 현재 상태에 따라 다른 규칙을 적용합니다. 예를 들어 사용자가 현재 상태를 방해 금지로 설정했다면 수신 전화를 음성 메일로 보냅니다.인바운드 라우팅은 현재 상태 컨테이너 수준을 알고 있고 차단된 컨테이너에 있는 사용자의 전화를 자동으로 거부합니다.그림 5는 OCS 인바운드 라우팅 구성 요소에서 지원하는 선택 사항을 요약해서 보여 줍니다.

그림 5 인바운드 라우팅 기능

인바운드 라우팅 규칙은 XML 스키마이며 사용자의 자체 프로비전 정보의 일부로 서버에 업로드됩니다.그림 6은 인바운드 라우팅의 작동 방식을 보여 줍니다.OCS 시스템에서 사용자에게 걸려오는 전화는 사용자에게 전달되는 것이 기본값입니다("나"로 표시됨).벨 울림 횟수 안에 전화를 받지 않으면, 기본적으로 응답하지 않은 전화가 음성 메일로 보내집니다.사용자는 기본 구성을 수정하여 직접 다른 번호, 다른 사람 또는 음성 메일로 즉시 착신이 전환되도록 선택할 수 있습니다.

그림 6 통화 라우팅(작업 시간 내)(크게 보려면 이미지 클릭)

다른 사람이나 번호로 즉시 착신 전환된 전화는 해당하는 사람이나 번호의 인바운드 라우팅 규칙에 따라 처리됩니다.또한 사용자는 응답하지 않은 전화를 다른 번호나 사람으로 전환하도록 설정할 수 있습니다.

사용자가 착신 전환 규칙에서 Outlook 작업 시간에만 적용 옵션을 선택한 경우 그림 6에 있는 규칙은 작업 시간에만 적용되며, 그 외의 시간에는 등록된 끝점에 전화를 걸 때의 기본 동작이 적용됩니다.이러한 동작을 위해서는 Microsoft Exchange Server 2007과 Outlook 2007 클라이언트가 조직에 배포되어 있어야 합니다. Communicator는 작업 시간 정보를 Exchange 2007 가용성 웹 서비스에서 얻으며 이 서버의 위치를 얻기 위해 Outlook 2007 자동 검색 지원을 활용하기 때문입니다.

품질 보고 및 문제 해결

OCS 2007 시스템의 클라이언트는 차세대 오디오 코덱인 RTAudio를 사용하므로 지터, 패킷 손실 등과 같은 불완전한 네트워크 조건을 허용할 수 있지만, 관리자가 잠재적인 문제점을 발견하고 수정할 수 있도록 모니터링은 여전히 필요합니다.OCS 2007 시스템의 클라이언트는 모든 통화의 품질을 보고하고, 매 통화가 끝날 때마다 대역폭, 손실, 지터, 평균 평가점(사용자가 느끼는 기준), 사용된 장치 등을 포함하는 자세한 통계를 중앙 QoE(체감 품질) 서버에 제공합니다.이 과정은 SIP SERVICE 요청 페이로드를 QoE 서버에 전송하여 이루어지며, 서버의 주소는 대역 내 프로비전 메커니즘을 통해 설정됩니다.

모든 클라이언트 끝점은 통화 품질에 대해 독립적으로 QoE 서버에 보고합니다.신호에 오류가 생겨 통화가 실패하면 클라이언트는 OCS에도 보고하며, 이러한 OCS는 클라이언트에서 발생한 모든 오류에 대한 리포지토리를 제공합니다.

전체 과정

지금까지 번호 입력, 인바운드 및 아웃바운드 라우팅, 연결 확인을 포함하여 통화를 설정하는 여러 측면을 살펴보았습니다. 이제 전체 프로세스를 설명하겠습니다.그림 7은 사용자가 전화를 거는 과정을 시간 순서대로 요약해서 보여 줍니다.OCS 시스템의 클라이언트는 통화 설정에서 중요한 역할을 하며 통화 설정 과정 전체를 관리합니다.OCS는 통화의 초기 라우팅에 관여하며 에지 서버는 최적의 미디어 경로를 찾도록 도와줍니다.다음으로, 대화에 대해 살펴보겠습니다.

그림 7 종단 간 통화 흐름(크게 보려면 이미지 클릭)

다중 모드 동작 및 대화

대화는 OCS 시스템에서 중심 개념입니다.대화는 다수의 사람들 사이에 형성된 다중 모드 세션으로서 음성, 비디오, IM이 동시에 포함될 수 있으며 세션 중의 파일 전송, Outlook 전자 우편, Microsoft Office OneNote®에 저장된 메모 등도 포함될 수 있습니다.

OCS 클라이언트 시스템의 설계에 영향을 줄 수 있는 요인으로 다음과 같은 대화의 측면이 있습니다.

• 대화에 관련된 모든 형식은 같은 창을 사용합니다.인스턴트 메시지가 음성 대화에 추가되는 경우 같은 창에 연결됩니다.
• 대화는 장치를 넘나들며 발생할 수 있습니다.예를 들면 사용자는 Communicator Phone Edition에서 음성을 선택하고 IM은 Communicator 데스크톱에서 선택할 수 있습니다.
• 모든 모드는 하나의 전화 회의로 에스컬레이션됩니다.에스컬레이션이 발생하면 해당 형식이 현재 적용 중인 장치에 상관없이 대화의 모든 형식은 함께 에스컬레이션되어야 합니다.예를 들어, Communicator Phone Edition에서 음성 모드를 사용할 수 있고 동일한 대화의 IM 모드를 Communicator 데스크톱에서 사용할 수 있는 경우, 전화 회의로 에스컬레이션되면 음성과 IM 모두 해당 대화와 동일한 참가자를 개입시키게 됩니다.
• 개별 세션에는 해당하지 않지만 대화는 로그가 기록됩니다.통화 로그에는 대화 중에 작성된 메모, 교환된 인스턴스 메시지, 음성의 길이 등을 포함하여 대화에 대한 세부 정보가 포함됩니다.사용자가 Outlook에서 통화 로그를 열어보면 전체 대화와 관련하여 유용한 통합 정보를 얻을 수 있습니다.
• 대화 로그에 이어서 대화를 진행할 수 있습니다.OCS 클라이언트는 장치와 응용 프로그램에서 대화를 고유하게 식별할 수 있는 번호인 대화 ID를 사용하여 대화를 서로 묶습니다.이전의 대화 기록 로그에서 새로운 대화가 시작되면 대화 사이의 차이를 계산하는 복잡한 메커니즘이 사용됩니다.또한 동일한 대화 ID가 Outlook의 전자 메일 ID로 저장됩니다.

대화 ID는 SIP INVITE에 있는 사용자 지정 속성인 Ms-Conversation-Id의 일부로서 전달됩니다.그림 8은 음성이 추가되고, 그 다음에 IM이 추가될 때 트랜잭션을 보여 줍니다.다중 모드 대화가 종료될 때 Outlook에 저장되는 기록 로그도 동일한 대화 ID를 갖게 됩니다.

그림 8 다중 모드 대화와 대화 ID(크게 보려면 이미지 클릭)

Exchange UM은 OCS 2007의 음성 메일 시스템입니다.OCS는 UC를 사용하는 전화만 Exchange UM으로 라우팅합니다.OCS는 Exchange UM과의 통합을 위해 다음과 같은 다양한 기능을 제공합니다.

• Communicator의 전화 UI (그림 9 참조)에 있는 음성 메일 호출 옵션을 사용하면 UM 사서함 관리 및 인사말 변경과 같은 작업을 할 수 있으며, 사용자가 이미 인증되었기 때문에 PIN을 입력할 필요가 없습니다.
• Communicator UI(그림 10 참조)에 있는 메시지 대기 표시기를 통해 사용자가 Outlook에서 음성 메일 폴더를 열 수 있습니다. 반면 Communicator Phone Edition에서는 사용자가 전화에서 직접 음성 메시지를 재생합니다.
• Communicator UI를 통해 전화를 음성 메일로 전달할 수 있습니다.
• 통화를 거부하면 자동으로 음성 메일로 연결됩니다.
• Outlook에 있는 음성 메일 항목에서 전화에서 재생을 선택하면 Office Communicator 클라이언트에서 직접 들을 수 있습니다.

그림 9 Communicator의 음성 메일 호출 옵션

그림 10 Communicator의 메시지 대기 표시기

OC에서 음성 메일 알림이 수신되는 방식은 Communicator Phone Edition과 다릅니다.OC는 Outlook에 있는 음성 메일 검색 폴더에 새로운 메일 알림을 등록하고 이 폴더에 새 메시지가 있음을 알립니다.또한 Communicator는 부재 중 대화 및 통화 로그도 사용합니다.

맺음말

OCS 2007의 음성 통화는 몇 가지 RFC를 활용하는 SIP에 기반을 둔 시스템이며 지금까지 그 동작 방식에 대해 살펴보았습니다.OCS에서 클라이언트 끝점은 통화를 관리하는 중심 역할을 담당합니다.모든 음성 통화는 기본적으로 안전하게 암호화됩니다.OCS는 전화 번호를 조작하고 시스템상에서 전화 번호의 흐름을 관리하는 유연한 구성 요소를 제공합니다.

대화는 OCS의 중심 개념으로서 음성, IM, 비디오를 포함합니다.OCS는 Exchange UM과 통합되며, 이를 통해 Communicator 끝점에서 음성 메일에 대한 알림을 수신할 수 있고 Outlook을 통해 음성 메일에 액세스하거나 서버에서 직접 액세스할 수 있습니다.

Rajesh Ramanathan은 통신 분야에서 14년간 일해왔으며 Office Communicator 2007의 음성 프로토콜, 사용자 환경, 음성 및 회의 기능을 설계했습니다.현재 Microsoft에서 Office Communicator 팀의 수석 프로그램 관리자로 재직 중입니다.문의 사항이 있으면 rajeshra@microsoft.com으로 연락하시기 바랍니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC.All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다.