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-Premise 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.

Weitere Links