SIP-Trunk mit OpenScape 4000
Gerade bei Pilot- und Test-Installationen von Skype for Business wird oft gefordert, dass ein paar VMs mit der Evaluierungsversion reichen sollten und Gateways oder SBCs vermieden werden. Net at Work stellt gerne entsprechende Gateways (Hardware oder Software) für solche Projekte bereit aber ein direkter SIP-Trunk zwischen der vorhandenen TK-Technik und dem Testfeld ist zumindest immer ein Versuch wert. So durfte ich vor einiger Zeit eine Skype for Business Installation in Verbindung mit einer Unify OpenScape 4000 (früher als Siemens Hipath 4000 bekannt) umsetzen. Aufgabe war die Kopplung per SIP-Trunk, damit ein paar Pilot-Benutzer und eine SfB Einwahl-Nummer für Konferenzen zur Verfügung standen. Bislang habe ich immer einen Session Border Controller in dem Bild gesehen, da ich schon zu viele "SIP-Dialekte" von TK-Anlagen gesehen habe, insbesondere bezüglich Rufnummernschemata, und auch der Support von Microsoft nur mit zertifizierten Gegenstellen gewährleistet ist.
Auf "Infrastructure qualified for Microsoft Lync - Supported IP-PBXs" (https://technet.microsoft.com/en-us/office/dn788945.aspx) wird OpenScape Voice bei Lync 2013 geführt:
Allerdings ist die Firmware 6 schon älter und der falsch geschriebene Name ("Seimens" statt Siemens) ist ja auch schon Geschichte. Ich werde das Gefühl nicht los, dass Unify nicht wirkliches Interesse an einer weiteren Zertifizierung hat, was ich ihnen natürlich nicht verdenken kann. Würde es ja den Kunden zu einfach machen, einen Mitbewerber zu evaluieren. Die Zukunft wird zeigen, wie sich die Bedeutung verändert hat.
Basiskonfiguration
Entsprechend wurde in der Skype for Business Topologie die IP-Adresse der TK-Anlage als Gateway angelegt und erst einmal auf TLS verzichtet. Damit ist es mit Wireshark und Co deutlich einfacher auf dem Kabel nach Fehlern zu suchen. Es betrifft ja nur den Weg zwischen Mediationserver und TK-Knoten. Allerdings verzichtet man dabei auf Media Bypass, da SRTP nur mit SIP/TLS sinnvoll nutzbar ist. Was hilft eine Verschlüsselung mit SRTP, wenn der Austausch der Encryptionkeys unverschlüsselt per SIP/TCP erfolgt.
Von Seiten der Siemens-Administration habe ich folgenden Screen-Capture der Trunk-Konfiguration bekommen:
Der Fachmanns sieht darauf schon mal, dass TLS möglich wäre aber nicht konfiguriert ist und dass der SIP-Transport auf UDP steht. Ob das geht? Zudem gibt es keinen Hinweise, wie die Rufnummern signalisiert werden. Zudem hat man mir gesagt, dass ich beim Invite die Form "rufnummer@ipadresse" verwenden müsse und keinesfalls Rufnummer@hostname, was TLS erschwert, da ich keine IP-Adressen im Zertifikat haben möchte. Zudem wurde mit gesagt, dass alle Rufnummern im E164-Format vorliegen würden und welche IP-Adresse die H4000 HG (STMI) hat. Die Konfiguration in Skype for Business ist erst einmal nur "Standard".
- SfB Server = 10.0.0.8
- Hipath 4000 = 10.0.0.9
Der Link steht
Jedes VoIP-Gateway wird vom Skype for Business Mediation Server regelmäßig mit einem OPTIONS-Request auf seine Erreichbarkeit überprüft. Das ist ein guter Indikator, ob die TCP/TLS Verbindung steht und die Gegenstelle per SIP reagiert. Schon direkt nach der Einrichtung konnte ich folgenden Dialog mitschneiden. Zuerst die OPTIONS-Anfrage des Clients:
OPTIONS sip:10.0.0.9 SIP/2.0 FROM: <sip:sfb01.uclabor.de:5068;transport=Tcp;ms-opaque=e740d57bbbf95680>;epid=77EEED2984;tag=a8bbe7be7 TO: <sip:10.0.0.9> CSEQ: 1038 OPTIONS CALL-ID: 9fd753b3f41b47d0a18f6fa7fe1628c0 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 10.0.0.8:57292;branch=z9hG4bKbf4f7881 CONTACT: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8> CONTENT-LENGTH: 0 User-AGENT: RTCC/6.0.0.0 MediationServer
Die Umgehend von der Gegenstelle mit einem 200 OK beantwortet wird:
SIP/2.0 200 OK Via: SIP/2.0/TCP 10.0.0.8:57292;branch=z9hG4bKbf4f7881 From: <sip:sfb01.uclabor.de:5068;transport=Tcp;ms-opaque=e740d57bbbf95680>;epid=77EEED2984;tag=a8bbe7be7 To: <sip:10.0.0.9>;tag=3290198705 Call-ID: 9fd753b3f41b47d0a18f6fa7fe1628c0 CSeq: 1038 OPTIONS Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,INFO,PRACK,UPDATE Server: OpenScape 4000 - HiPath 4000 Common Gateway Content-Type: application/sdp Content-Length: 873 v=0 o=MxSIP 0 0 IN IP4 0.0.0.0 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 5555 RTP/AVP 8 18 4 96 98 99 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:96 CLEARMODE/8000 a=rtpmap:98 telephone-event/8000 a=rtpmap:99 red/8000 a=silenceSupp:off - - - - a=fmtp:18 annexb=no a=fmtp:4 annexa=no a=fmtp:98 0-15,32-36,49 a=fmtp:99 98 m=audio 5555 RTP/SAVP 8 18 4 96 98 99 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:96 CLEARMODE/8000 a=rtpmap:98 telephone-event/8000 a=rtpmap:99 red/8000 a=silenceSupp:off - - - - a=fmtp:18 annexb=no a=fmtp:4 annexa=no a=fmtp:98 0-15,32-36,49 a=fmtp:99 98 m=image 5555 udptl t38 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxFillBitRemoval:0 a=T38FaxMaxBuffer:72 a=T38FaxMaxDatagram:375 a=T38FaxVersion:0 a=T38FaxUdpEC:t38UDPRedundancy
Die Anlage reagiert schon mal auf einen OPTIONS-Request, unterstützt auch REFER und mit PCMA ist auch ein passender Codec dabei. Leider fehlt in der Codec-Liste aktuell CN\8000, also Comport Noise, was sicher im Eventlog für regelmäßige "Erinnerungen" sorgen wird.
Ausgehender Anruf
Insofern habe ich dann aus der Skype for Business Welt für einen ausgehenden Anruf gesorgt.
INVITE sip:+495251304613@10.0.0.9;User=phone SIP/2.0 FROM: "User1"<sip:+4952579388086@uclabor.de;User=phone>;epid=77EEED2984;tag=48ba564784 TO: <sip:+495251304613@10.0.0.9;User=phone> CSEQ: 1044 INVITE CALL-ID: f64c3de7-602a-419c-a279-b5b767983243 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 10.0.0.8:57364;branch=z9hG4bKfe37bb9 CONTACT: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8;ms-opaque=e740d57bbbf95680> CONTENT-LENGTH: 329 SUPPORTED: 100rel User-AGENT: RTCC/6.0.0.0 MediationServer CONTENT-TYPE: application/sdp ALLOW: ACK Allow: CANCEL,BYE,INVITE,PRACK,UPDATE v=0 o=- 2 1 IN IP4 10.0.0.8 s=session c=IN IP4 10.0.0.8 b=CT:1000 t=0 0 m=audio 51566 RTP/AVP 97 101 13 0 8 c=IN IP4 10.0.0.8 a=rtcp:51567 a=label:Audio a=sendrecv 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
Der ausgehende INVITE ist klassische Skype for Business Technik und auch die Gegenstelle sendet nach unter 1 Sekunde ein "100 Trying" wie es sich gehört gefolgt vonn einem RINGING. Ein "183 Session Progress" fehlt aber dazwischen. EarlyMedia ist so erst mal nicht möglich.
SIP/2.0 100 Trying Via: SIP/2.0/TCP 10.0.0.8:57364;branch=z9hG4bKfe37bb9 From: "User1"<sip:+4952579388086@uclabor.de;User=phone>;epid=77EEED2984;tag=48ba564784 To: <sip:+495251304613@10.0.0.9;User=phone> Call-ID: f64c3de7-602a-419c-a279-b5b767983243 CSeq: 1044 INVITE Server: OpenScape 4000 - HiPath 4000 Common Gateway Content-Length: 0
SIP/2.0 180 Ringing Via: SIP/2.0/TCP 10.0.0.8:57364;branch=z9hG4bKfe37bb9 From: "User1"<sip:+4952579388086@uclabor.de;User=phone>;epid=77EEED2984;tag=48ba564784 To: <sip:+495251304613@10.0.0.9;User=phone>;tag=2899074892 Call-ID: f64c3de7-602a-419c-a279-b5b767983243 CSeq: 1044 INVITE Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO, PRACK, UPDATE Contact: <sip:+495251304613@10.0.0.9:5060;transport=tcp> P-Asserted-Identity: "ExternAmt" <sip:+495251304613@10.0.0.9;User=phone> Require: 100rel RSeq: 1 Server: OpenScape 4000 - HiPath 4000 Common Gateway Content-Type: application/sdp Content-Length: 236 v=0 o=MxSIP 65747 204367788 IN IP4 10.0.0.9 s=SIP Call c=IN IP4 10.0.0.9 t=0 0 m=audio 29100 RTP/AVP 101 8 a=rtpmap:101 telephone-event/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - a=fmtp:101 0-15 a=sendrecv
Schön auch zu sehen, dass die TK-Anlage als "contakt" einen Displaynamen mit liefert. Die beiden Pakete des PRACK samt OK habe ich unterschlagen, Weiter geht es mit dem 200OK, dass die Gegenstelle abgehoben hat.
SIP/2.0 200 OK Via: SIP/2.0/TCP 10.0.0.8:57364;branch=z9hG4bKfe37bb9 From: "User1"<sip:+4952579388086@uclabor.de;User=phone>;epid=77EEED2984;tag=48ba564784 To: <sip:+495251304613@10.0.0.9;User=phone>;tag=2899074892 Call-ID: f64c3de7-602a-419c-a279-b5b767983243 CSeq: 1044 INVITE Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO, PRACK, UPDATE Contact: <sip:+495251304613@10.0.0.9:5060;transport=tcp> P-Asserted-Identity: "ExternAmt" <sip:+495251304613@10.0.0.9;User=phone> Server: OpenScape 4000 - HiPath 4000 Common Gateway Session-Expires: 1800;refresher=uas Supported: replaces, timer X-Siemens-Call-Type: ST-insecure Content-Length: 0
Auch die Audio-Verbindung wurde aufgebaut, wie man mit Wireshark schön sehen und mangels Verschlüsselung sogar anhören konnte.
Nach einigen Sekunden habe ich dann Seitens Skype for Business die Verbindung ordentlich beendet.
BYE sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8;ms-opaque=e740d57bbbf95680 SIP/2.0 Via: SIP/2.0/TCP 10.0.0.9;alias;branch=z9hG4bKc119e768f54fd7246 Max-Forwards: 70 From: <sip:+495118933045@10.0.0.9;User=phone>;tag=2899074892 To: "User1" <sip:+4952579388086@uclabor.de;User=phone>;epid=77EEED2984;tag=48ba564784 Call-ID: f64c3de7-602a-419c-a279-b5b767983243 CSeq: 8829 BYE Reason: Q.850; cause=16; text="Normal call clearing" Supported: timer User-Agent: OpenScape 4000 - HiPath 4000 Common Gateway Content-Length: 0
Der BYE an die TK-Anlage wurde sehr schnell mit einem OK quittiert
SIP/2.0 200 OK FROM: <sip:+495118933045@10.0.0.9;User=phone>;tag=2899074892 TO: "User1"<sip:+4952579388086@uclabor.de;User=phone>;tag=48ba564784;epid=77EEED2984 CSEQ: 8829 BYE CALL-ID: f64c3de7-602a-419c-a279-b5b767983243 VIA: SIP/2.0/TCP 10.0.0.9;branch=z9hG4bKc119e768f54fd7246;alias CONTENT-LENGTH: 0 SERVER: RTCC/6.0.0.0 MediationServer
Die Verbindung ist zustande gekommen, d.h. die übermittelte Rufnummer hat gestimmt und da beim Anrufer auch die "richtige" Rufnummer gemeldet wurde, ist auch das Format der "CallerID" für diesen Fall korrekt gewesen. Das ist aber noch keine Garantie, dass die Formatierung der Rufnummern für alle Fälle (Lokal, National, International, Mobilfunk etc.) korrekt ist.
Eingehender Anruf
Da ich anhand des ausgehenden Anrufs die Rufnummer gesehen habe, konnte ich sehr schnell nun einen Rückruf einleiten. Hier sehen Sie gut die Codecs, die von der TK-Seite angeboten werden
INVITE sip:+4952579388086@10.0.0.8:5068;transport=tcp;User=phone SIP/2.0 Via: SIP/2.0/TCP 10.0.0.9;alias;branch=z9hG4bKf28c71279f6dcbbd8 Max-Forwards: 70 From: "ExternAmt" <sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 To: <sip:+4952579388086@10.0.0.8;User=phone> Call-ID: 425d86fb2496436a CSeq: 772 INVITE Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO, PRACK, UPDATE Contact: <sip:+495118933045@10.0.0.9:5060;transport=tcp;User=phone> Min-SE: 90 P-Asserted-Identity: "ExternAmt" <sip:+495118933045@10.0.0.9;User=phone> Session-Expires: 1800 Supported: 100rel, timer User-Agent: OpenScape 4000 - HiPath 4000 Common Gateway X-Siemens-Call-Type: ST-insecure Content-Type: application/sdp Content-Length: 374 v=0 o=MxSIP 131284 1401914015 IN IP4 10.0.0.9 s=SIP Call c=IN IP4 10.0.0.9 t=0 0 m=audio 29100 RTP/AVP 8 18 4 98 99 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:98 telephone-event/8000 a=rtpmap:99 red/8000 a=silenceSupp:off - - - - a=fmtp:18 annexb=no a=fmtp:4 annexa=no a=fmtp:98 0-15,32-36,49 a=fmtp:99 98 a=sendrecv SIP/2.0 100 Trying FROM: "ExternAmt"<sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 TO: <sip:+4952579388086@10.0.0.8;User=phone> CSEQ: 772 INVITE CALL-ID: 425d86fb2496436a VIA: SIP/2.0/TCP 10.0.0.9;branch=z9hG4bKf28c71279f6dcbbd8;alias CONTENT-LENGTH: 0
Skype for Business unterstützt natürlich "EarlyMedia" und sendet daher einen "183 Session progress". von den Codec bleiben natürlich nicht mehr viel über, das der Mediation Server mit G729 oder G723 nichts anfangen kann.
SIP/2.0 183 Session Progress FROM: "ExternAmt"<sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 TO: <sip:+4952579388086@10.0.0.8;User=phone>;tag=9a824a316e;epid=77EEED2984 CSEQ: 772 INVITE CALL-ID: 425d86fb2496436a VIA: SIP/2.0/TCP 10.0.0.9;branch=z9hG4bKf28c71279f6dcbbd8;alias CONTACT: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8> CONTENT-LENGTH: 266 CONTENT-TYPE: application/sdp ALLOW: CANCEL ALLOW: BYE ALLOW: UPDATE ALLOW: PRACK REQUIRE: 100rel SERVER: RTCC/6.0.0.0 MediationServer Rseq: 1 v=0 o=- 3 1 IN IP4 10.0.0.8 s=session c=IN IP4 10.0.0.8 b=CT:1000 t=0 0 m=audio 52128 RTP/AVP 8 98 97 c=IN IP4 10.0.0.8 a=rtcp:52129 a=label:Audio a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:98 telephone-event/8000 a=fmtp:98 0-16 a=rtpmap:97 RED/8000
Auch hier entferne ich das PRACK und die Quittung darauf, da sie keine weitere Information liefern. Es kommt noch ein weiterer 183 Sessoin Progress aber ohne einen SDP-
SIP/2.0 183 Session Progress FROM: "ExternAmt"<sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 TO: <sip:+4952579388086@10.0.0.8;User=phone>;tag=9a824a316e;epid=77EEED2984 CSEQ: 772 INVITE CALL-ID: 425d86fb2496436a VIA: SIP/2.0/TCP 10.0.0.9;branch=z9hG4bKf28c71279f6dcbbd8;alias CONTACT: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8> CONTENT-LENGTH: 0 ALLOW: CANCEL ALLOW: BYE ALLOW: UPDATE ALLOW: PRACK SERVER: RTCC/6.0.0.0 MediationServer
Erst dann kommt ein RINGING, dass ein Skype for Business Endgerät "klingelt"
SIP/2.0 180 Ringing FROM: "ExternAmt"<sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 TO: <sip:+4952579388086@10.0.0.8;User=phone>;tag=9a824a316e;epid=77EEED2984 CSEQ: 772 INVITE CALL-ID: 425d86fb2496436a VIA: SIP/2.0/TCP 10.0.0.9;branch=z9hG4bKf28c71279f6dcbbd8;alias CONTACT: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8> CONTENT-LENGTH: 0 ALLOW: CANCEL ALLOW: BYE ALLOW: UPDATE ALLOW: PRACK SERVER: RTCC/6.0.0.0 MediationServer
Nach einem dritten "183 Session Progress" kommt dann das OK, was die Rufannahme beim Client anzeigt
SIP/2.0 200 OK FROM: "ExternAmt"<sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 TO: <sip:+4952579388086@10.0.0.8;User=phone>;tag=9a824a316e;epid=77EEED2984 CSEQ: 772 INVITE CALL-ID: 425d86fb2496436a VIA: SIP/2.0/TCP 10.0.0.9;branch=z9hG4bKf28c71279f6dcbbd8;alias CONTACT: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8> CONTENT-LENGTH: 266 SUPPORTED: 100rel CONTENT-TYPE: application/sdp ALLOW: ACK SERVER: RTCC/6.0.0.0 MediationServer Allow: CANCEL,BYE,INVITE,PRACK,UPDATE v=0 o=- 3 1 IN IP4 10.0.0.8 s=session c=IN IP4 10.0.0.8 b=CT:1000 t=0 0 m=audio 52128 RTP/AVP 8 98 97 c=IN IP4 10.0.0.8 a=rtcp:52129 a=label:Audio a=sendrecv a=rtpmap:8 PCMA/8000 a=rtpmap:98 telephone-event/8000 a=fmtp:98 0-16 a=rtpmap:97 RED/8000
Die Audio-Verbindung steht und funktioniert. Nach einiger zeit lege ich seitens Amt (Anrufer) auf, so dass dies mal die Hipath das BYE sendet
BYE sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8 SIP/2.0 Via: SIP/2.0/TCP 10.0.0.9;alias;branch=z9hG4bK54f0735b97ef673bd Max-Forwards: 70 From: "ExternAmt" <sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 To: <sip:+4952579388086@10.0.0.8;User=phone>;tag=9a824a316e;epid=77EEED2984 Call-ID: 425d86fb2496436a CSeq: 774 BYE Reason: Q.850; cause=16; text="Normal call clearing" Supported: timer User-Agent: OpenScape 4000 - HiPath 4000 Common Gateway Content-Length: 0
Der Skype for Business Mediation Server quittiert das Bye und die Verbindung wird abgebaut
SIP/2.0 200 OK FROM: "ExternAmt"<sip:+495118933045@10.0.0.9;User=phone>;tag=7090b54ae3 TO: <sip:+4952579388086@10.0.0.8;User=phone>;tag=9a824a316e;epid=77EEED2984 CSEQ: 774 BYE CALL-ID: 425d86fb2496436a VIA: SIP/2.0/TCP 10.0.0.9;branch=z9hG4bK54f0735b97ef673bd;alias CONTENT-LENGTH: 0 SERVER: RTCC/6.0.0.0 MediationServer
REFER
Einfache Anrufe in beide Richtungen funktionieren schon mal mit korrekter Übermittlung und Anzeige der Rufnummer. Der erste "höherwertige Test" ist natürlich eine Weiterleitung. Wenn alles gut geht, dann sendet der weiterleitende einen REFER zurück an den Anrufer, damit er sich einen neuen Weg sucht. Leider hat das noch nicht funktioniert, wie der folgende Trace zeigt. Ich dokumentiere nur die Pakete, die hier für den Fall relevant sind.
INVITE sip:+495251304613@10.0.14.8:5068;transport=tcp;User=phone SIP/2.0 From: <sip:+4952579388086@192.168.26.40;User=phone>;tag=e42e4297ee To: <sip:+495251304613@10.0.14.8;User=phone> Call-ID: 0fd7f328ee93f8fb
REFER sip:+495251304613@10.0.0.9:5060;transport=tcp;User=phone SIP/2.0 FROM: <sip:+4952579388086@10.0.0.8;User=phone>;epid=77EEED2984;tag=357e3f94fe TO: <sip:+495251304613@10.0.0.9;User=phone>;tag=e42e4297ee CSEQ: 2 REFER CALL-ID: 0fd7f328ee93f8fb CONTACT: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8;ms-opaque=e740d57bbbf95680> CONTENT-LENGTH: 0 REFER-TO: <sip:sfb01.uclabor.de:5068;transport=Tcp;maddr=10.0.0.8;ms-opaque=e740d57bbbf95680?REPLACES=a2f06c05-48a0-487a-968e-7cbeea6e9519%3Bfrom-tag%3D454f776e0%3Bto-tag%3Dd67f164b5b> User-AGENT: RTCC/6.0.0.0 MediationServer
Hier ist aber die Hipath noch nicht korrekt konfiguriert und obwohl sie das Verb "REFER" beim der Frage "OPTIONS" noch in der Antwort anbietet, lehnt Sie den Aufruf mit einem "405 Method not Allowed" ab
SIP/2.0 405 Method Not Allowed Via: SIP/2.0/TCP 10.0.0.8:5068;branch=z9hG4bK9733dfc From: <sip:+4952579388086@10.0.0.8;User=phone>;epid=77EEED2984;tag=357e3f94fe To: <sip:+495251304613@10.0.0.9;User=phone>;tag=e42e4297ee Call-ID: 0fd7f328ee93f8fb CSeq: 2 REFER Server: OpenScape 4000 - HiPath 4000 Common Gateway Content-Length: 0
Ich bin sicher, dass die Hipath auch einen REFER könnte aber an dem Tag konnte wir das nicht mehr weiter verfolgen. Als schnelle Lösung habe ich REFER auf dem Skype for Business Trunk abgeschaltet. Hier war das in Ordnung, da eine Weiterleitung ohne REFER zwar dann den Audio-Kanal weniger effektiv über den Mediation Server laufen lässt, aber nur wenn die Ziel extern ist. Für eine Demo-Umgebung ist dies sicher tolerierbar.
Einschätzung
Dies ist ein erster einfacher Artikel über die Anbindung von Skype for Business On-Prem mit einer Unify Openscape 4000, der unter anderem belegt, dass es erst einmal möglich ist die beiden Welten über ein "Openscape 4000 - Hipath 4000 Common Gateway" zu verbinden. Allerdings stehen noch einige Teste aus, ehe so eine direkte Anbindung in Betrieb gehen könnte, z.B.:
- Media Bypass mit SRTP
- Absicherung per SIP/TLS
- "Lange Verbindungen"
- Comfort Noise
- Unterstützung von REFER (Vermitteln)
- Unterstützung von Park
- Verschiedene Gegenstellem
Aber selbst dann bleibt immer noch dass Risiko, dass ein Update auf einer der Seiten die Funktion grundlegend verändert. Schon beim Wechsel von Lync 2010 auf Lync 2013 hat Microsoft die Anforderungen an die Gegenstellen angehoben um neue Funktionen zu unterstützen. Auch auf der Unify-Seite könnte ein Update oder schon ein geänderter Default die Funktion stören. Solange die beiden Seiten auch auf Ebene der Hersteller nicht miteinander sprechen und ihre Interoperabilität testen, würde ich dennoch immer einen Session Border Controller dazwischen setzen, der übrigens auch für eine spätere Migration durchaus seine Daseinsberechtigung haben kann.