AW: DeutschlandLAN SIP-Trunk overlap dialing nach rfc3578

[#1]

Guten Abend allerseits.
Seit dem die Telekom nun immer mehr Geschäftskunden von durchwahlfähigen ISDN-Basisanschlüssen und ISDN-Primärmultiplexanschlüssen auf die All-IP-basierten SIP-Trunks umstellt, kristalisiert sich mehr und mehr eine eklatante Schwäche der von der Telekom für diese Anschlüsse verwendeten "TAS"-Plattform heraus - die Wegwahl (englisch "overlap dialing" oder "overlap signalling") und somit die Ende-zu-Ende-Signalisierung der live gewählten Ziffern "in die Verbindung hinein", wie sie von der IETF in der RFC3578 festgehalten ist, wird nicht unterstützt. Bei diesem Verfahren wird mit jeder gewählten Ziffer ein neuer INVITE an die Vermittlungsstelle (SIP-Proxy) gesendet, der die gewählte Rufnummer dann anhand seines Dialplans weiter an den entsprechenden Zielprovider und dieser dann (bei entsprechend weit fortgeschrittener Wahl) an den Ziel-UA sendet. Ist die gewählte Nummerngasse im Dialplan vorhanden, aber nicht vollständig, so wird der INVITE mit "484 - Adress Incomplete" beantwortet, was dem initiator der Wahl suggeriert, dass auf weitere Ziffern gewartet werden muss. Erst wenn der letzte Teilnehmer in der Kette mit "180 - Ringing" antwortet, ist die Wahl vorüber und das Telefonat beginnt. Stellt irgend jemand der beteiligten Vermittlungsstellen während der Wahl fest, dass die gewählte Nummerngasse im Wählplan/Nummerierungsplan nicht existiert (die Wahl also in eine Sackgasse führt), signalisiert er "404 - not found".

Bisher reagiert der Telekom TAS-Proxy auf einen unvollständigen INVITE mit einem tarpit und einem anschließenden "404 - not found". Mit der fortschreitenden Migration wird dieses vorgehen mehr und mehr zum Problem, da das Wahlende somit nur mit einem Timeout oder mit der Pflege von allen Nummerierungsplänen der Erde erkannt werden kann. Dazu kommt, dass überlang genutzte Rufnummernblöcke nicht mehr komplett erreicht werden können, obwohl das mit ISDN früher möglich war. Ich betreue ca. 200 Telefonanlagen der Größe 5 bis 500 Teilnehmer und kann sagen, dass 75% der Kunden überlange Rufnummernblöcke verwenden.

Das fehlen der Ende-zu-Ende Rufnummernsignalisierung nach RFC 3578 stellt einen erheblichen Rückschritt gegenüber dem alten ISDN-Netz dar. Wann wird dieses Leistungsmerkmal vom Telekom DeutschlandLAN SIP-Trunk unterstützt?

Grüße Robert Weidner

[#2]

@wultna 

M.E.n. ist das ein Issue des involvierten Voip-Gateways/UA's.

Ich weiß, dass z.B. LANCOM, Patton das Merkmal unterstützen, also es im EG entsprechend prozessiert und dann raus in Richtung Backend gesendet wird. Bitte mal prüfen, ob die Frage damit geklärt sein könnte.

Siehe hier:

https://www.lancom-systems.de/docs/LCOS/referenzhandbuch/topics/aa1469934.html

Oder hier:

https://www.patton.com/voipnews/v1n4/OverlapDialing.asp

[#3]

Overlap-Dialing wird von keiner VoIP-Plattform der Telekom unterstützt (siehe 1TR114, 4.2.13) Es ist auch nicht geplant dies zu unterstützen.

Die Überwahl funktioniert weiterhin, wenn die Rufnummer vollständig "en block" in einem INVITE vollständig übermittelt wird.

[#4]

@ NPS011172

Hallo,

nein, das ist eben kein Issue der Gateways. Der Telekom-SBC reagiert auf eine unvollständige Adresse nicht mit 484 - Adress Incomplete, sondern mit einem Tarpit. Dies läuft dem Prinzip von Overlap Signalling genau zuwider.

[#5]

@ Meester Proper
Hallo. Es geht jedoch eben nicht um einen Rufaufbau bei "blockförmig" gewählter Rufnummer sondern um den Rufaufbau bei einem "Nur-wegwahfähigem"-Gerät wie einem analogen Telefon. Hierbei muss das umsetzende Gateway immer mit virtueller Wegwahl mittels Timeout signalisieren, was natürlich bei zu langen Abständen zwischen den Zifferneingaben zu einer Fehlwahl führt, die wegen des bereits eingangs erwähnten Tarpits auch noch stark verzögert signalisiert wird. Ein unsäglicher Rückschritt zum alten ISDN-Signaling. Das führt zudem dazu, dass manche Endgerät die überlang vergebenen Rufnummern nicht mehr richtig erreichen können.

Hier muss unbedingt etwas geändert werden!

[#6]

Hallo @wultna,

leider kann ich mich deines Anliegens nicht direkt annehmen, da ich auf die Schnelle keine passende Antwort parat habe.

Ich habe das Anliegen aber direkt an die Fachseite weitergetragen und erwarte hier nun in den nächsten Tagen eine Antwort. Ich werde mich dazu am Freitag wieder mit einem Zwischenstand melden.

Liebe Grüße aus Kiel
Gerrit H.

[#7]

Die meisten Gateways erlauben die Erkennung der Raute (#) als Abschluss des Wählens und bauen dann direkt die Verbindung auf (=INVITE wird versendet). Das ist der einzige mögliche Workaround für Legacy-Endgeräte.

Ansonsten bleibt nur, wenn dieses Feature entsprechend wichtig ist und die zusätzliche Verzögerung unbedingt vermieden werden muss, das Anschaffen von modernen Endgeräten wie IP-Telefonen, diese senden ebenfalls mit dem Betätigen des "Wählens" den Ruf sofort ab und der Anruf wird direkt aufgebaut.

[#8]

Hallo @wultna,

ich habe nun von einem Kollegen von der Fachseite folgende Antwort bekommen:

Wir unterstützen bei SIP-Trunk kein Overlap-Dialing, sondern arbeiten mit Blockwahl; auch die Schnittstellenspezifikationen gegenüber den Endgeräteherstellern fordern Overlap-Dialing nicht an.

Es stimmt, dass bei DDI-Produkten wie dem SIP-Trunk die Herausforderung besteht, wie man damit umgeht, dass bei ankommenden Anrufen aus dem PSTN zu SIP-Trunk die Rufnummernlänge des Ziels am Netzübergang nicht bekannt ist, da die Kunden in der Länge ihrer Durchwahlen frei sind. Die relevanten Netzelemente (konkret. der Mediagateway-Controller/MGC) wissen nicht, ob eine ankommende Rufnummer bereits alle Wahlziffern enthält oder ob noch Ziffern nachgesendet werden - im Gegensatz zum MSN-Produkten, da bekommen die MGCs immer die komplette Rufnummer.

Overlap-Dialing/Multiple Invite wäre eine Lösung, wir arbeiten jedoch mit Blockwahl, was bedeutet, dass der MGC für eine definierte Zeit auf evtl. Nachwahlziffern wartet und dann ein Invite sendet. Dieses Verfahren funktioniert, die Folge einer um den genannten Zeitraum verlängerte Rufaufbauzeit ist tolerierbar.

Wir sehen daher momentan keine Notwendigkeit für eine Einführung von Overlap-Dialing beim SIP-Trunk.

Liebe Grüße aus Kiel,
Gerrit H.

[#9]

Sorry, liebe Telekom-Verantwortliche,

diese Antwort ist nicht befriedigend. Als Ende der 1980er Jahre mit der PCM30-Technologie und den ISDN-Anschlüssen die End-To-End-Digitalisierung in die Vermittlungsstellen und Büros/Privathaushalte einzog, resultierte dies nicht zuletzt auf dem fortschrittlichen Internationalen Zeichengabeverfahren Nr. 7, welches die digitale Nachwahl von Rufnummern zur durchgängigen Grundlage jeder End-To-End-Verbindung machte. Mit einem damals erstaunlichem Zeitvorteil: jede so initiierte Verbindung war  mit der Wahl der letzten erforderlichen Ziffer durchvermittelt und begann binnen Sekundenbruchteilen zum Leuten.

Für mich war es immer unverständlich, wie man darauf bei der SIP-Umstellung des Festnetzes verzichten konnte und jetzt - zumindest im SIP-Trunk und ohne #-Terminierung - wieder 5-10 Sekunden Wartezeit aufgedrückt bekommt; das ist ein zeitlicher Rückfall ins Zeitalter implusbasierter Zeigengabeverfahren und entspricht in etwa der Geschwindigkeit meines W48-Wählscheibenapparates. Wieso also bitte nicht RFC3578 implementieren, der den damals gewonnenen Komfort zumindest auch im IP-Zeitalter weiterführen würde?  Die oben von Ihnen getroffene Aussage  "Dieses Verfahren funktioniert, die Folge einer um den genannten Zeitraum verlängerte Rufaufbauzeit ist tolerierbar..." ? erinnert mich in diesem Zusammenhang an die gute alte Bundespostzeit. Oh nein, sorry, die Digitalisierung mit Zeichengabeverfahren Nr. 7 war ja auch noch zu Bundespostzeiten und damit deutlich innovativer