crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
01.10.2018 10:07 Zuletzt bearbeitet: 01.10.2018 10:09 durch den Autor
vorweg mal die Serien# und Firmware-Version debe.IP+ (entspricht der Digitalisierungsbox Premium)
Seriennummer BE2CAK018170910
BOSS-Version V.10.2.4.100 IPv6, IPSec, MGW from 2018/08/17 00:00:00
Es ist folgendes Konfiguriert und funktioniert auch, außer in dem anschließend geschilderten Fall:
Wie geschrieben das ist so alles OK, funktioniert außer (bitte zu Ende lesen!):
Anruf von einer Nebenstelle der PBX über be.IP+ an die Telekom WENN der Empfänger ein Handy ist mit der eingeschalteten Option LTE für Sprache und Daten. Wenn LTE nur für DATEN aktiviert ist funktioniert es. Als Handys im Test waren es das iPhone 7 und das Google Pixel 2. Außerdem kam das nachfolgend geschilderte Verhalten auch schon bei einer Festnetznummer vor, dafür haben wir aber keinen Beleg, nur Hinweise im PBX Log.
Aus dem Trace (Lokale Dienste -> Trace -> VOIP/SIP Trace > Ereignisse 2) ist zu erkennen:
Bei den geschilderten Fällen bekommt letztendlich die be.IP+ das OK von der Telekom auf das entsprechende INVITE (also wenn der B-Teilnehmer das Gespräch angenommen hat), leitet jene in diesen Fällen jedoch nicht weiter an die PBX wie sonst.
Trying, Ringing werden weitergeleitet, OK nicht, der SIP Timer bei der Telekom veranlasst dann noch 4 Retries und gibt dann auf.
Zu Bemerken wäre das das OK (wie auch schon das Ringing, welches jedoch weitergeleitet wird an die PBX) im TO: Header nun
sip:anonymous@anonymous.invalid
statt (wenn im Endgerät oder bei den Anrufen ins normale Festnetz, wie gesagt auch mit Ausnahme)
+491511xxxxxxx@sip-trunk.telekom.de
stehen hat, was so aber von der Telekom signalisiert wird. (Ich habe die Nummer hier aus Datenschutz ausge-X-t)
Kein Response von der Bintect auf das OK der Telekom bzw. auch keine Weiterleitung an die PBX.
Das Problem tritt an zwei unterschiedlichen Deutschland-LAN SIP Trunk Anschlüssen auf (gleiches Produkt), an verschiedenen Ziel-Rufnummern.
Da es die be.IP+ schafft das "Ringing" weiterzugeben, und das noch richtig formuliert für die PBX, so das die das auch "versteht", wäre das ja machbar den Router entsprechend zu fixen das er nach dem Motto "Be graceful what you accept and strict what you send" arbeitet, ohne natürlich den Sicherheitsaspekt außen vor zu lassen... Die Lösung drängt (wie immer).
Ich habe auch schon mich mit dem Telekom Support telefoniert, hoffe die tun das was, warte auch dort auf Antwort. Zudem hatte ich eine Support-Anfrage (Enterprise-Level Partner) an Bintec gestellt, die sagten das Problem ist bekannt, es wird an einer Lösung gearbeitet. Zeitpunkt konnte keiner genannt werden, mit dem nächsten Update soll es einen FIX geben.
Jedoch liegt das Problem eher (eindeutig?) beim Netzanbieter, und eventuell, kann ja die Telekom oder jemand anders einen "Workaround" anbieten oder eine andere Hardware epmpfehlen (nicht Bintec) mit der ich sowohl zur Telekom als auch zur Cloud PBX trunken und auch routen kann, welches aber bereits diese Problem kompensiert/ korrigiert.
Anbei mal das Kommentierte / Markierte Trace-Protokoll als PDF (Auf die SIP Nachrichten dieser Verbindung zusammengekürzt, komplettes Trace wäre auch vorhanden für den GUT als auch FEHLERFALL)
Ich habe hier
ersetzt (Vorwahl gebe ich Preis, Interne IPs auch)
01.10.2018 21:24
03.10.2018 18:20
Sie benötigen eine persönliche Kaufberatung? Das Geschäftskundenteam der Telekom berät Sie gerne.
Informieren Sie sich über unsere aktuellen Festnetz- & Internet-Angebote.