OCS R2 Outside Voice Control – Teil 2: Im Detail

11 Aug 2009

von Jan Boguslawski

11. August 2009, 07:05 Uhr Kurzlink und Zitatlink einblenden

Kategorie: Lync Translate with Google Translate

Translate EN

Zuletzt aktualisiert: 19. August 2009

Wie im voran gegangenen Beitrag “OCS R2 Outside Voice Control – Teil 1: Einführung” angekündigt, beleuchte ich nun den technischen Background der neuen OCS R2 Funktion.

Anhand der Bilder aus Teil 1 lässt sich bereits erahnen, wie der Verbindungsaufbau, bei einem Anruf „über den Arbeitsplatz…“ zustande kommt. Welche Netzwerk-Komponenten und Server-Rollen involviert sind, habe ich in dieser Grafik skizziert:

Der Communicator Mobile R2 ist via Edge Server am Standard / Enterprise Edition Server registriert. Nach der Registrierung erhält er durch das sogenannte Inband-Provisioning alle für ihn relevanten Informationen (bspw. meine Kontaktliste). Dazu zählt u.a. das Location Profile. Damit kann auch der mobile Communicator alle gewählten Nummern in das E.164 Format umwandeln und sie damit korrekt an OCS übereichen.

„Kurz gefasst“ erfolgt der Rufaufbau bei „Über Arbeitsplatz anrufen…“ technisch wie folgt:

In SIP übermittelt der Communicator Mobile seine Service-Anforderung via Edge Server an die Outside Voice Control Applikation. Diese ist auf dem OCS Standard bzw. Enterprise Frontend Server installiert, genauer ist sie als eine der On-Top Applikationen in der neuen Unified Communications Application Server Rolle (UCAS) verankert. Die Applikation ID lautet hier microsoft.rtc.applications.ccs wobei das ccs für die ursprüngliche Bezeichnung Call Control Server steht.
Die Outside Voice Control Applikation findet in der SIP Anforderung die in Communicator Mobile hinterlegte Nummer und die Nummer des eigentlichen Ziels. Daraufhin fordert sie zunächst den OCS R2 Mediation Server auf einen Ruf über das Festnetz zur konfigurierten Nummer zu tätigen.
Wird der Anruf des Mediation Servers am Handy durch den Communicator Mobile Nutzer angenommen, informiert er den Call Control Server (CCS) darüber. Erst dann übermittelt der CCS dem Mediation Server die Nummer des eigentlichen Ziels.
Mediation Server führt nun den zweiten Ruf aus. Dabei übergibt er als Quell-Nummer die Festnetz-Arbeitsplatznummer an das VoIP-Gateway. Wird dieser Anruf angenommen, „legt“ der Mediation Server beide Leitungen zusammen. Statt jedoch eine Audio-Konferenz MCU (Multipoint Control Unit) zu nutzen, relayed er lediglich den AudioStream. Das spart Ressourcen und vermeidet Einbußen in der Sprachqualität.

Zwei Anmerkungen:

Hier wird auch eine Limitierung von Outside Voice Control deutlich: Jeder so getätigte Ruf der als Ziel eine externe Nummer hat, belegt zwei Leitungen auf dem ISDN Anschluss.
Zwischen Mediation Server und VoIP Gateway (3a.) wird im Normalfall die SIP Kommunikation ohne TLS Verschlüsselung erfolgen. Ebenso wird der Audiostream unverschlüsselt und per UDP übertragen. Daher sollte dieser Netzwerkabschnitt speziell vor Abhörmöglichkeiten geschützt werden. Einige Gateway-Hersteller unterstützen mittlerweile auch SIP/TLS zum Mediation Server. Vermutlich wird zukünftig auch eine SRTP Verschlüsselung des Audiostreams hinzu kommen.

Um das Zusammenspiel von Communicator Mobile R2 und den drei OCS-Rollen (Edge, CCS, Mediation) genauer zu untersuchen, lohnt sich ein Blick in die SIP-Protokoll-Logs an diesen Servern. Dazu ist das sogenannte Snooper Tool ein hervorragendes Analyse-Werkzeug. Snooper kann im Rahmen des OCS R2 Ressource Kits auf alle OCS R2 Rollen installiert werden. Etwas English-Kenntnisse vorausgesetzt lassen sich damit, die vom standardmäßig installierten OCS R2 Logging Tool erfassten SIP-Traces beinahe im „Klartext“ lesen. Dies gilt übrigens nicht für die Inhalte von Chats. Bei allen Instant Messaging SIP-Nachrichten wird der Message Body nicht erfasst. Einige Auszüge der Logs erläutere ich genauer:

Die Spurensuche beginnt im Snooper Tool am Edge Server. Hier findet man durch Filtern nach microsoft.rtc.applications.ccs den vom Communicator Mobile abgesetzten SIP-INVITE an den Call Control Server.

Nebenbei ist unter User-Agent die Version des Communicator Mobile zu finden und auf welchem Pocket-PC Modell dieser läuft.

Nach zwei Diagnostic Einträgen: „Routed a request using signed route headers“ und „The message has an internally supported domain“ übergibt der Edge Server den INVITE an den internen CCS. Durch ein ACK (acknowledge) bestätigt der CCS seine Bereitschaft. Dieses wird via Edge Server dem Communicator Mobile zugestellt. Erst jetzt sendet COMO das SIP-INFO Packet mit den gewünschten Nummern.

Message-Body: <?xml version=“1.0″?>

<request requestId=“2″ protocolVersion=“1″ from=“sip:jan.boguslawski@itacs.de“ to=“sip:jan.boguslawski@itacs.de“><startConversation><conversation-info xmlns=“http://schemas.microsoft.com/rtc/2008/12/conversationinfo“ entity=“{98A78AA7-50C9-941E-18A0-A8BCCD73584B}“><conversation-description><conversation-id>Acngj+vuByc+xRm4MAEiHgMGdTIMAg==</conversation-id><importance>normal</importance></conversation-description><user entity=“sip:jan.boguslawski@itacs.de“><associated-aors xmlns=“urn:ietf:params:xml:ns:conference-info“><entry><uri>tel:+493039978418</uri><purpose>preferred-identity</purpose></entry></associated-aors><endpoint xmlns=“urn:ietf:params:xml:ns:conference-info“ entity=“e11062224″ xmlns:msci=“http://schemas.microsoft.com/rtc/2005/08/confinfoextensions“ msci:endpoint-uri=„sip:+49179123456789@itacs.de;user=phone“><media id=“audio“><ci:type xmlns:ci=“urn:ietf:params:xml:ns:conference-info“>audio</ci:type><ci:status xmlns:ci=“urn:ietf:params:xml:ns:conference-info“>sendrecv</ci:status></media></endpoint></user><user entity=“sip: +4930987654321@itacs.de;user=phone“><endpoint xmlns=“urn:ietf:params:xml:ns:conference-info“ entity=“e10902496″ xmlns:msci=“http://schemas.microsoft.com/rtc/2005/08/confinfoextensions“ msci:endpoint-uri=„sip:+4930987654321@itacs.de;user=phone“><media id=“audio“><ci:type xmlns:ci=“urn:ietf:params:xml:ns:conference-info“>audio</ci:type><ci:status xmlns:ci=“urn:ietf:params:xml:ns:conference-info“>sendrecv</ci:status></media></endpoint></user></conversation-info></startConversation>

</request></requests>

Wie gut zu erkennen ist befinden sich diese Informationen allerdings nicht im SIP selbst, sondern im anhängenden Message-Body in einer XML-Formatierung. COMO und der OCS CCS chatten (<startConversation> ) quasi per XML über die zu erstellende conference. Durch die Preferred-Identity ist festgelegt welche Nummer (hier meine Office-Nummer) dem Angerufenen zu präsentieren ist. Die erste msci :endpoint-uri entspricht der für Outside Voice Control konfigurierten Nummer (hier mein Handy) und die zweite dem eigentlichen Ziel meines Anrufs. Nachdem sich COMO und CCS per „XML-Chat“ einig geworden sind, erfolgt eine beiderseits bestätigte Zusammenfassung:

Message-Body: <?xml version=“1.0″ encoding=“utf-16″?>

<conversation-info entity=“{98A78AA7-50C9-941E-18A0-A8BCCD73584B}“ xmlns=“http://schemas.microsoft.com/rtc/2008/12/conversationinfo“>

<conversation-description>

<conversation-id>Acngj+vuByc+xRm4MAEiHgMGdTIMAg==</conversation-id>

<importance>normal</importance>

</conversation-description>

<associated-aors xmlns=“urn:ietf:params:xml:ns:conference-info“>

<entry>

<purpose>preferred-identity</purpose>

</entry>

</associated-aors>

<type>audio</type>

<status>sendrecv</status>

<d6p1:media-state>Pending</d6p1:media-state>

</media>

</endpoint>

</user>

<type>audio</type>

<status>sendrecv</status>

<d6p1:media-state>Pending</d6p1:media-state>

</media>

</endpoint>

</user>

</conversation-info>

</startConversation>

</response>

</responses>

Ab diesem Moment startet die „Action“ zwischen Call Control Server und Mediation Server. Wobei der Mediation Server den VoIP-Gateway als Bindeglied zum Fest- bzw. Handynetz (PSTN) nutzt. Daher sind die Logs am Mediation Server auf aufschlussreichsten. Er sitzt ja mittendrin. Der Call Control Server fordert via SIP-INVITE den ersten Anruf zu meinem Handy an:

TL_INFO(TF_PROTOCOL) [1]13A8.1214::05/29/2009-18:17:53.826.0006b92c (S4,SipMessage.DataLoggingHelper:sipmessage.cs(581))

<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_2A07950>], MediationSRV-IP:5061<-OCS-SE-SRV-IP:51390

INVITE sip:+49179123456789@ocsmediationserverfqdn.itacs.de:5061;user=phone;maddr=ocsmediationserverfqdn.itacs.de SIP/2.0

FROM: „Jan Boguslawski“<sip:jan.boguslawski@itacs.de>;epid=444E1165FA;tag=a85b1ade

TO: <sip:+49179123456789;ms-skip-rnl@itacs.de;user=phone>

CSEQ: 10 INVITE

CALL-ID: e345ca8b-821a-4bdb-b03f-24e244e78482

MAX-FORWARDS: 69

VIA: SIP/2.0/TLS OCS-SE-SRV-IP:51390;branch=z9hG4bK87D89DB8.54257D78E12E3432;branched=FALSE

VIA: SIP/2.0/TLS OCS-SE-SRV-IP:51435;branch=z9hG4bK714f73f7;ms-received-port=51435;ms-received-cid=35700

RECORD-ROUTE: <sip:ocsseserverfqdn.itacs.de:5061;transport=tls;opaque=state:T;lr>;tag=5658CF40F3C38C46021D544A05FDFAAB

CONTACT: <sip:ocsseserverfqdn.itacs.de@itacs.de;gruu;opaque=srvr:Microsoft.Rtc.Applications.Ccs:BYNDyUfCWkGSjw2nRm1NEwAA>;automata;text;audio;video

CONTENT-LENGTH: 0

EXPIRES: 600

PRIORITY: Normal

SUPPORTED: Replaces

SUPPORTED: ms-dialog-route-set-update

SUPPORTED: gruu-10

SUPPORTED: timer

USER-AGENT: RTCC/3.5.0.0 Microsoft.Rtc.Applications.Ccs

ALLOW: UPDATE

ALLOW: Ack, Cancel, Bye,Invite,Message,Info,Service,Options,BeNotify

P-ASSERTED-IDENTITY: „Jan Boguslawski“<sip:jan.boguslawski@itacs.de>,<tel:+493039978418>

ms-user-data: ms-publiccloud=true;ms-federation=true

ms-application-via: backend_token;ms-server= ocsseserverfqdn.itacs.de;ms-pool=ocs04.extranet.itacs.de;ms-application=AB072FF0-C918-424c-AC12-7C100E91FE3E

Ms-Conversation-ID: 303122b457e64fcfa9d67dc920fe178f

Session-Expires: 1800

Min-SE: 90

————EndOfIncoming SipMessage

Unter P-ASSERTED-IDENTITY ist die dem Festnetz „vorzugebende“ Nummer, also meine Office-Nummer hinterlegt. Der Mediation Server berücksichtigt diese Information und maskiert damit die eigentlich Quellnummer. Schön zu sehen am From in dem recht einfachen INVITE, den er an den VoIP-Gateway sendet:

TL_INFO(TF_PROTOCOL) [1]13A8.0B5C::05/29/2009-18:17:54.107.0006ba2e (S4,SipMessage.DataLoggingHelper:sipmessage.cs(531))

>>>>>>>>>>>>Outgoing SipMessage c=[<SipTcpConnection_3897EC9>], 192.168.2.1:50658->192.168.2.2:5060

INVITE sip:+49179123456789@192.168.2.2;user=phone SIP/2.0

FROM: <sip:+493039978418@ocsmediationserverfqdn.itacs.de;user=phone>;epid=767BC92111;tag=6fee949a9

TO: <sip:+49179123456789@192.168.2.2;user=phone>

CSEQ: 56 INVITE

CALL-ID: 71bda7e7-6b16-4586-aa6e-14e5b2a071b3

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.2.1:50658;branch=z9hG4bK24978c6d

CONTACT: <sip:ocsmediationserverfqdn.itacs.de:5060;transport=Tcp;maddr=192.168.2.1;ms-opaque=df732c6244a000ee>

CONTENT-LENGTH: 325

SUPPORTED: 100rel

USER-AGENT: RTCC/3.5.0.0 MediationServer

CONTENT-TYPE: application/sdp; charset=utf-8

ALLOW: UPDATE

ALLOW: Ack, Cancel, Bye,Invite

v=0

o=- 115 1 IN IP4 192.168.2.1

s=session

c=IN IP4 192.168.2.1

b=CT:1000

t=0 0

m=audio 62806 RTP/AVP 97 101 13 0 8

c=IN IP4 192.168.2.1

a=rtcp:62807

a=label:Audio

a=rtpmap:97 RED/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:13 CN/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=ptime:20

————EndOfOutgoing SipMessage

Das transport=Tcp statt TLS macht deutlich das SIP nun unverschlüsselt übertragen wird. Der SDP Anteil (Session Description Protocol) der Nachricht offenbart welche Audio-Codecs der Mediation Server für die Sprachübertragung unterstützt. Leider beschränkt sich der Support auf Schmalband (narrow-band) G.711 alaw und μ-law, obwohl moderne VoIP-Gateways ja bereits länger bessere Codecs, darunter auch Breitband unterstützen. Aber zum Glück wird ja OCS ständig verbessert, bzw. von Version zu Version modernisiert.
Ein abschließender Blick in die SIP-SERVICE Logs zeigt auf, dass die Audioströme beider Gesprächspartner lokal auf dem Mediationserver verknüpft werden. Dazu wird ICE (Interactive Connectivity Establishment) bzw. MS-ICE verwendet und der Mediation Server zu einem Vermittler. Die VQReportEvent (Voice Quality Report) Nachrichten dienen auch zur Auswertung im Quality of Experience Monitoring Server. Dabei wird die Sprachqualität genau für den beobachteten Abschnitt zwischen Mediationsserver und VoIP-Gateway betrachtet. Auch hier befindet sich die Botschaft im Anhang und im XML-Format.

CONTENT-TYPE: application/vq-rtcpxr+xml

Message-Body: <?xml version=“1.0″?>

<LocationProfile>locationprofilefqdn-of-itacs.de</LocationProfile>

<DialogCategory>TRUNK</DialogCategory>

<FromURI>sip:+493039978418@mediationserverfqdn-of-itacs.de;user=phone</FromURI>

<ToURI>sip:+4930987456321@audiocodesgateway-IP;user=phone</ToURI>

<LocalContactURI>sip:mediationserverfqdn-of-itacs.de:5060;transport=Tcp;maddr=mediationserver-external-ip;ms-opaque=df732c6244a000ee</LocalContactURI>

<RemoteContactURI>sip:1030@audiocodesgateway-IP;transport=tcp</RemoteContactURI>

<LocalUserAgent>RTCC/3.5.0.0 MediationServer/3.5.6907.23</LocalUserAgent>

<RemoteUserAgent>Audiocodes-Sip-Gateway-Mediant 1000/v.5.60A.014.009</RemoteUserAgent>

</DialogInfo>

<Ice>DIRECT</Ice>

</Connectivity>

<IPAddr>mediationserver-external-ip </IPAddr>

</LocalAddr>

<IPAddr>audiocodesgateway-IP </IPAddr>

</RemoteAddr>

</Description>

</Jitter>

</PacketLoss>

</BurstGapLoss>

</Utilization>

</Network>

<Audio>

</Signal>

</Audio>

</Payload>

<Audio>

</NetworkMOS>

</Audio>

</QualityEstimates>

</InboundStream>

</Jitter>

</PacketLoss>

<Delay>

</Delay>

</Utilization>

</Network>

<Audio>

</Audio>

</Payload>

</OutboundStream>

</MediaLine>

</VQSessionReport>

</VQReportEvent>

Anhand des Call Control Servers bzw. der Outside Voice Control Applikation lässt sich gut nachvollziehen, wie ein Microsoft OCS Deployment im Grunde unbegrenzt um eigene Dienste erweitert werden kann. SIP ist dabei nur das Vermittlungsprotokoll, der MessageBody ein universeller Container und die OCS Infrastruktur das Vermittlungsnetzwerk. Alle vier Applikation die sich im Auslieferzustand des OCS R2 auf der Unified Communications Application Server Rolle (UCAS) befinden:

Applikations-Name	Applikations-Identität
Conferencing Attendant	Microsoft.Rtc.Applications.Caa
Conference Announcement Service	Microsoft.Rtc.Applications.Cas
Outside Voice Control	Microsoft.Rtc.Applications.Css
Response Group Service	Microsoft.Rtc.Applications.Acd

sind mit Hilfe der Microsoft Office Communications Server 2007 R2 SDK geschrieben. Mit diesem Entwickler-Kit können also Drittanbieter genauso Lösungen On-Top erstellen, wie es die jeweiligen Entwicklungsabteilungen des Microsoft-RTC-Teams taten (RTC = Real-Time-Communications).

Im nächsten Beitrag „OCS R2 Outside Voice Control – Teil 3: Ausblick“ beschreibe ich wie sich die technische Architektur dieser Funktion verändern wird und welche Verbesserungen damit einhergehen werden…

Über den Autor:

Jan Boguslawski ist Consultant bei der ITaCS GmbH. Als Spezialist für die Microsofts Unified Communications und Messaging Lösungen liegt sein technischer Focus auf Office Communications Server & Exchange Server, inklusive deren Integration in Telekommunikationssysteme.

Kurzlink zu diesem Artikel:
http://faq-o-matic.net/?p=1531

<< vSphere-Client auf Windows 7 installieren (neuer)

(älter) OCS R2 Outside Voice Control – Teil 1: Einführung >>

OCS R2 Outside Voice Control – Teil 2: Im Detail

Kurzlink zu diesem Artikel

Titel und Link kopieren und in eigene Texte einfügen

Suchen

Wegweiser

Kategorien

Protected by

Blogzeit

Formales

Autoren

OCS R2 Outside Voice Control – Teil 2: Im Detail

Kurzlink zu diesem Artikel

Titel und Link kopieren und in eigene Texte einfügen

Verwandte Beiträge:

Suchen

Wegweiser

Kategorien

Protected by

Blogzeit

Formales

Autoren