RTCP und Session-Timeout

Diese Seite kann interessant sein, wenn Sie Lync über einen SIP-Trunk zu Cisco oder z.B. der Telekom verbinden. Das Problem kann sogar existent sein, wenn Sie einen Session Border Controller dazwischen haben. Aber eins nach dem anderen.

Signalisierung (SIP) und Audio (RTP)

Bei einem klassischen Telefon war die Welt noch einfach: Es gab zwei Drähte, durch die per Strom die Sprache übertragen wurde und die auch zur Übermittlung der Rufnummern per Impulswahl oder Tonwahl verwendet wurden. Sobald der Hörer abgehoben wurde, hat der "Gabelumschalter" den Stromkreis geschlossen und der Schleifenstrom hat der Vermittlungsstelle signalisiert, dass die Leitung "aktiv" ist.

Bei VoIP wird für die Signalisierung und die Audio-Übertragung zwar das gleiche Medium (Ethernet und IP) genutzt, aber es sind unterschiedliche Connections. Die SIP-Signalisierung erfolgt über 5061 oder 5060 TCP, manchmal auch per UDP aber für Audio versuchen die meisten Clients direkt die Daten per UDP zu senden. UDP ist einfach, billig und wenn bei VoIP-Audio mal ein Paket verloren geht, dann lohnt es sich nicht, dieses erneut anzufordern. Daher ist UDP besser als TCP geeignet. Bei TCP würde es aufgrund der Sequenznummern und dem Handshake sofort auffallen, wenn ein Paket verloren geht oder die Verbindung unterbrochen wird. Selbst bei "Ruhe"-Verbindungen wird in der Regel alle 2 Minuten ein "Lebenszeichen" gesendet.

Bei Audio über UDP muss natürlich auch eine "Kontrolle" erfolgen, da der Lync Server zwar die Signalisierung (SIP) mitbekommt aber der Registrar nicht in der Audioverbindung involviert ist. Das kann am Server komplett vorbei laufen (Stichwort MediaBypass) oder nutzt andere Dienste wie den Mediation Server oder die Konferenz-MCU (AVMCU).

RTP/RTCP und 30 Sek

Aus dem Grund gibt es mit RTCP einen Rückkanal für jeden Audiokanal, über den der Empfänger dem Sender der Daten ein Feedback zur Qualität etc. gibt. So kann der Sender seine Sendeparameter anpassen (z.B. größere Pakete, Umschaltung auf Error-Correction, Codec-Wechsel etc.) und der Sender sieht vor allem, dass der Empfänger noch "hört". Das ist essentiell, denn ohne Rückmeldung kann der Sender nicht wissen, ob seine UDP-Pakete einfach ungehört verhallen. Es gibt gleich mehrere Situationen, in denen der RTP-Datenstrom Ausbleibt

  • Verbindungsverlust oder Firewall oder Virenscanner
    Wenn keine IP-Verbindung mehr besteht, dann ist natürlich klar, dass nichts mehr ankommt. Das kann ein "gezogenes Kabel" sein aber auch eine unterbrochene WiFi-Verbindung oder andere Störung. Es gibt aber auch perfidere Einflüsse, z.B. wenn Provider, Firewalls oder auch Virenscanner eine RTP-Kommunikation als "unerwünscht" ansehen und blockieren. Das passiert besonders gerne in Netzen, bei denen der Betreiber die Umgebung seine TK-Struktur unterbinden will. Häufig also bei "kostenfreiem WiFi" oder auch Mobilfunkverbindungen, bei denen SIP in einigen Verträgen nicht erlaubt ist.
  • "Stille Erkennung" (Siehe Silence)
    Der Sender erkennt, dass nicht mehr gesprochen wird oder das Mikrofon "Stumm" geschaltet ist. Und sendet nun keine 50 Audiopakete a 160byte für 20ms Audio, sondern reduziert die Rate und sendet nur noch ein "CN8000"-Paket. Das kann die Gegenseite schon verstehen, aber nicht immer will sie das verstehen und geht davon aus, dass die Audio-Verbindung unterbrochen wurde.
  • Gespräch "halten"
    Wenn Sie ein Telefonat weiter vermitteln und erst mit dem Ziel sprechen wollen, wir der erste Anrufer "gehalten". Diese Meldung kommt per SIP und ist nicht im RTP-Strom zu sehen. für das Gateway hört der Anruf dann plötzlich auf.
  • Lync Konferenz
    Auch wenn die Audiogegenstellt die AVMUC ist, kann der Fall auftreten, dass ein Teilnehmer sein Mikrofon "stumm" geschaltet hat oder der Konferenzleiter alle aus Stumm stellt. Wird dies nicht korrekt umgesetzt, dann kann ein System irrtümlich die Verbindung als beendet ansehen.

Auch in Verbindung mit der  kann es passieren, dass eine Seite auch länger nichts mehr sendet und nur die RTCP-Daten quasi die Existenz der Verbindung erhalten. Insofern ist RTCP eine sehr gut Einrichtung.

Bei Lync Clients und Servern ist RTCP per Default aktiv. Um so erstaunlicher ist es, dass es SIP-Trunks gibt, bei denen diese Funktion der Verbindungssicherung nicht genutzt werden kann. Sie senden einfach keine RTCP-Pakete. In Verbindung mit dem Lync Mediation Server muss man hier dann die Einstellung abschalten, dass er auf RTCP-Pakete wartet.

A media time-out occurs on the Microsoft Office Communications Server 2007 R2, Mediation Server if no Real-Time Transport Protocol (RTP) packets or Real-Time Control Protocol (RTCP) packets are received für 30 seconds.
Quelle: 981218 A call is dropped when a media time-out occurs on the gateway side of the Office Communications Server 2007 R2, Mediation Server

Was letztlich bei ihnen "zuschlägt", gilt es heraus zu finden. NetMon hilft ihnen sehr gut dabei. Hier ein Beispiel einer Konferenz (Codec = G722) , in der ich alleine drin bin und dann mein Mikrofon "stumm" geschaltet habe. Und dann wieder aktiviert habe. Gut zu sehen, dass ein einziges "CN"-Paket das Ende angezeigt hat aber dann lange lange einfach nichts mehr gekommen ist. Hier gibt es aber auch kein RTP/RTCP-Timeout, weil Lync in der Konferenz nicht nutzt. Ob jemand in der Konferenz drin ist, lässt sich per SIP-Timeout lösen, im dem ja auch der Befehl "recv only" oder "send only" enthalten ist.

Bei einer "Audio-Verbindung zu einem Gateway" ist es etwas anders. Hier kommen sehr wohl RTCP-Pakete dazu. Hier am Beispiel eines eingehenden Calls von einem Audiocodes Gateway zu einem Lync Mediation Server:

Gut ist hier auch zusehen, dass dank Early Media die RTP und RTCP-Pakete schon direkt nach dem INVITE losgehen, nachdem ein "183 Session Progress" in Zeile 5003 schon die Kandidaten gemeldet hat. MediaBypass ist hier nicht aktiv, vermutlich weil der angerufene Anwender dies nicht anbietet oder z.B. per Edge aus dem Internet arbeitet und daher der Mediation Server vermittelt.

SBC und RTP
Wenn eine SBC in der Mitte ist und sie den Audiostrom ((RTP) transcodieren muss, dann könnte Sie auch RTCP-Pakete in Richtung Lync unterstützen, selbst wenn die Gegenseite dies nicht mach

RTP und 15 Minuten

Gerade bei SIP-Anbindungen über Firewalls und NAT-Router ist es für die Firewall wichtig zu erkennen, dass da eine Verbindung immer noch aktiv ist. Dieser Session-Timeout ist von NAT zu NAT-Router unterschiedlich. Siehe dazu auch TCP Session Timeout. Das gleiche Thema trifft natürlich auch auf UDP zu. Hier gibt es dann zwei Probleme, die beide meist bei Firewalls und NAT-Routern auftreten, die weniger als 15 Minuten als Session Timeout nutzen, da 900Sekunden oft der Default bei einigen Verbindungen ist

  • SIP Session Timeout
    Ein Client baut eine Session per SIP zu einem Server auf der anderen Seiten der Firewall/NAT-Router auf. Über diesen bestehenden TCP-Kanal sendet die Gegenseite natürlich auch eingehende Pakete, z.B. einen eingehenden Anruf. Wenn der TCP-Kanal aber durch die Firewall schon unterbrochen ist, dann kommt der Ruf nicht an
  • RTP-Session Timeout
    Vergleichbar verhält es ich mit UDP -Verbindungen per Audio. IN der Regel baut ein Client ja über eine ausgehende Verbindung den Kanal auf und die Gegenseite sendet auf den gleichen Port ihre Antwort. Wenn nun aber die interne Seite keine Daten mehr sendet, z.B. Comfort Noise, dann könnte die Firewall irgendwann auch die eingehenden Pakete verwerfen.

Solche Fehler sind nicht immer einfach zu ermitteln, da sie solchen Problemen fast nur per Paketanalysen mit Wireshark auf die Spur kommen und idealerweise natürlich vor und hinter dem fraglichen Device mitschneiden. Das ist aber meist nicht möglich.

Session Timeout

Parallel zu RTCP gibt es aber auch noch im SIP-Protokoll ein Session Timeout, d.h. im SIP-Paket wird mit übermittelt, wie lange die Session gültig ist. Kurz vor dem Ablauf kann dann jeder Partner die Session mit einem "UPDATE" oder einem INVITE" wieder erneuern. Das ist ein ganz normaler Prozess, den der Lync Client z.B. auch gegenüber dem Lync Server macht, um seine Registrierung immer wieder zu erneuern. Wenn ein Client sich nicht mehr "abmelden" kann, weil z.B. die Netzwerkverbindung verloren geht oder unterbrochen wurde, dann wird der Server nach Ablauf dieses Timeouts diesen Endpunkt aus seiner Liste löschen.

Bei einer Audio-Verbindung wird natürlich auch mit einem "INVITE" die Verbindung gestartet und auch hier pflegen die beiden Parteien eine "Session". Auch diese Absicherung ist per Default aktiv. Das sehen Sie schon bei "Register" eines Clients, da der Server hier mit einem 200OK antwortet aber eine Expiration mitliefert (gekürzt):

SIP/2.0 200 OK
ms-keep-alive: uAS; tcp=no; hop-hop=yes; end-end=no; timeout=300
Authentication-Info: TLS-DSK ...
From: "Carius, Frank"<sip:frank.carius@netatwork.de>
To: <sip:frank.carius@netatwork.de>
CSeq: 7 REGISTER
presence-state: register-action="refreshed";primary-cluster-type="central";is-connected-to-primary="yes"
Expires: 7200
Supported: ms-keepalive-deregister

Hier steht mit dem "Expires: 7200" die Information vom Server an den Client, dass er diese Verbindung für 7200 Sekunden (= 2 Stunden) aufrecht erhält. Der Client muss also dafür sorgen, nach spätestens 2 Stunden einen Refresh zu machen.

Etwas anderes ist es aber bei einem INVITE

INVITE sip:+495251304613@10.1.1.1;User=phone SIP/2.0 
From: "Frank Carius" <sip:+495251304613;ext=613@msxfaq.de;User=phone>
To: <sip:+495251304613@10.1.1.1;User=phone> 
CSeq: 1 INVITE 
Contact: <sip:192.168.207.5:5060;ms-opaque=5ad073ec200ed38b> 
Supported: 100rel,timer 
Session-Expires: 1800 
Min-SE: 90 User-Agent: Mediant 1000 - MSBG/v.6.60A.234.004 
Content-Type: application/sdp 
Content-Length: 377 
 
v=0 ...

Hier sieht man schon beim INVITE den Eintrag "Session-Expires", der vorgibt, in welchem Zeitrahmen die Session "erneuert" werden muss, damit die Verbindung bestehen bleibt. 1800 Sekunden (=30 Minuten). Manchmal sehen Sie auch, dass ein Gateway einen Session-Expires mit der Option "refesher=" sendet.

SIP/2.0 200 OK
From: "Carius, Frank"<sip:frank.carius@netatwork.de>
To: <sip:+495246700971@netatwork.de;User=phone>
CSeq: 1 INVITE
Call-ID: 6e4d1de39f4c43c6aebafc6b3ec5b7b2
Contact: <sip:nawlync001.netatwork.de@netatwork.de;gruu;opaque=srvr:MediationServer:xxx;grid=7>
Supported: timer
Content-Type: application/sdp
Allow: ACK
Server: RTCC/5.0.0.0 MediationServer
Allow: CANCEL,BYE,INVITE,REFER,NOTIFY,PRACK,UPDATE
Session-Expires: 1800;refresher=uas
Min-SE: 90

Bislang habe ich hier nur gesehen:

  • Session-Expires: 1800;refresher=uac
    Der Client (also der die Verbindung initiiert hat) muss sich drum kümmern die SIP-Transaction immer wieder am Leben zu erhalten
  • Session-Expires: 1800;refresher=uas
    Hier wird die Aufgabe auf die andere Seite delegiert, d..h. in dem Fall muss Gateway die Transaction immer wieder am Leben erhalten

Das Problem dabei ist, dass zumindest der Lync Mediation Server damit nicht umgehen kann. Wenn Sie also einen SIP-Trunk zu einem Provider aufgebaut haben und dieser ihnen ein "Session-Expires: 1800;refresher=uac" sendet, dann wird Lync den Call nach ca. 30 Minuten mit einem Byte abbauen anstatt einen INVITE oder UPDATE zu senden. So gesehen bei einem Kunden mit SIP-Trunk zur Telekom.

Parameter auf dem Lync Trunk

Nachdem Sie nun das Handwerkszeug haben, können Sie ja die Einstellung auf dem Lync Trunk oder global per PowerShell ändern. Leider ist per GUI nur ein Teil erreichbar. folgende Parameter sind dabei relevant

  • RTCPActiveCalls (Default: $True)
    Definiert, ob der Mediation Server vom Gateway eingehende RTCP-Pakete erwartet. Ein "$true" führt dazu, dass der Mediation Server eingehende RTCP-Pakete erwartet und wenn diese Ausbleiben, geht er von einem Verlust der Verbindung aus und baut diese auch per SIP ab
  • RTCPCallsonHold  (Default: $True)
    Wenn ein Telefonat "gehalten" wird, werden normalerweise keine Audiodaten übertragen (aktiviertes MoH ist einen Ausnahme). Ist der Wer auf True, dann werden vom Mediation Server dennoch RTCP-Pakete gesendet.
  • EnableSessionTimer (Default:$False)
    Aktiviert die Funktion, dass Lync einen Sessiontimer einsetzt, d.h. einen Verfallszeit für Sessions mit übermittelt. Wird der Wert auf "$false" gesetzt, sendet Lync selbst keine SIP-Pakete mit einem Sessiontimer. Sollte die Gegenseite aber einen ReINVITE oder Update senden, dann wird Lync darauf reagieren. Lync wird bei einem "$false" aber nicht selbst ein UPDATE oder ReINVITE senden.
    Sobald Sie RTCP-Funktionen abschalten, ist der SessionTimer ein Notbehelf, um Dauerverbindungen zu vermeiden. Lync weist Sie auch darauf hin.
  • MediaBypass
    Beim MediaBypass geht RTP und damit auch RTCP gar nicht durch den Mediation Server und die Einstellungen wären wirkungslos. Trotzdem müssen Sie genau dann RTCPActiveCalls auf "$false" setzen, damit der Mediation Server nicht auf RTCP-Pakete wartet und die Verbindung unterbricht. Genau genommen hätte Microsoft dies auch selbst implizit umsetzen können.
  • EnableReferSupport und ConcentratedTopology
    Die meisten SIP-Trunks unterstützen kein Refer und erlauben auch nicht, dass die Audio-Verbindungen anderen Wege gehen. Sie selbst werden in der Regel aber auch nicht die IP-Adresse beim Provider von allen Clients erreichbar machen wollen, so dass Sie Refer=$false und "CentralizedMediaProcessing=$True problemlos setzen können. Anders sieht es erst aus, wenn Sie z.B. selbst einen SBC - Session Border Controller einsetzen.

Die meisten Provider für VoIP-Links unterstützen kein RTCPActiveCalls, so dass Sie dieses fast immer auf "$False" setzen müssen, damit der Mediation Server die Verbindung nicht vorschnell (nach ca. 10Sek) abbricht.

Hinweis:
Das Abschalten der RTCP Checks unddas Abschalten des SessionTimers birgt ein sehr hohes Risiko, dass Ressourcen für Audio-Verbindungen genutzt werden, die gar nicht mehr aktiv sind. Diese Konfiguration sollte nur in Ausnahmefällen genutzt werden. RTCP ist natürlich der präferierte Weg, wenn die Gegenstelle dies unterstützt. Zumindest SessionTimer sollten möglich sein.

Parameter bei OCS 2007R2

Bei OCS2007R2 Mediation Server können Sie noch nicht mit der PowerShell diese Werte einstellen. Hier muss zuerst der OCS2007R2 auf den aktuellen Patchstand angehoben werden, damit er die neuen Parameter in der XML-Datei (MediationServerSvc.exe.config) versteht

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="forwardDisplayName" value="True" />
    <add key="GatewayIgnoreMediaTimeout" value="True" />
    <add key="GatewaySessionTimer" value="False" />
  </appSettings>
</configuration>
  • GatewayIgnoreMediaTimeout
    Der Eintrag "GatewayIgnoreMediaTimeout" auf "True" deaktiviert die Beendigung der Verbindung, wenn keine Audiodaten per RTP mehr kommen. Er steht per Default (z.B. wenn er nicht definiert ist) auf False
  • GatewaySessionTimer
    Der Eintrag GatewaySessionTimer steuert das Verhalten beim Auftreten eines SIP-Timeouts. Wenn er auf "False" steht, dann ist der Timer nicht aktiv, d.h. eine Verbindung bleibt auch länger stehen.

Weitere Links