Audiocodes SPS - SIP Phone Support

Lync unterstützt native Lync:Telefone aber keine generischen SIP-Clients. Dafür gibt es Drittprodukte, die als Proxy oder Gateway auf der einen Seite mit Lync kommunizieren und auf der anderen Seite ein SIP-Server für allgemeine Clients sind und damit über Lync die Telefonie-Funktionen nutzen können und auch einen Präsenzstatus anzeigen. Allerdings werden so weder die Provisioningfunktionen von Lync, noch Instant Messages, Adressbuchzugriffe etc. funktionieren. Dennoch kann so eine Lösung interessant sein um solche Clients anzubinden.

Audiocodes SPS ist ein Vertreter solcher Software. Es gibt natürlich vergleichbare Wettbewerbsprodukte,. z.B. Ferrari SIP2Lync und andere. Einfache SIP-Clients können (ohne Präsenz) oftmals auch direkt an Gateways oder Session Border Controller angebunden werden.

Ich beschreibe hier relativ ausführlich den Einsatz dieser Software mit Lync. Lassen Sie sich bitte nicht dazu verleiten, anhand dieser Beschreibung zu entscheiden, ob diese Anbindung für Sie die passende Lösung darstellt. Es gibt eine ganze Menge Abhängigkeiten und ein gutes Design und Konzept erfordert Erfahrung. Aber vielleicht macht Sie die Beschreibung neugierig und sprechen das weitere Vorgehen mit uns ab.

Dass ich oft mit Gateways von Audiocodes arbeite, ist sicher schon bekannt (Siehe Audiocodes und Folgeseiten). Insofern ist es nur logisch, wenn ich mir auch die Software von Audiocodes anschaue, um SIP-Endgeräte in Lync einzubinden, die selbst nicht mit Lync kommunizieren können. Diese Seite beschreibt grob die Funktionsweise. Aufgrund der unterschiedlichen eingesetzten Produkte und Techniken möchte ich eine solche Lösung aber nicht als "Plug and Play" bezeichnen. Sie sollten schon ein fundiertes Wissen mitbringen.

Funktionsweise

Audiocodes hat natürlich das Rad nicht neu erfunden und die Gateways selbst sind zwar Lync-zertifiziert, aber das betrifft nur Voice-Routing aber keine Präsenz. Die Gateways alleine können auch nicht sinnvoll als Registrar für Client arbeiten. In einer Umgebung ohne Lync ist also auch mit einem Gateway immer noch eine Art VoIP-PBX (Asterisk, FreeSWITCH o.ä.) möglich aber mit Lync und Presence hat das nicht mehr viel zu tun. Die Presence kann natürlich der Communicator setzen oder ein Helper-Service, der z.B.: per UCMA "im Auftrag des Benutzers" die Einstellungen vornimmt. Und genau das macht SPS. Es nutzt UCMA, um ein SIP-Endgerät, welche sich nicht direkt an Lync anmelden kann, mit einem Status zu versehen. Die verschiedenen Statusmeldungen eines Clients:

Beschreibung Status

Verfügbar:
In diesen Status fällt ein Endpunkt zurück, wenn die Verbindung aufgelegt wurde

Am Telefon:
In diesen Status setzt die SPS-Software den Client, wenn die Verbindung hergestellt wurde. Ein Klingeln alleine setzt den Status noch nicht

Inaktiv
Nach einigen Minuten Inaktivität, was global konfiguriert werden kann, wird der Endpunkt "Gelb". Das bedeutet natürlich nicht, dass der Teilnehmer nichts tut, aber er hat eben einige Zeit nicht mehr telefoniert.

Offline
Dieser Status steht an, wenn kein Endpunkt sich am SPS registriert hat. Wird also das analoge Gerät nicht nur abgelegt, sondern kann z.B. der ATA-Adapter oder das SIP-Telefon sich nicht mehr registrieren, dann läuft die aktuelle Registrierung auf und das Gerät wird "Offline". Es gibt aber eine merkliche Verzögerung, wenn das Endgerät sich nicht korrekt "abmeldet"

Hinweis:
Gerade mit analogen Endgeräten kann es gut passieren, dass die Verbindung abgebaut wird, aber der Teilnehmer nicht "auflegt". Er ist damit telefonisch nicht mehr erreichbar, da jeder SIP INVITE natürlich mit einem SIP BUSY beendet wird. Im Status ist dies aber nicht zu erkennen.

Damit es diesen Status setzen kann, muss es aber den Status auch können. Und es muss einen Vermittler für die SIP und RTP (Audio)-Kommunikation geben, denn ein normales SIP-Endgerät kann sich ja nicht an Lync anmelden. Audiocodes macht das aber nun nicht über ihre Gateways, wie das Ferrari mit ihrem SIP2Lync machen, sondern nutzen UCMA nicht nur zum Status-Setzen, sondern auch als RTP und SIP-Endpunkt für Lync. Der Lync Server "glaubt" also, dass alle Endpunkt auf dem SPS-Server registriert sind.

Auf der anderen Seite muss es natürlich einen SIP Registrar bzw. Proxy geben, der die normalen SIP-Geräte bedient. Genau diese Funktion übernimmt bei Audiocodes SPS eine entsprechend angepasst Version der FreeSWITCH.

Die Free-Switch spricht aber nicht mit Lync !!. Sie ist ja auch nicht Lync Zertifiziert. Mit Lync spricht nur der UCMA-Stack.

Das ganze sieht als Funktionsbild in etwa so aus:

Sie sehen, dass ganz links einen Grandstream ATA-Router 502 SIP, der ein analoges Telefon per SIP an den "SPS Switch" anbindet. Dahinter verbirgt sich die FreeSWITCH, die sich auch im UserAgent wiederfindet. Dann gibt es aber noch den SPSLync-Dienst, welcher mit der FreeSWITCH nach links und mit UCMA nach rechts kommuniziert. SPSLync "weiß" also genau, welche Verbindungen gerade etabliert sind, da jedes INVITE, OK und BYE durch ihn durch gehen. Entsprechend kann der Dienst per UCMA auch den Status in Lync beeinflussen. Die Berechtigungen dazu hat er als "Trusted Application/Server"

Installation

Auch wenn Audiocodes die Software SPS entwickelt, so funktioniert sie komplett unabhängig von den Gateways. Sie kann aber z.B.: auf dem PC einer SBA laufen, wenn Sie in einer Niederlassung einfach nur SIP-Telefone betreiben wollten. Technisch brauchen Sie:

  • Intel/AMD-Server
  • Windows 2008
  • NET 3.51

Interessanterweise reicht es aber nicht, einfach die UCMA für Lync zu installieren. Warum auch immer muss auf dem PC auch das Lync Setup ausgeführt werden und ein Local Configuration Store, also die SQL-Express mit dem Lync Replicator installiert werden. Einen Grund dafür kann ich nicht erkennen. Allerdings sind mit der "Vorbereitung" durch das Lync Setup auch die Lync PowerShell Commandlets vorhanden. Dazu würde aber die Installation der CoreComponents als Vorarbeit des Setup reichen und man bräuchte keinen "Local configuration Store". Das SPS Setup lässt sich ohne die RTCLOCAL Instanz aber nicht fortsetzen. Hier die wichtigsten Schritte:

  • DNS: Eintrag sps-pool-1.netatwork.de A 192.168.100.64
  • Lync: Installation TopologyBuilder (Installiert "nebenbei" die Deploymenttools, Lync PowerShell etc)
  • Lync: Install Local Store (Installiert nur SQL da kein Server mit Rollen im Lync CMS)
  • Lync: Computerzertifikat für den geplanten Pool-Namen anfordern und als Default zuweisen
  • Lync Ressource Kit installieren
    Das machte ich generell um die Daten des Lync Logging Tools besser auswerten zu können
  • Activate SPS (Als Admin starten das sonst "Execution Policy" nicht gesetzt werden kann)
  • ZentAdmin: initiales Adminkennwort setzen

Nach der Installation befinden sich eine ganze Menge von Icons im Startmenü, von denen Sie aber nur wenige tatsächlich brauchen.

Zuerst sehen Sie einen SPS Core-genannten Bereich. Das ist der SIPLync-Teil, der per UCMA mit Lync spricht aber auch RTP zu den SIP-Endpunkten handhabt. Der als "SPS Switch" benannte Bereich ist eine FreeSWITCH, die als SIP-Registrar für die SIP-Teilnehmer dient. Zudem wird ein ZEND-Server (ein vorbereitete Apache-Paket mit PHP etc.) installiert, über den die Konfiguration erfolgt.

Aktivierung: Die normalerweise komplizierte Einbindung in Lync

Die "Aktivierung" ist faktisch ein PowerShell-Script, welches in Lync die entsprechenden Einstellungen vornimmt. Eine erfolgreiche Aktivierung sieht so aus:

Danach erkennt man z.B.: die "Trusted Application" im Control Panel

Der "Trusted Application Server" hat den Weg in den Topology-Builder gefunden:

Aber das ist nur ein Teil der Konfiguration. Per PowerShell erhalten sie auch die TrustedApplicationsComputer und Pools

PS C:\> Get-CsTrustedApplication

Identity                   : sps-pool-1.netatwork.de/urn:application:sps
ComputerGruus              : {NAWLYNCTEST.netatwork.de sip:NAWLYNCTEST.netatwor
                             k.de@netatwork.de;gruu;opaque=srvr:sps:xxxxxxxxxxx
                             xxxxxxxxxxxxx}
ServiceGruu                : sip:sps-pool-1.netatwork.de@netatwork.de;gruu;opaq ue=srvr:sps:xxxxxxxxxxxxxxx-xxxxxxxx
Protocol                   : Mtls
ApplicationId              : urn:application:sps
TrustedApplicationPoolFqdn : sps-pool-1.netatwork.de
Port                       : 15061
LegacyApplicationName      : sps
PS C:\> Get-CsTrustedApplicationComputer

Identity : NAWLYNCTEST.netatwork.de
Pool     : sps-pool-1.netatwork.de
Fqdn     : NAWLYNCTEST.netatwork.de
PS C:\> Get-CsTrustedApplicationEndpoint

Identity               : CN={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx},CN=Applicati
                         on Contacts,CN=RTC Service,CN=Services,CN=Configuratio
                         n,DC=netatwork,DC=de
RegistrarPool          : nawlync001.netatwork.de
HomeServer             : CN=Lc Services,CN=Microsoft,CN=1:12,CN=Pools,CN=RTC Se
                         rvice,CN=Services,CN=Configuration,DC=netatwork,DC=de
OwnerUrn               : urn:application:sps
SipAddress             : sip:sps-lync-site1@netatwork.de
DisplayName            : Audiocodes SPS application endpoint
DisplayNumber          :
LineURI                : primäryLanguage        : 0
SecondaryLanguages     : {}
EnterpriseVoiceEnabled : True
Enabled                : True
PS C:\> Get-CsTrustedApplicationPool

Identity             : TrustedApplicationPool:sps-pool-1.netatwork.de
Registrar            : Registrar:nawlync001.netatwork.de
FileStore            :
ThrottleAsServer     : True
TreatAsAuthenticated : True
OutboundOnly         : False
RequiresReplication  : True
AudioPortStart       :
AudioPortCount       : 0
AppSharingPortStart  :
AppSharingPortCount  : 0
VideoPortStart       :
VideoPortCount       : 0
Applications         : {urn:application:sps}
DependentServiceList : {}
ServiceId            : 1-ExternalServer-16
SiteId               : Site:Paderborn
PoolFqdn             : sps-pool-1.netatwork.de
Version              : 5
Role                 : TrustedApplicationPool

All diese Einträge legt aber das PowerShell-Skript für sie quasi automatisch an. Aber es kann einiges diese Aktivierung verhindern, z.B.:

  • Zertifikate
    Alle Server zu Server Kommunikation in Lync wird per TLS und Zertifikate abgesichert. Das Aktivierungsskript versucht selbst entsprechende Zertifikate für den SPS-Server anzufordern. Das funktioniert natürlich nur mit einer AD-Integrierten CA, entsprechenden Berechtigungen und dem "Webserver"-Template. Meine CA hatte aber diese Template nicht mehr und es wurde durch ein angepasstes "WebServer 5 Jahre"-Template ersetzt. Da das PowerShell-Script aber nicht nur die Zertifizierungsstellen ausliest und eine zu Auswahl anbietet sondern auch als "Type = Default" angibt, habe ich es vorgezogen, mit den Lync Deployment Tools ein Zertifikat anzufordern und zuzuweisen.
  • Script-Signierung und Execution Policy
    Per Default führt die PowerShell nur signierte Skripte aus. Das Audiocodes-Skript ist nicht signiert. Sie müssen also eventuell die Execution -Policy anpassen oder das Skript "Als Administrator ausführen...", um den folgenden Fehler zu vermeiden:
  • Lokaler Lync SQL-Store
    Ich habe lange überlegt, warum die die SPS eine komplette Lync Basis-Installation auf dem Server haben will. Die Lync PowerShell für die Aktivierung kann ich ja noch verstehen aber einen SQL-Server und Replication Services ?. Aber ohne diese Dienste funktioniert die Aktivierung nicht
  • DNS Eintrag für Pool

Audiocodes hat aber auch an die Firmen gedacht, die noch mehr mit delegierten Berechtigungen arbeiten und eine Anleitung für die manuelle Aktivierung beigefügt. Sie finden diese auf "C:\Program Files\Audiocodes\SPS\SPS Core\PowerShell\ManualSpsActivation.rtf"

Lync Einstellungen, Dienste und Ports

Nach der Aktivierung können Sie die drei Dienste starten:

Wenn man den Dienst "debuggen" will, dann kann der Dienst gestoppt werden. Die Exe kann mit einem Parameter gestartet werden:

REM SPSLync interaktiv mit Bildschirmausgaben starten
SPSLync.exe -console
REM oder
SPSLync.exe -c

Auch wenn der Dienst SPS-Switch benannt ist, so können sie sowohl in der Kommandozeile doch spätestens im Prozessmanager sehen, welche Ports durch SpsLync und welche durch FreeSWITCH belegt werden.

Konfiguration

Die Konfiguration ist recht schnell ein einfach beschrieben, da die Aktivierung eigentlich schon alles erledigt hat.

  • Globale Einstellungen
    Es gibt einige allgemeine Einstellungen wie z.B. die Sondernummern um vom Telefon den Status zu setzen
  • Benutzereinstellungen
    Alle Anwender, die sich per SIP mit einem Endgerät anmelden wollen, müssen in der SPS konfiguriert werden.

Wer sich das erste mal an der SPS per Browser anmeldet, wird erst mal verwundert schauen. Die SPS hat eine Weboberfläche, die sich sehr stark an die Verwaltung der Audiocodes Medianten aus gleichem Haus orientiert. Auf der ersten Ebene sehen Sie den Status:

Im Bereich des Management können Sie z.B. die Rufnummern für die StatusÄnderung konfigurieren. Dies ist aber nur erforderlich, wenn ein Anwender über das so angebundene Telefon seinen Präsenzstatus ändern muss. Den Wechsel auf "Am Telefone", "Offline", "Abwesend" oder "Frei" übernimmt die SPS von alleine

Interessanterweise fehlt hier der Status "Offline". Dieser kann bei Audiocodes SPS nicht manuell gesetzt werden. Sollte sich das SIP-Telefone allerdings abmelden, dann setzt SPS den Status natürlich automatisch auf "Offline". Den aktuellen Status kann der Anwender am Telefon leider nicht sehen. Die Zeit bis zum automatischen Wechsel von "Frei" nach "Inaktiv" oder "Abwesend" können sie nur global einstellen.

Management: Benutzer

In der SPS muss jeder Benutzer addiert werden, der über die SPS ein Telefon anbinden will. Insofern gibt es eine kleine eigene Benutzerverwaltung auf dem SPS mit eigenem Kennwort. Es kommt nicht das Active Directory Kennwort zum Einsatz, was ich aber ausnahmsweise gut finde. denn:

  • Kennwortrichtlinien, Tokens oder Smartcard
    Das Active Directory Kennwort ist der Schlüssel zu den Daten. Und oft werden diese regelmäßig geändert oder die Anmeldung ist zusätzlich mit Tokens oder Smartcards gesichert. Ein eigenes VoIP-Kennwort macht da schon Sinn, vor allem wenn es nicht regelmäßig geändert werden muss.
  • Eingabe auf numerischer Tastatur
    Zudem sind die EingabeMöglichkeiten auf Telefontastaturen vielleicht beschränkt. Zahlen und vielleicht noch Buchstaben sind möglich aber bei Sonderzeichen wird das Ganze mehr ein Ärgernis.
  • SIP/TCP und abhören
    Nicht alle Endgeräte werden sicher alles mit TLS verschlüsseln und auch wenn die SPS als Anmeldung "DIGEST" nutzt, bleibt ein Restrisiko, dass das Kennwort doch auslesbar wäre. Ein Angreifer könnte dann maximal auf Kosten des legitimen Anwender telefonieren.

Zuerst nutzen wir aber die "Add New User"-Schaltfläche, um die gewünschten Anwender zu addieren.

Gut erkennbar ist, dass die 694@netatwork.de mit "MediaBypass" konfiguriert ist. Dazu später mehr. Beim Benutzer selbst gibt es nicht allzu viel einzustellen. 

Das Kennwort ist mit einem zufälligen Wert vorbelegt und kann durch einen Klick auf das Fragezeichen eingeblendet werden. Es kann auch auf numerische Werte geändert werden, z.B. wenn ein SIP-Telefon zur Anmeldung keine Zeichen unterstützt.

Media Bypass

Sie sie bei der Konfiguration der Benutzer und am Anfang am Bild schon sehen konnten, können Sie Pro Benutzer (nicht pro Gerät) die Funktion Media Bypass aktivieren. Diese Einstellung darf nicht mit MediaBypass in Lync verwechselt werden. Sie sind komplett losgelöst voneinander.

Per Default ist Media Bypass abgeschaltet und die Audiodaten gegen über SPSLync als Relay. Das bedeutet natürlich eine höhere Last, längere Laufzeit der Pakete. Ehe Sie aber nun MediaBypass abschalten, müssen sie die Kompatibilität zu bestehenden Endgeräten prüfen. Eine Audiocodes SPS setzen Sie ja ein, um, eben SIP-Geräte in Lync samt Status einzubinden, selbst wenn diese ansonsten nicht mit Lync arbeiten.

Wenn mit MediaBypass hier arbeiten, geht die Signalisierung (SIP) weiterhin über SPSLync und FreeSWITCH, aber SPSLync setzt nicht mehr seine IP-Adressen als "Endpunkte" ein, sondern gibt die Kandidaten der beiden Partner weiter. Die Partner müssen sich dann selbst verständigen.

Normalerweise nutzt Lync "SRTP Only", was nicht alle Endpunkte können. Wobei viele Umgebungen von sich aus von "Media Encryption: Required" auf "Media Encryption: Supported" umstellt, weil es auch Endgeräte gibt, die sich selbst direkt an Lync anmelden können aber (noch) kein SRTP unterstützen, z.B. Polycom Konferenzsysteme (HDX). Aber selbst wenn das SIP-Endgerät sogar SRTP unterstützt, so gibt es auch hier verschiedene Varianten und auch die Codec-Frage muss geklärt werden. Und weil es damit noch nicht genug ist, gibt es in Lync Umgebungen noch Edge-Server, die STUN/TURN-Server sind, die DTMF Signalisierung, Anzeige der Nummern, Funktion mit SBA etc. Die liste ist nicht vollständig.

Für den Status sollten Sie für jede Richtung folgende Punkte Klären:

  • Töne: Hört der Anrufer die "gewohnten" Töne (Freizeichen, Wählton, Besetzt etc.)
  • Klingeln: Kommt der Ruf an, wird die richtige Rufnummer angezeigt, hört der Anrufer ein Freizeichen bzw. Besetzt ?
  • Audio: Verständigung klar und deutlich, fehlen die ersten Sekunden
  • DTMF: kann Exchange UM u.a. korrekt gesteuert werden

Und dann gibt es eine ganze Menge von Paarungen:

Teilnehmer A Teilnehmer B Status
A->B
Status
B->A
Bemerkung

SIP

Lync Communicator

 

 

Das ist der einfachste und normale Einsatzfall. Eine Verbindung zwischen dem SIP-Teilnehmer und einem Lync Communicator sollte auf jeden Fall funktionieren

SIP

Communicator (EDGE)

 

 

Eine Verbindung zu einem Client "draußen", der über Edge angebunden ist, sollte auch funktionieren. In der Regel wird so etwas nicht mit Media Bypass funktionieren, da die wenigsten Endgeräte einen ICE-Handshake mit dem Edge-Server unterstützen und die Kandidaten entsprechend bereitstellen.

SIP

Lync Phone

 

 

Für Lync gibt es zum einen die ARIES-Telefone wie Aasta 6721p/6725p, Polycom Telefon, HP Phone 4120 aber auch SNOM liefert Lync zertifizierte Telefone die in diesem Umfeld mitspielen müssen

SIP

SIP

 

 

Natürlich sollte es auch möglich sein, dass zwei SIP-Geräte sich unterhalten können und der Lync-Status entsprechend aktualisiert wird. Auch wenn die Audio-Verbindung dann ein Stück weit durch "Lync" geht.

SIP

Exchange UM

 

 

Exchange UM ist ein guter Kandidat um die DTMF-Funktion zu testen.

SIP

CallPark

 

 

Die Weitergabe an das eigene DECT-Telefon funktioniert über CallPark sehr elegant. Das SIP-Endgerät muss natürlich dann den Ruf auch heranziehen können. Das hängt auch etwas von der Wahl der Parking Range ab. Siehe folgender Abschnitt.

SIP

Lync Konferenz Dialin

 

 

ähnlich wie UM muss eine Einwahl in das Konferenzsystem möglich sein. Hier ist nicht nur DTMF gefordert, sondern auch die Kompatibilität mit der Lync Audio-MCU

SIP

Lync Responsegroup

 

 

Ein SIP-Endgerät wird sich zwar nicht in eine RGS ein und austragen können, wie das ein Lync-Client kann, aber der Teilnehmer kann ja "informal" enthalten sein. Das System muss also mit diesen parallelen Einladungen ebenso umgehen wie mit einem "CANCEL". Oft wird man im Telefon in der Anrufliste den Ruf sehen, auch wenn jemand anderes den Ruf angenommen hat. Die Rückrufliste wird also eher unbrauchbar werden.

Weiterhin sind natürlich Funktionen wie Weiterleiten, Rückfrage, Halten, Makeln etc. interessant, wenn das Endgerät dies erlaubt. Auch "Teamcall" sollte durch einen anderen Klingelton unterstützt werden.

Sonderfall Edge und Bypass

Natürlich hat mich interessiert, wie das System bei aktiviertem Media Bypass reagiert, wenn ein Anrufer "extern" ist, also per Federation oder Remote über den EdgeServer anruft. Mit aktiviertem Media Bypass müsste die SPS-Software ja die "Kandidaten" des externen Anrufers nach innen geben und davon sind einige Kandidaten definitiv nicht erreichbar.

Die Verbindung hat auf Anhieb funktioniert und mit Snooper können Sie sehen, dass der INVITE vom Lync Server per UCMA herein kommt und von UCMA intern weiter zur FreeSwitch gegeben wird:

Interessant ist dabei aber der SDP-Playload: Links die Einladung von Lync zum UCMA-Stack mit allen Kandidaten und rechts die Einladung vom UCMA zum FreeSwitch

Lync -> UCMA UCMA -> Freeswitch

Der INVITE, der beim SIP-Endgerät ankommt, enthält als SDP Candidate die IP-Adresse des AudiocodesSPS-Systems. Alle Spuren, dass die Verbindung über einen Edge aufgebaut wurde, sind nicht mehr vorhanden. Ob dies nun eine "Besonderheit" in Verbindung mit einer Kommunikation über den Edge-Server ist, habe ich nicht weiter analysiert. Interne Verbindungen nutzen schon den Bypass.

Einsatz mit Callpark

Seit Lync 2010 gibt es die Funktion "Parken". Damit kann ein Teilnehmer eine Verbindung für einige Zeit "Parken" und an einer anderen Nebenstelle einfach wieder den Ruf heranholen. Lync vergibt dem Ruf dabei eine "Parknummer", aus einem konfigurierbaren Bereich (Siehe Call Park). Nun bietet es sich ja gerade zu an, auf einem mobilen Gerät den Ruf fortzusetzen. Natürlich könnte ich das Gespräch an mein DECT-Telefon weiter leiten. Aber viel schicker ist doch das parken und der Pickup am DECT-Telefon. Denn dann bleibt mein Status auch auf "Am Telefon", weil die SPS den Status weiter pflegt.

Allerdings unterstützen nicht alle SIP-Geräte die Verwendung von Sonderzeichen. Bei Lync ist es kein Problem, z.B. "#200-#219" als Parkbereich zu definieren. Auf jedem Lync Client und Aries-Phone können sie dann problemlos die Parknummer anrufen und den Ruf heranholen. Die Verwendung der Sonderzeichen wird gerne gewählt, um eine Normalisierung durch den Lync Dialplan zu unterbinden, keine Rufnummern zu belegen und einen Abruf von extern zu verhindern.

In Verbindung mit der SPS/FreeSWITCH-Plattform ist dies aber scheinbar nicht möglich. Der Versuch einen Ruf auf der "#218" abzuholen, war leider nicht möglich.

In so einem Fall muss man einen Bereich der eigenen Nummern für CallPark reservieren und im Lync Dialplan die Normalisierung entsprechend anpassen, dass daraus dann keine E.164-Nummer wird.

Test mit PhonerLite oder XLite

Ehe ich dann mit SIP-Telefonen oder gar einer Aastra DECT-Basis loslege, nutze ich erst mal einen SIP-Client wie "PhonerLite". Der läuft auf Windows, ist einfach per Tastatur zu befüllen (statt per 10er Pad) und Netmon kann den unverschlüsselten Verkehr direkt mitschneiden. Hier eine exemplarische Einstellung in PhonerLite

.

Analog können Sie auch in X-LITE eine Verbindung konfigurieren. Hier sind deutlich weniger EinstellMöglichkeiten:

Dennoch reicht auch das, um eine Registrierung und Verbindung zur SPS herzustellen

Status und Logging

Die Protokollfunktionen des SPS-Systems sind ziemlich ausgeprägt. Das System protokolliert für verschiedene Module relativ umfangreich die Aktivitäten auf der lokalen Festplatte mit. Die Logs sind über die Weboberfläche einsehbar. 

Es ist relativ einfach, die Textdateien direkt auf dem Server zu finden und mit anderen Programmen zu überwachen, z.B. über einen Tail oder auch mit anderen Monitoring-Lösungen.

Interessant ist auch der Call Status, der eine Übersicht über die Verwendung und die aktuell aktiven Calls anzeigt. Die Zahlen hier sind nicht repräsentativ, da es sich um eine Testinstallation handelt.

Optional: Devices

Die Pflege von Endgeräten ist nicht zwingend erforderlich. Allerdings können so verschiedene Endgeräte sogar provisioniert werden. Mit dieser Funktion habe ich mich aber noch nicht weiter beschäftigt. Aber das wird dann eine Aufgabe, wenn wirklich mehrere Geräte genutzt werden sollen.

Besonderheit Anmeldung

Bei den Versuchen mit dem Grandstream ATA-Router 502 SIP ist mir eine unstimmigkeit aufgefallen. In der Verwaltung der Benutzer taucht ein "Login Name" auf. Hier "694@netatwork.de". Dieser Name steht auch im Titel des Fensters, wenn man den Benutzer bearbeitet.

Allerdings darf dieser Name so nicht als "Anmeldename" auf einem Client angegeben werden. Hier ein Versuch einer Registrierung mit dem kompletten Namen wie in der GUI angezeigt.

- SIP: Request: REGISTER sip:192.168.100.64 SIP/2.0
  - SipParser: Request: REGISTER sip:192.168.100.64 SIP/2.0
   + RequestLine: REGISTER sip:192.168.100.64 SIP/2.0
   - RequestHeaders: 
    + Via: SIP/2.0/TCP 192.168.100.67:5060;branch=z9hG4bK1503226298;rport;alias
    + From: <sip:694@192.168.100.64;user=phone>;tag=1376671466
    + To: <sip:694@192.168.100.64;user=phone>
      CallID: 1403452001-5060-1
    + CSeq: 2001 REGISTER
    + Contact: *
    - Authorization:
       scheme: Digest userName: "694@netatwork.de"
       Realm: "192.168.100.64"
       nonce: "d6dbf706-3646-4fe6-a367-7edee68b1600" uri: "sip:192.168.100.64"
       Response: "9b82f1e11950eeb987f7cbca2613486c"
       Algorithm: MD5
       cnonce: "11506878"
       QualityOfProtection: auth
       nc: 00000001

Im Application-Log der SPS findet man aber dann doch die lapidare Meldung:

Ignorieren Sie einfach den Domainteil und nutzen Sie als Anmeldename immer nur den userpart vor dem "@"-Zeichen.

Hinter den Kulissen

Natürlich hat mich interessiert, wie die interne Kommunikation vonstatten geht. Das Bild am Anfang dieser Seite ist ja so nicht in einer Dokumentation zu finden. Sysinternals "Procmon" ist ein sehr effektives Werkzeug, um zu sehen, welche Prozesse miteinander sprechen. Hier einmal der Mitschnitt auf dem SPS-Server, wenn ein SNOM Telefon über den SPS ohne Media Bypass mit einem HT502 eine Audioverbindung aufbaut. Auch wenn dies nur ein Ausschnitt ist, können Sie verschiedene Kommunikationswege sehen:

In dem Bild sehen sie mehrere Verbindungen: Am besten orientieren Sie sich an den Ports der letzten Spalte. Ich beschränke mich auf die interessanten Ziel-Ports. Alle anderen Ports sind dynamische Quellports

Port Quelle Ziel Beschreibung

15061/TCP

Lync Server

SPSLync

Der Port 15061 ist als "Trusted Application" in Lync definiert. Über den Weg hat der Lync-Server über UCMA den SpsLync angesprochen. Der Port 61031 ist dabei der "HighPort" des Lync, der die Verbindung initiiert hat.

5062/TCP

SPSLync

HT502

Der HT502 ATA-Adapter wurde so eingestellt, dass er auf Port 5062 eingehende SIP-Verbindungen annimmt. Der SPSLync sendet über den Weg also den INVITE zum HT502

5060/TCP

HT502

SPSLync

Der HT502 ATA-Adapter seinerseits baut eine Verbindung zum SPS-System über den normalen SIP-Port 5060 auf

Und hier dann die Audiodaten als UDP-Pakete. Man muss aber schon genau hinschauen, um all vier Verbindungen zu sehen:

Es ist in einer Lync Umgebung nicht üblich, dass zum senden und empfangen die gleichen Ports verwendet werden. (Siehe auch Early Media, MRAS Edge,ICE) und die dortige Beschreibung zu "Candidates". Das gleiche Bild dann auch im Netmon. Hier eine Verbindung ohne MediaBypass, bei der das SPS-System (192.168.10.64) mit dem HT502 (192.168.100.67) über RTP eine Audioverbindung betreibt. Als Codec kommt G711 zum Einsatz.

Eindruck

Einfach genial. Keine Zusatzhardware, funktioniert auch als VM, kann als B2BUA problemlos laufen und der Status des Telefons auf der "anderen Seite" ist in Lync akkurat gepflegt. für "Microsoft Systemhäuer" ist natürlich PHP und Apache wieder eine zusätzliche Komponente, die nicht über Windows Update gepatched wird und gesondert zu verwalten ist. Es wäre nett, wenn der Apache per Default nur per Localhost erreichbar wäre. Aber wer eine "sichere Umgebung" benötigt, weiß auch um, diese EinstellMöglichkeiten und wird sich sowieso nicht auf die Herstellerdefaults verlassen.

Schade nur, dass die klassischen SIP oder analogen Endgeräte einfach in ihrer Funktion beschränkt sind. Sie können nämlich z.B. nicht...

  • ... den Status der anderen Lync Benutzer anzeigen
  • ... auf IMs reagieren oder antworten.

Aber was soll man schon von "dummen Telefonen" erwarten. Die Funktion eines Lync Client oder einen Lync Mobile Clients kann so nicht bereit gestellt werden. Aber wer immer noch "klassisch" telefonieren will, kann so sehr gut in Lync eingebunden werden. Einzig die Erfordernis der lokalen SQL-Instanz kann ich mir nicht erklären.

Weitere Links