SIP und Weiterleitungen

Weiterleitungen sind doch was Schönes: und sie sind sehr oft im Einsatz, ohne dass es direkt auffällt:

  • ... Besetzt (oder abgelehnt)
    Wenn ich gerade nicht mit dem Anrufer sprechen will, kann ich diesen umleiten
  • ... Nicht erreicht
    z.B. wenn ich im Urlaub bin und mein Telefon auf meinen Stellvertreter oder die Voicemail (z.B. Exchange UM) umleite
  • ... Permanent umgeleitet
  • ... inkompatibel (z.B. ISDN Faxanruf auf Analogtelefon)
    Auch das gibt es, z.B. wenn die ISDN Dienstmerkmale nicht zusammen passen.
  • ... auf Mobiltelefon (auch Parallelruf)
    Dies ist oft der Fall, wenn ein Mitarbeiter seinen Platz verlässt und alle Gespräche auf sein Mobiltelefon (GSM oder DECT) weiterleitet.

Umleitungen sind also eine gängige Technik.

Weiterleitung wo ?

Die wenigsten Anwender haben sich aber schon mal Gedanken gemacht, wie die Umleitung technisch realisiert wird. Ich habe mal drei Beispiele herangezogen.

  • Umleitung am Telefon
  • Umleitung an der TK-Anlage
  • Umleitung in Lync

Und das Ganze hat natürlich auch seine Auswirkungen auf die Signalisierung, die Rufnummernanzeige und auch die Abrechnung und Kosten

Beachten Sie dazu auch Rufweiterleitung

Die "Bedeutung" der Weiterleitung

Schauen wir uns einmal eine "Demo-Umgebung" einer mittleren Firma an, welche an zwei Standorten eine TK-Anlage hat, die über eine "Querverbindung" miteinander verbunden sind. Weiterhin gibt es eine parallel aufgebaute Lync-Umgebung, welche über zwei Gateways lokal mit der TK-Anlage verbunden ist. Entsprechende "Leitwege" wurden eingerichtet, dass die Lync Benutzer mit den TK-Teilnehmern und umgekehrt kommunizieren können. Auch der Zugang zum Amt ist möglich.

Losgelöst von der Signalisierung per SIP und QSIG stellt sich hier die Frage, wie die Audio-Daten laufen bzw. laufen sollen.

Partner Option Bewertung

Lync B
PBX B

Über GW-B

Das ist die Zielvorstellung um einen effektiven Weg zu haben

Über GW-M

Dann haben Sie im Routing nicht aufgepasst. Dieser Weg sollte maximal als "Backup"-Weg möglich sind

Lync B
PBX M

Über GW-B

In diesem Fall wird die IP-WAN-Verbindung nicht genutzt aber auf dem Trunk ein Kanal belegt.

Über GW-M

Über Lync Leitwege können Sie so den Audiostrom zum Gateway in München lenken und damit den TK-Trunk entlasten.

Lync M
PBX B

Über GW-B

Auch hier wird das TCP-WAN benutzt und der TK-Trunk entlasten

Über GW-M

Hier wechselt der Audiostrom wieder von Lync zur TK-Welt "vor Ort" und der Rest geht über den TK-Trunk

Lync M
PBX M

Über GW-B

Das wäre ein sehr ungünstiger Weg und sollte per Konfiguration nicht genutzt werden

Über GW-M

Dass lokale Gespräche auch "lokal" bleiben, ist eigentlich selbstverständlich, es sei denn das Gateway ist ausgefallen

Ob Sie nun die Kommunikation zwischen Standorten über das IP-WAN oder die TK-Querverbindung betreiben, ist eine individuelle Frage. Wenn die Querverbindung oft "belastet" ist, kann der neue Weg über den Trunk interessant sein. Andererseits stellt Lync auch Anforderungen an die WAN-Bandbreite und Latenzzeit, so dass die Audioqualität über die TK-Anlage bei HochlastUmgebungen sogar besser sein kann. ISDN-Trunks oder TK-Kopplungen haben eben meist dedizierte garantierte Bandbreiten.

Interessant werden solche Spiele nun auch, wenn Sie mit Konferenzen anfangen und sowohl die RTP-Daten innerhalb Lync zur MTU als auch zur TK-Anbindung leiten müssen. Auch die Optionen mehrere Leitwege um eine Fehlertoleranz zu haben ist erst mal nicht Thema dieser Seite.

Weiterleitung und Übergabe in der TK-Anlage

Sie können sicher das normale Bild, dass ein Teilnehmer A sein Telefon an einen Teilnehmer B weiterleitet. Ruft ein anderer Teilnehmer dann den Teilnehmer "A", dann leitet die TK-Anlage den Ruf an den Zielanschluss um. Interessant ist dabei aber die Frage, wie dies technisch passiert, d.h. welchen Weg die Sprache in der TK-Anlage nimmt.

Besonders wenn es mehrere TK-Anlagen im Verbund sind. Es ist durchaus ein unterschied, ob meine Sprache erst zum Vermittlungsknoten des Teilnehmers A geht und dort über eine "zweite" Verbindung an den Zielanschluss weiter gegeben wird.

Das kostet natürlich zwei Kanäle auf dem Trunk. Dies ist aber die Funktion, wenn das Telefon selbst die Weiterleitung macht, also etwas, was Sie z.B. zuhause in einer FRITZ!Box einstellen können, um Rufe an ihr Festnetz auf einen anderen Anschluss weiter zu leiten. Das "kostet" sie dann in de Regel zwei B-Kanäle, d.h. obwohl kein Telefon an der Box zum telefonieren genutzt wird, sind alle Leitungen belegt.

Im Privatkundensegment mag das noch tolerierbar sein aber in Firmen und besonders bei einer Verbindung von TK-Anlagen ist "Trunk" und die damit verfügbaren B-Kanäle kostbar und teuer. Besser ist es, wenn die gerufene PBX M den Ruf gar nicht annimmt und der PBX B den Hinweis gibt, wohin der Ruf weiter geleitet werden soll:

Das funktioniert idealerweise natürlich auch, wenn eine dritte PBX im Spiel ist und Ein Ruf von PBX-B von der PBX-M auf die PBX-F weiter geroutet wird. Spätestens dann müssen Sie sich aber nicht nur Gedanken machen, wie die PBX-Systeme untereinander den gleichen Dialekt sprechen, sondern auch wie die neue Zielrufnummer übergeben wird. Schließlich muss diese für alle Systeme "verständlich" sein. Daher nutzen viele "Verbundanlagen" intern eine Anlagenkennziffer (oder eine 8X) vor der eigentlichen Teilnehmernummer, die zwar auch von Anwendern als "Querwahl" gewählt werden kann. primär ist es aber eine erforderliche Funktion, um in einem Verbund eindeutige Rufnummern zu haben.

Es ist natürlich klar, dass diese Rufnummern in alle Richtungen wieder normalisiert werden müssen, z.B.:

  • Abgehende Rufnummer zum Amt
  • Rufende Nummer einer Weiterleitung
  • Anzeige der Weiterleitung im Telefondisplay

Und natürlich muss auch ein Lync-Gateway in der Umgebung dann diese internen "Anlagenkennziffern" entsprechend addieren oder entfernen. Und wer ein Telefon mit "Display" hat, wird hier natürlich auch eine korrekte Anzeige sehen wollen. Das betrifft sowohl den Anrufer dem eventuell die Weiterleitung gemeldet werden soll als auch der gerufene Teilnehmer, dass der Ruf über eine Weiterleitung bei ihm angekommen ist. Alles Funktionen die früher bei "Heb-Dreh-Wählern" der analogen Technik nicht möglich war.

Weiterleitung und Übergabe in der Lync Welt

Auch in der VoIP-Welt gibt es natürlich "Weiterleitungen". Sie können das in Lync recht einfach konfigurieren.

Und auch der gerufene Teilnehmer kann erkennen, ob der Ruf über eine Weiterleitung, eine Team-Anrufergruppe oder eine Responsegruppe angekommen ist. (Hier das Bild einer manuelle Übergabe)

Entsprechend gibt es auch im SIP-Protokoll entsprechende Möglichkeiten, einen Ruf nicht einfach durch ein "INVITE" an eine andere Stelle zu routen, sondern mit zusätzlichen Daten zu bereichern bzw. eingehende Rufe mit einem neuen Ziel abzuweisen.

Information über Weiterleitung (181 Call Is Being Forwarded)

Wenn Sie in Lync einen anderen Teilnehmer anrufen und dessen Ruf weitergeleitet wird, dann bekommen Sie z.B. einen "181 Call Is Being Forwarded" als SIP-Message. Das es eine Meldung aus dem 100er-Bereich ist, hat dies keine weiteren Auswirkungen auf den Call selbst. Ihr Client kann diese Information aber nutzen um diese z.B. anzuzeigen. Hier ein Beispiel:

SIP/2.0 181 Call Is Being Forwarded
FROM: <sip:+49160xxxxxxxx@nawm1000.netatwork.de;User=phone>;tag=1c830284876
TO: <sip:+495251304999@192.168.100.100;User=phone>;tag=21a943e3b;epid=95E1CEC903
CSEQ: 1 INVITE
CONTACT: <sip:NAWLYNC001.netatwork.de:5068;transport=Tcp;maddr=192.168.100.100>
SERVER: RTCC/4.0.0.0 MediationServer

Hier hat der Lync Mediation Server diese Meldung generiert. Der Ruf wird aber nicht physikalisch umgeroutet. Es ist nur eine Statusmeldung, wenn der gerufene Teilnehmer den Anruf selbst übergibt

Referred-By

Aber auch beim dem Teilnehmer, der den weitergeleiteten Ruf erhält, tut sich etwas. Der sollte ja auch "sehen", wer den Ruf an ihn weiter geleitet hat. In der SIP-Welt kann er das beim "INVITE" erkennen. Hier ein Beispiel eines Rufs, der auf meine Festnetznummer bei Net at Work gegangen ist und von dort von Lync zum Mobiltelefon weiter geleitet wurde.

Der INVITE zum Amt enthält als zusätzliche Information die Rufnummer, von der die Weiterleitung kommt. Diese Information ist auch für Exchange Unified Messaging wichtig, um die richtige Mailbox gleich zuzuordnen.

Hier noch mal das komplette SIP-Paket:

  Frame: Number = 6, Captured Frame Length = 1072, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-90-8F-23-BB-A1],SourceAddress:[00-26-2D-06-F8-AF]
+ Ipv4: Src = 192.168.100.100, Dest = 192.168.100.107, Next Protocol = TCP, Packet ID = 23084, Total IP Length = 1058
+ Tcp: Flags=...AP..., SrcPort=59880, DstPort=5060, PayloadLen=1018, Seq=889750563 - 889751581, Ack=3212477566, 
    Win=256 (scale factor 0x8) = 65536
- SIP: Request: INVITE sip:+4915700000000@nawm1000.netatwork.de;User=phone SIP/2.0
  - SipParser: Request: INVITE sip:+4915700000000@nawm1000.netatwork.de;User=phone SIP/2.0
   + RequestLine: INVITE sip:+4915700000000@nawm1000.netatwork.de;User=phone SIP/2.0
   - RequestHeaders: 
    + From: <sip:+49160xxxxxxxx@netatwork.de;User=phone>;epid=E3E5C6D8EC;tag=86c26099ba
    + To: <sip:+4915700000000@nawm1000.netatwork.de;User=phone>
    + CSeq: 1 INVITE
      CallID: 20821aa6-bf17-46cc-8f76-e984e7321681
      MAX-FORWARDS: 70
    + Via: SIP/2.0/TCP 192.168.100.100:59880;branch=z9hG4bKa76048f2
    + Contact: <sip:NAWLYNC001.netatwork.de:5068;transport=Tcp;maddr=192.168.100.100;ms-opaque=ffb0cd40b4a75336>
      ContentLength: 348
      REFERRED-BY: <tel:+495251304999;ext=613>
      Supported: 100rel User-AGENT: RTCC/4.0.0.0 MediationServer
      ContentType: application/sdp
      ALLOW: ACK
      Allow: CANCEL,BYE,INVITE,PRACK,UPDATE
      HeaderEnd: CRLF
     RequestBody: 
+ Sdp: Request: INVITE sip:+4915700000000@nawm1000.netatwork.de;User=phone SIP/2.0;
     SDP:SessionName=session, Version=0, MediaDescription=audio 7210 RTP/AVP 8 0 18 13 101

Das ist aber keine Umleitung sondern ein INVITE, d.h. eine zweite Verbindung.

Damit diese Funktion möglich ist, ist ein Update des Lync Mediation Servers erforderlich

  • KB 2517730 Update April 2011
  • KB 2599421 Update auf Mediation Server für "Referred-by "
  • 972770 An Update package enables Office Communications Server 2007 R2, Mediation Server to include a diversion header in the re-invite after the server processes a 302 redirection
  • 2500421 The call history information is incomplete in Lync Server 2010 Mediation Server
  • 2517730 The call history information is incomplete in Lync Server 2010 Mediation Server
  • The Session Initiation Protocol (SIP) Referred-By Mechanism
    http://www.faqs.org/rfcs/rfc3892.html

Nach dem Update ist auf dem Mediation Server die XML-Datei (C:\Program Files\Microsoft Lync Server 2010\Mediation Server\MediationServerSvc.exe.config) zu erweitern.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="nawm1000.netatwork.de.ReferredBySupported" value="true"/>
  </appSettings>
  <runtime>
    <generatePublisherEvidence enabled="false"/>
  </runtime>
</configuration>

Erst durch den Eintrag "ReferredBySupported" auf "true" wird der Mediation Server angewiesen, diese Information auch an das Gateway oder den SIP-Trunk weiter zu senden. Diese Einstellung ist pro Gateway durchzuführen.

Umleitung mit 302 MOVED TEMPORARILY und SIP CONTACT

Nun kommen wir zu den "richtigen" Umleitungen, bei denen der Anruf tatsächlich von der Quelle her umgeleitet wird. Es gibt zwei Möglichkeiten, wie per SIP ein Ruf umgeleitet werden kann. REFER oder "302-Meldung". Schauen wir uns erst mal eine 302-Meldung an. Im folgenden Beispiel ruft der LyncTN1 eine Rufnummer des PBXTN1 an, der aber den Ruf auf PBXTN2 weiter geleitet hat. Hier erst mal der erste INVITE (gekürzt)

Lync Mediation Server -->>> VoIP Gateway:
INVITE sip:+495251304PBXTN1@ip.voice.gate.way;User=phone SIP/2.0
FROM: "LyncTN1"<sip:+495251304LYNCTN1@lync.netatwork.de;User=phone>;epid=CA922A39B2;tag=af8c744e95
TO: <sip:+495251304PBXTN1@ip.voice.gate.way;User=phone>
VIA: SIP/2.0/TCP ip.lync.med.server:54036;branch=z9hG4bK73c1388
CONTACT: <sip:lync.netatwork.de:5068;transport=Tcp;maddr=ip.lync.med.server;ms-opaque=2e3fe80bde8bb274>
CONTENT-LENGTH: 342
SUPPORTED: 100rel User-AGENT: RTCC/4.0.0.0 MediationServer
CONTENT-TYPE: application/sdp

Nicht aufgezeichnet habe ich nun die Feinheiten der ISDN-QSIG-Kommunikation, mit der aus dem ISDN der Ruf abgelehnt wird und über eine Facility-Information "Deflection" eine neue Zielnummer übergeben wird. Die neue Zielnummer ist hier "CPN-PBXTN2". Dies sollte eine gültige SIP-URI sein, was aber nicht jede TK-Anlage oder Gateway hin bekommt. Auf jeden Fall generiert hier das VoIP-Gateway eine 302-Antwort an den Lync Server.

VoIP Gateway -->>>  Lync Mediation Server
SIP/2.0 302 Moved Temporarily
FROM: "LyncTN1"<sip:+495251304LYNCTN1@lync.netatwork.de;User=phone>;epid=CA922A39B2;tag=af8c744e95
TO: <sip:+495251304PBXTN1@ip.voice.gate.way;User=phone>;tag=1c96368575
VIA: SIP/2.0/TCP ip.lync.med.server:54036;branch=z9hG4bK73c1388
CONTACT: <sip:CPN-PBXTN2@ip.de.gate.way:5060;transport=tcp>
SUPPORTED: em,timer,replaces,path,resource-priority
ALLOW: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
SERVER: Audiocodes-Sip-Gateway-Mediant 1000
Diversion: <tel:CPN-PBXTN1>;reason=unconditional;counter=1
Reason: SIP ;cause=302 ;text="302 Moved Temporarily"

Im Feld "CONTACT" ist die Rufnummer hinterlegt, an die der Ruf weiter geleitet wird.

Beachten Sie hier auch das Feld "Diversion", welche die erste Rufnummer enthält. Dieses Feld benötigt Exchange 2010 UM zur Ermittlung der Voicemailbox".

"302 Moved Temporarily" kommen auch in Verbindung mit "Redirect-Servern" zum Einsatz. Der Client sendet seinen INVITE immer zu diesem Zwischensystem, welches dann die tatsächliche Adresse im 302 zurück gibt, unter der der gewünschte Kontakt zu erreichen ist.

Es ist Aufgabe des Gateways die Kontaktadresse so zu formen, dass es eine gültige SIP-URI wird.

Hinweis:
Die Adresse, die im "CONTACT" des Header gesendet wird, wird von Lync NICHT mehr normalisiert. Laut SIP Spezifikation muss der Client diese Adresse genau so verwenden. Es obliegt also dem Gateway, welches den 302 generiert, dass die SIP-URI korrekt ist.

Das steht so auch in der RFC 3261

21.3.3. 302 Moved Temporarily
   The requesting client SHOULD retry the request at the new address(es)
   given by the Contact header field (Section 20.10).  The Request-URI
   of the new request uses the value of the Contact header field in the
   response.
 
Quelle: RFC 3261 SIP: Session Initiation Protocol http://www.ietf.org/rfc/rfc3261.txt

Das hat leider auch den Nachteil, dass ein Ruf von Lync nach TK mit Weiterleitung zu Lync niemals vom Lync dann wieder als "intern" verstanden wird, sondern immer über das Gateway raus und wieder rein geht, d.h. zwei Kanäle verwendet werden oder das Gateway dies "umbiegt".

Lync Mediation Server  --->>>  Lync Mediation Server
INVITE sip:CPN-PBXTN2@INVITE sip:CPN-PBXTN2@ip.lync.med.server:5068;transport=tcp SIP/2.0
FROM: "LyncTN1"<sip:+495251304LYNCTN1@lync.netatwork.de;User=phone>;epid=CA922A39B2;tag=af8c744e95
TO: <sip:CPN-PBXTN2@ip.lync.med.server:5068;transport=tcp>
VIA: SIP/2.0/TCP ip.lync.med.server:54037;branch=z9hG4bKbaaedac3
CONTACT: <sip:lync.netatwork.de:5068;transport=Tcp;maddr=ip.lync.med.server;ms-opaque=2e3fe80bde8bb274>
SUPPORTED: 100rel User-AGENT: RTCC/4.0.0.0 MediationServer
CONTENT-TYPE: application/sdp
ALLOW: ACK
Diversion: <tel:CPN-PBXTN2>;reason=unconditional;counter=1

Die Folgepakete sind nun nicht mehr interessant, da es ja ein normaler INVITE ist.

REFER-Methode

Eine zweite Methode ist die Weiterleitung über einen "REFER. Refer kommt zum Einsatz, wenn Tn-A bereits mit Tn-B verbunden ist und Tn-B eine "Rückfrage" an Tn-C durchführt und dann Tn-A zu Tn-C verbinden will. Dies kommt in der Regel intern von SIP zu SIP-Client zum Einsatz aber kann auch zu Gateways gehen. Hierzu muss aber auf dem Trunk der "REFER"-Support eingeschaltet werden. Dies kann global und pro Trunk erfolgen:

Das ganze geht auch per PowerShell

PS C:\Users\user1> Get-CsTrunkConfiguration

Identity                            : Global
OutboundTranslationRulesList        : {}
SipResponseCodeTranslationRulesList : {}
Description                         :
ConcentratedTopology                : True
EnableBypass                        : True
EnableMobileTrunkSupport            : False
EnableReferSupport                  : True
EnableSessionTimer                  : False
EnableSignalBoost                   : False
MaxEarlyDialogs                     : 20
RemovePlusFromUri                   : False
RTCPActiveCalls                     : True
RTCPCallsOnHold                     : True
SRTPMode                            : Required
EnablePIDFLOSupport                 : False

Entsprechend kann ein Client dann einen INVITE senden, der dann durch einen REFER umgebogen wird. So sieht z.B. ein REFER-Paket aus.

REFER sip:192.168.100.107:5060;User=phone;transport=tcp SIP/2.0
FROM: <sip:+495251304999@192.168.100.100;User=phone>;epid=95E1CEC903;tag=a469aeea3
TO: <sip:+4952467009@nawm1000.netatwork.de;User=phone>;tag=1c140382002
CSEQ: 2 REFER
Call-ID: 140380885128201114258@192.168.100.107
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.100.100:5068;branch=z9hG4bK359c5d6f
CONTACT: <sip:NAWLYNC001.netatwork.de:5068;transport=Tcp;maddr=192.168.100.100;
   ms-opaque=76ad9bc865ddbb69>
CONTENT-LENGTH: 0
REFER-TO: <sip:NAWLYNC001.netatwork.de:5068;transport=Tcp;maddr=192.168.100.100;
   ms-opaque=76ad9bc865ddbb69?REPLACES=cb0835802dd3463daea1fda3cd8a8976%3Bfrom-tag%3D77127d3ed6%3Bto-tag%3D33c98a7da0> User-AGENT: RTCC/4.0.0.0 MediationServer

Im Syslog eines Mediant sieht man dazu passend

(SIPTU#150)REFER State:Connected(140380885128201114258@192.168.100.107)
new GetNewSIPCall created - #138
new AcSIPCallAPI created - #96
Resource StackSession <#35> Allocated
| #38:SIP_REFER_EV(140380885128201114258@192.168.100.107)
New SIPMessage created - #25
(SIPTU#150)GENERAL_RESPONSE_REQ State:Connected(140380885128201114258@192.168.100.107)

202 Accepted
Via: SIP/2.0/TCP 192.168.100.100:5068;branch=z9hG4bK359c5d6f
From: <sip:+495251304999@192.168.100.100;User=phone>;tag=a469aeea3;epid=95E1CEC903
To: <sip:+4952467009@nawm1000.netatwork.de;User=phone>;tag=1c140382002
Call-ID: 140380885128201114258@192.168.100.107
CSeq: 2 REFER
Contact: <sip:192.168.100.107:5060;User=phone;transport=tcp>
Supported: em,timer,replaces,path,early-session,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Audiocodes-Sip-Gateway-Mediant 1000/v.6.20A.027.012
Content-Length: 0

Hier sendet der Mediation Server einen REFER an meinen Audiocodes Mediant. Interessant ist der "REFER-TO" Eintrag, welcher dem TN-C sagt, welcher Call (nämlich der von Tn-B) ersetzt wird. Wenn das Paket bei Tn-C ankommt, dann weiß Tn-C, dass Tn-B die Verbindung von B<->C nach Tn-A "verraten" hat. Das ist die Legitimation für das Replacement des Calls.

Der Mediant antwortet dann mit einem "202 Accepted", was aber nicht die finale Meldung ist, sondern erst eine Vormeldung, die am Ende noch abgeschlossen werden muss.

ISDN Defer, Deflection, Pathreplacement, ECT

Nun haben Sie ja gelernt, dass bei SIP es zwei Wege gibt, einen Ruf umzuleiten. Vergleichbare Verfahren gibt es natürlich auch in der Telefonwelt und insbesondere bei der Kopplung von Anlagen per ISDN mit QSIG. Aber auch hier gibt es Definitionen aber jeder Hersteller kocht doch wieder sein eigenes Süppchen, so dass ich hier sicher keine umfassende und vollständige Erklärung liefern kann. Anscheinend gibt es zwei generelle unterschiedliche Wege

  • EuroISDN: Explicit Call Transver (ECT) (Sowohl bei BRI als auch PRI)
    Beim einfachen Euro-ISDN, welches auch Endgeräte verwenden, kommt diese Funktion zum Einsatz
  • QSIG: PathReplacment (Primär bei PRI-Trunks)
    Sind beide TK-Systeme (Ein Gateway ist auch ein TK-System) per QSIG gekoppelt, dann ist das Path Replacement der Weg den Call möglichst optimiert zu routen.

Bei ISDN werden solche Meldungen als "Facility-Message" übertragen interessant sind dabei:

Opcode SupplServ defining ECMA

4

pathReplacePropose

ECMA-176

5

pathReplaceSetup

ECMA-176

6

pathReplaceRetain

ECMA-176

7

callTransferIdentity

ECMA-178

8

callTransferAbandon

ECMA-178

9

callTransferInitiate

ECMA-178

10

callTransferSetup

ECMA-178

11

callTransferActive

ECMA-178

12

callTransferComplete

ECMA-178

13

callTransferUpdate

ECMA-178

86

pathReplaceInvite

ECMA-176

Interessanterweise sind nicht alle Varianten bei allen ISDN-Protokollen möglich. Die Audiocodes-Dokumentation beschreibt das im Dokument "LTRT-27020 Mediant 1000B Gateway & E-SBC User's Manual Ver 6.4.PDF auf Seite 770". Ich habe mich hier mal auf die in Europa gängigen Protokolle beschränkt:

Protokoll Transfermethode

E1 Euro ISDN
  • ECT (Explicit Call Transfer)
  • INBAND

E1 QSIG
T1 QSIG
  • Single Step Transfer
  • Path Replacement Transfer
  • Inband

Die Details sind in ECMA-Dokumenten zu "ECMA-148 Private Integrated Services Network (PISN)" hinterlegt:

Und selbst dann muss eine Anlage nicht alle Features implementieren. Und die entsprechenden "Abkürzungen" machen das Thema nicht einfacher. Wenn Sie bislang nur mit CLIP, COLP bei der Rufnummernübertragung zu tun hatten, dann kommt nun folgendes noch hinzu:

  • Call Forwarding unconditional (SS-CFU)
  • Call Forwarding Busy (SS-CFB)
  • Call Forwarding No Reply (SS-CFNR)
  • Call Deflection (SS-CD)

Sie sehen also, dass es schon wichtig ist, eine Menge "Testfälle" zu definieren und systematisch abzuprüfen.

Lync und Gateways

Selbst die VoIP Gateways, die ja zwischen ISDN und VoIP vermitteln, sind hier gefordert. So sendet ein Mediant einen REFER, wenn er die Umleitung über das ISDN Leistungsmerkmal "ETSI TS 183 036, Section G.2 (Explicit Communication Transfer – ECT)" bekommt.

Sender die ISDN-Seite aber einen Call Deflection (ETS-300-207-1) für Euro ISDN and QSIG (ETSI TS 102 393), schickt der Mediant ein "302 Moved Temporary". Lync hingegen versteht angeblich nur einen „REFER“, aber wie sie oben sehen, ist er auch bei einem 302 nicht untätig. Er gibt das Paket einfach bis zum Client weiter, welcher dann selbst zusehen muss, wie er aus dem CONTACT-Feld die SIP-URI ermittelt und eine neue Verbindung aufbaut.

P-Asserted-Identity und P-Preferred-Identity

Diese Feld hat NICHTS mit der Thematik Weiterleitung/Umleitung zu tun. Es ist primär dazu da, die Identität des Anrufers zu protokollieren, selbst wenn dieser "anonym" anruft. Die beiden Felder kommen nie gemeinsam vor:

  • P-Preferred-Identity
    Identität die der Client als User Agent (UA) an den nächsten Proxy/Edge sendet. Der Wert könnte gefälscht sein.
  • P-Asserted-Identity
    Der Frontend Server setzt das P-Preferred-Identity durch sein P-Asserted-Identity, wenn er die Identität (z.B. anhand von Anmeldeinformationen) überprüft hat.

Relevant ist das Feld für den Mediation Server, der aus dem P-Asserted-Identity sich die Rufnummer heraus holt, die der dann über ISDN weiter gibt. Hier mal Am Beispiel eines Calls von einem Lync Phone über einen Frontend Server zu einem Mediation Server zum Gateway:

Paket vom Telefon zum Frontend:

Start-Line: INVITE sip:+495251304999@netatwork.de;User=phone SIP/2.0
From: <sip:fcarius@netatwork.de>;tag=a5f0861e3e;epid=d350900107
To: <sip:+495251304999@netatwork.de;User=phone> User-Agent: CPE/4.0.7457.0 OCPhone/4.0.7457.0 (Microsoft Lync 2010 (RC) Phone Edition)
P-Preferred-Identity: <sip:fcarius@netatwork.de>, <tel:+495251304613>

Paket vom Frontend zum Mediation Server:

INVITE sip:+495251304999@10.3.0.61:5070;User=phone;maddr=NAWLYNC001.netatwork.de SIP/2.0
FROM: "Frank Carius"<sip:amst@netatwork.de>;tag=a5f0861e3e;epid=d350900107
TO: <sip:+495251304999@netatwork.de;User=phone>
P-ASSERTED-IDENTITY: "Frank Carius"<sip:fcarius@netatwork.de>,<tel:+495251304613>

Paket vom Mediation Server (Colocated, daher gleicher Name im CONTACT) zum Gateway:

INVITE sip:+495251304999@10.3.0.61;User=phone SIP/2.0
FROM: "Frank Carius"<sip:+495251304613@NAWLYNC001.netatwork.de;User=phone>;epid=0C175BE68A;tag=f4a52b98bf
TO: <sip:+495251304999@10.3.0.61;User=phone>
CONTACT: <sip:NAWLYNC001.netatwork.de:5060;transport=Tcp;maddr=10.3.0.20;ms-opaque=c562ac1bf32b3cd1> User-AGENT: RTCC/4.0.0.0 MediationServer

Aus dem P-Preferred-Identity wird auf dem Frontend ein P-ASSERTED-IDENTITY und auf dem Mediation Server, der ein "Back2Back User Agent" (B2BUA) ist, wird dann ein ganz neuer INVITE erstellt, der als Absender die Rufnummer hat.

Hinweis:
Bei eingehenden Anrufen an Skype for Business darf die P-ASSERTED-IDENTITY nur im ersten "INVITE" vorkommen. Wenn die Information erst im 200 OK kommt, dann terminiert Skype for Business den Anruf mit einem "CANCEL". Im Trace finden sie ein "Provisional was already received. Sending CANCEL"

Der Trace liefert noch ein wenige aussagekräftiges "The operation failed because a message received from the network was not formed properly"

Weiterleitung über Loopback / Zweitruf

Wenn all die Weiterleitung über SIP und ISDN nicht funktioniert, dann spricht natürlich nichts dagegen, wenn ein System einfach einen zweiten Anruf aufbaut. Die erste Verbindung wird dann auf einem System terminiert und von dort ein zweiter Anruf aufgebaut wird.

Als ein Beispiel möchte ich hier den Audiocodes Mediant 1000 als "Loopback" vorstellen. Ich habe damit sowohl ISDN zu ISDN als auch SIP2SIP Weiterleitungen realisiert: für die SIP-Seite habe ich einen Umweg über ISDN gewählt, weil ich keine SIP2SIP Lizenz installiert habe. Aber ein "Session Border Controller" (SBC) ist ziemlich genau eine SIP2SIP umsetzen.

Bei ISDN kommt es z.B.: vor, dass man als Firma einen Teil der Rufnummern weiterleiten will, z.B. zu einem Faxdienstleister. Exemplarisch habe ich das für einen Mediant 1000 auf der Seite AC M1000 in Stichworten beschrieben.

Deflection mit Audiocodes

Achtung: Diese Beschreibung funktioniert erst seit Firmware 6.2.037

Ein Audiocodes Mediant 1000 unterstützt die Umsetzung von QSIQ-Deflection nach SIP "302 Moved temporary". Das ist insbesondere interessant, wenn Ruf von einem Teilnehmer in das andere Netz dort an einen dritten Teilnehmer weiter gegeben werden, z.B. "Lync-A ruft PBX-B und Weiterleitung nach PBX-C."

  1. Lync-A 1111 ruft PBX-B 2222
  2. INVITE +4952513042222 zum Mediant
  3. Mediant normalisiert Nummern
  4. Mediant ruft interne Nebenstelle an der TK-Anlage 832222
  5. PBX sendet ein "Deflection 833333" zurück
  6. Mediant normalisiert "Redirect" Nummer nach +4952513043333@mediant
  7. Mediant sendet "302 Moved temporarily" mit neuer Nummer an Client
  8. Lync Client sendet "INVITE +4952513043333@mediant"
  9. Mediant normalisiert nummer nach 833333
  10. Ausgehender ISDN-Ruf nach 83333

Ganz so einfach ist es natürlich nicht, denn die "Contact"-Adresse muss korrekt zusammen gesetzt werden. Dazu gehört zum einen der "Localpart", d.h. der Teil vor dem "@"-Zeichen aber auch der "DomainPart", d.h. die Hostadresse dahinter.

Leider wird die Adresse vom Client nicht noch mal anhand des Dialplan "normalisiert" oder gar gegen das Lync Addressbuch geprüft. Insofern ist es wichtig, dass die SIP-Adresse im "contact" immer eine gültige Adresse ist.

Man kann in Lync über die MSPL-Skriptsprache SIP-Pakete modifizieren. Es wäre also denkbar, dass man auf dem Frontend Server eine Logik einbaut, welche bei eine, "302 Moved Temporarily" die Contact-Adresse z.B. gegen das Lync Adressbuch abgleicht oder über das Routing vielleicht an eine andere "bessere" Adresse sendet.

Beim Mediant gibt es nun drei Stellen, die für die Normalisierung zuständig sind.

  • Manipulation Redirect Normalisierung Tel->IP
    Diese Tabelle hat seit Firmware 6.2.037 die Bedeutung den „Userpart“ bei der Redirect-Nummer zum „Contact“ in der SIP-Message umzuschreiben. Hier kommt aus der TK-Welt in der Regel eine "kurze" Nummer, die ich hier in E.164 umsetzen muss. Nur verwende ich hier kein "+" sondern ein "R" als erstes Zeichen.



    Die Bedeutung wird ihnen gleich klar werden.
  • Outbound IP Routing (Tel2IP-Routing)
    Diese Tabelle erfüllt originär das Routing vom PSTN zu LYNC, indem es z.B. alle Rufnummern mit einer "+" zum Mediation Server routet. Zugleich ist diese Tabelle aber auch für die umschreibung des Hostparts zuständig. Hier muss man nun natürlich anhand der "Nummer" wissen, dass diese aus dem Rewrite-Anforderung kommt. Ein bestimmtes Prefix ist daher ratsam. Ich nutze z.B. "R" für Rewrite, die natürlich auch in der Tabelle "Manipulation Redirect Normalisierung Tel->IP" entsprechend einer Vorarbeit Bedarf.


    Hier sehen Sie, dass er Rufe an eine SIP-Adresse mit "R" am Anfang an das Gateway 192.168.100.108 routen würde. Nur kommt ein "R" nie in einer echten Rufnummer vor. Dieser Eintrag ist nur für das umsetzen des Hostteils. Durch den Trick mit dem "R" wird dieser Eintrag aber nicht für das Routing von echten Rufnummern verwendet. Die SIP-URI mit dem "R" läuft natürlich bis zum Client. Beim zweiten INVITE kommt dies also auch beim Mediant wieder an.
  • Manipulation Destination IP2TEL
    In dieser Tabelle wird nun auch ein ausgehender Ruf mit dem "R" als Prefix behandelt, als wenn es ein "+" wäre. Damit sind direkter Rufe mit E164-Nummer aber auch Rufe, die mit einem "R" über ein "320 Moved temporary" weiter geleitet wurden.


    Und damit kommt auch der Ruf im Telefonnetz wieder verständlich an.

Interessant wäre natürlich, denn der Audiocodes anhand der Rufnummer dann einen LDAP-Lookup gegen Lync machen würde und lokale Anwender dann nicht nach "draußen" leiten würde. Sicher kann ich für wenige Personen ein Rewrite der Nummer auf einen SIP-Namen machen und dann im Routing diesen SIP-Namen dann auf die Domain umstellen. Aber das skaliert nicht. Andererseits nimmt natürlich auch der Lync Client die Contact-URI für bare Münze und verbindet sich dort hin. Ein Versuch hier einfach den Lync-Server oder den Mediation Server zu verwenden, war aber nicht erfolgreich. Anscheinend löst Lync eine SIP-URI, die auf die Telefonnummer eines Lync-Teilnehmers lautet, nicht gegen Lync auf.

Diese knifflige Situation könnte man in Lync natürlich über ein MSPL-Skript auf dem Lync-Server nachrüsten, der schon den "302 Moved Temporarily" erkennt, den Kontakt dort extrahiert und "passend" routet. Dann würde auch wieder Least Cost Routing innerhalb von Lync möglich sein.

Weitere Links