CAC - Testen

Nicht jeder hat ein Lync Testfeld parat und selbst wenn ihr Dienstleister wie z.B. Net at Work ein fundiertes Wissen mitbringt, so ist die Umsetzung und die Auswirkung nicht immer einfach zu durchschauen und hat durchaus etwas mit der Komplexität einer Einführung von QoS, VLANs, 802.1x etc. zu tun. Zudem bekommen die Client die Information, das Sie CAC nutzen sollen, per "Inband Provisioning" bei der Anmeldung mit. Es greift also nicht "sofort" und damit kann man es auch nicht mehr "sofort" rückgängig machen.

Bandwidth Policy Server erreichbar ?

Der Client, welcher den Ruf bekommt, hat als erster sowohl die Kandidaten des Anrufers als auch seine Kandidaten und legt diese dem Bandwidth Policy Server zur Bestätigung vor. Mit dem Tools "MsTurnPing" aus dem Lync Ressource Kit können Sie vom Client aus testen, ob dieser PolicyServer erreichbar ist. Der Aufruf ist wie folgt:

MsTurnPing -ServerRole BandwidthPolicyServer

Die Ausgabe erfolgt auch nur in der CMD-Box

Damit ist schon mal sichergestellt, dass der Client den Server erreicht.

Test mit einzelnen Hosts

Aber der umstand, dass bei CAC "nicht bekannte Subnetze" als "unbeschränkt" gelten, öffnet ihnen den Weg mit CAC im LAN zu experimentieren. Sie können nämlich auch einzelne Hosts als "Subnetz" definieren. So können Sie als Subnetz erst mal einzelne IP-Adressen von Clients angeben und nach und  nach erweitern.

Wichtig:
Beide Endpunkte der Audio/Video-Verbindung müssen in CAC definiert sein, damit CAC angewendet wird ! Denken Sie auch an die IP-Adressen des Edge-Server, die Mediation Server und Konferenz-MCUs der Frontend Server

Auch umgekehrt ist so ein "Einzel Host Subnetz" ganz hilfreich um z.B. die offizielle IP-Adresse des AV-Edge-Servers in eine eigene Region zu stecken und damit die Bandbreite über das Internet zu steuern.

In einem INVITE können Sie dann sehr gut auch sehen, welche Bandbreiten-Limits gelten.

Content-Type: application/sdp
v=0
o=- 0 5 IN IP4 10.164.146.29
s=session
c=IN IP4 10.164.146.29
b=CT:99980
t=0 0
a=x-mediabw:main-video send=95;recv=4000
a=x-devicecaps:audio:send,recv;video:send,recv
m=audio 50004 RTP/SAVP 114 9 112 111 0 8 116 115 97 13 118 101
a=x-ssrc-range:2195221019-2195221019

Ein Limit muss nicht immer in beide Richtungen gelten.

All ihre CAC Einstellungen werden im Eventlog protokolliert. Hier sind zwei Events interessant:

Source: Eventlog: Source "LS Bandwidth Polcy Service (Core)
EventID: 36034 Meldung über Subnetze, die nicht definiert sind
EventID: 36046 Configuration Change and Updates. Guter Indikator um Änderungen zu loggen

Sobald CAC eine Verbindung unterbindet, sieht man auf dem Client eine leider nicht ganz so sprechende Fehlermeldung. Ich habe hier einfach versucht den Audio Testservice anzurufen.

Blickt man dann aber in den Lync Trace auf dem Client, dann kann die Ursache einfach gefunden werden:

Das fragliche 488 Paket enthält folgende Daten, die nach Einfügen einiger Zeilenumbrüche besser sichtbar sind:

SIP/2.0 488 Not Acceptable Here
From: "Carius, Frank"<sip:frank.carius@netatwork.de>;tag=fe119d2799;epid=2385f4c267
To: "Audio Test Service"<sip:nawlync001.netatwork.de@netatwork.de;gruu;opaque=srvr:Microsoft.
Rtc.Applications.TestBot
CSeq: 1 INVITE
Priority: Normal
Warning: 370 lcs.microsoft.com "Call cannot be completed due to bandwidth check"
Server: RTCC/5.0.0.0 ATS/1.0.100
Subject: Testanruf
ms-diagnostics: 5;Component="RTCC/5.0.0.0_ATS/1.0.100";
   Reason="Insufficient bandwidth to establish session. Attempt PSTN re-route";
   CalleeICEWarningFlags="Audio:ICEWarn=0x48000,
      LocalSite=192.168.100.100:53356,LocalMR=80.66.20.21:54750,
       RemoteSite=192.168.102.15:3098,RemoteMR=80.66.20.21:58668,
       PortRange=49152:57500,LocalMRTCPPort=54538,RemoteMRTCPPort=58668,
       LocalLocation=2,RemoteLocation=2,FederationType=0,
       Interfaces=0x2,BaseInterface=0x2,BaseAddress=192.168.100.100:51964";
    Source="NAWLYNC001.netatwork.de"

Schade, dass der Lync Client diese Fehlermeldung nicht wenigstens partiell auf der GUI anzeigt und den Anwender so um dunkeln stehen lässt. Im Eventlog des Client wird jedoch ein Event 11 mit allen Details geloggt. Hier ein um die SDP-Records gekürztes Beispiel:

Protokollname: Application
Quelle:        Lync
Datum:         28.06.2013 17:48:36
Ereignis-ID:   11
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      NAWNBFC.netatwork.de
Beschreibung:

Lync
80ef01e8
RequestUri:   sip:nawlync001.netatwork.de@netatwork.de;gruu;opaque=srvr:Microsoft.
  Rtc.Applications.TestBot:yxGAFXR5iVm6z2OQ9SjS6gAA
From:         sip:frank.carius@netatwork.de;tag=fe119d2799
To:           sip:nawlync001.netatwork.de@netatwork.de;gruu;opaque=srvr:Microsoft.
  Rtc.Applications.TestBot:yxGAFXR5iVm6z2OQ9SjS6gAA;tag=bed5214ad
Call-ID:      e77702f7eb044662820315ae8b2c819e
Content-type: multipart/alternative;boundary="----=_NextPart_000_01C7_01CE7427.B6C603A0";
  call-type=audiovideo

------=_NextPart_000_01C7_01CE7427.B6C603A0
Content-Type: application/sdp
.... 
------=_NextPart_000_01C7_01CE7427.B6C603A0--


Response Data:

180  Ringing


488  Not Acceptable Here
ms-diagnostics:  5;Component="RTCC/5.0.0.0_ATS/1.0.100";
Reason="Insufficient bandwidth to establish session. Attempt PSTN re-route";
CalleeICEWarningFlags="Audio:ICEWarn=0x48000,LocalSite=192.168.100.100:53356,
LocalMR=80.66.20.21:54750,RemoteSite=192.168.102.15:3098,RemoteMR=80.66.20.21:58668,
PortRange=49152:57500,LocalMRTCPPort=54538,RemoteMRTCPPort=58668,
LocalLocation=2,RemoteLocation=2,FederationType=0,Interfaces=0x2,
BaseInterface=0x2,BaseAddress=192.168.100.100:51964";Source="NAWLYNC001.netatwork.de";
OriginalPresenceState="0";CurrentPresenceState="0";MeInsideUser="Yes";
ConversationInitiatedBy="0";SourceNetwork="0";RemotePartyCanDoIM="No"

Wer einen Lync Monitoring Server betreibt, kann aber auch dort nach solchen fehlgeschlagenen Calls suchen.

PSTN Failover am Client

Wenn Sie die Funktion "Enable PSTN retour" aktiv haben und entsprechenden PSTN-Usages den Client über ein noch erreichbares Gateway einen Telefonanruf erlauben, dann umgeht der Lync eine Bandbreitensperre. Dies können Sie problemlos in den Traces sehen.

Keyhole-Debugging - Was man allein über das Lync Client Log ermitteln kann.

 Der angerufene Teilnehmer sendet dann dem Anrufer die folgende Meldung als Bestandteil des SIP-Dialogs:

SIP/2.0 199 Early Dialog Terminated
ms-User-logon-data: RemoteUser
Authentication-Info: NTLM qop="auth", opaque="53E2666D", srand="7056D21B", snum="30",
   rspauth="fefb", targetname="lync001.netatwork.de", realm="SIP Communications Service", version=4
Content-Length: 0
Via: SIP/2.0/TLS 192.168.103.25:42800;received=80.66.20.18;ms-received-port=38762
From: "Frank Carius"<sip:User1@netatwork.de>;tag=69a63fdd9b;epid=110531d8e4
Call-ID: b52fbb66e9e345238307c83421691b00
CSeq: 1 INVITE
To: <sip:User2@netatwork.de>;tag=166329d54d
ms-diagnostics: 5;reason="Insufficient bandwidth to establish session.
   Attempt PSTN re-route";source="lync001.netatwork.de";appName="InboundRouting"
Server: http%3A%2F%2Fwww.microsoft.com%2FLCS%2FDefaultRouting(Microsoft Lync Server 2010 4.0.7577.139)

Sie sehen in der Meldung die Information: ms-diagnostics: 5;reason="Insufficient bandwidth to establish session." und der Vorschlag doch einen PSTN-Reroute zu tun. Gleiches sehen Sie auch noch mal in dem nachfolgenden 181.

SIP/2.0 181 Progress Report
ms-User-logon-data: RemoteUser
Authentication-Info: NTLM qop="auth", opaque="53E2666D", srand="0931A7D2", snum="31",
   rspauth="e6f1", targetname="lync001.netatwork.de", realm="SIP Communications Service", version=4
Via: SIP/2.0/TLS 192.168.103.25:42800;received=80.66.20.18;ms-received-port=38762;ms-received-cid=47F00
From: "Frank Carius"<sip:User1@netatwork.de>;tag=69a63fdd9b;epid=110531d8e4
To: <sip:User2@netatwork.de>
Call-ID: b52fbb66e9e345238307c83421691b00
CSeq: 1 INVITE
ms-diagnostics: 5;reason="Insufficient bandwidth to establish session. Attempt PSTN re-route";
  source="lync001.netatwork.de";appName="InterClusterRouting"
Server: InterClusterRouting/4.0.0.0
Content-Length: 0

SIP/2.0 101 Progress Report
ms-User-logon-data: RemoteUser
Authentication-Info: NTLM qop="auth", opaque="53E2666D", srand="68415B4C", snum="32",
    rspauth="b462", targetname="lync001.netatwork.de", realm="SIP Communications Service", version=4
Via: SIP/2.0/TLS 192.168.103.25:42800;received=80.66.20.18;ms-received-port=38762;ms-received-cid=47F00
From: "Frank Carius"<sip:User1@netatwork.de>;tag=69a63fdd9b;epid=110531d8e4
To: <sip:User2@netatwork.de>
Call-ID: b52fbb66e9e345238307c83421691b00
CSeq: 1 INVITE
ms-diagnostics: 25002;reason="Routing to best pool";source="lync001.netatwork.de";
   clusterFqdn="lync001.netatwork.de";routingType="ToRouting";appName="InterClusterRouting"
Server: InterClusterRouting/4.0.0.0
Content-Length: 0

Der Anrufer startet dann einen eigenen INVITE, indem er nun aber die Rufnummer des Partners angibt und über eine Option dem Lync sagt, dass er auch tatsächlich die Rufnummer weiter verarbeiten soll und nicht etwa im Adressbuch wieder den Lync-Benutzer findet.

Der angerufene Teilnehmer sieht dann idealerweise einen eingehenden Ruf und bei korrekter Übermittlung der "Calling Party Number" kann der Client auch den Anrufer namentlich anzeigen.

Hinweis:
Damit PST-Failover sauber funktioniert, sollten Sie z.B. in dem Standort des Anrufers eine Voice Route anlegen, die die jeweils andere Niederlassung spezifiziert. Eine globale Route "+*" über mehrere Gateways ist da nicht geeignet. Mehrere Gateways sollten nur dann in einer Route zusammen gefasst werden, wenn diese wirklich "Hochverfügbarkeit" am gleichen Standort liefern und nicht ein Failover über andere Sites bedeuten.

Weitere Links