Willkommen in der Business Community

Die Telekom Community für Geschäftskunden

Aktueller Hinweis

Manche eingehenden Anrufe am SIP-Trunk sind nicht E.164-konform

Unsere neue Telefonanlage läuft sein 2 Wochen, und alles funktioniert, nur einzelne Kunden können uns nicht erreichen. Ich konnte jetzt klären, woran es liegt:

 

Obwohl man am SIP-Trunk alle abgehenden Nummern als E.164 senden muss, kommen manche Anrufe (ca. 1%) mit einem anderen Format für die Direct Inward Dialed Number rein.

 

Alle korrekten Anrufe haben das erwartete Format: +4912349876.

 

Bei manchen wird die deutschlandweite Nummer übertragen, also bei obigem Beispiel: 012349876, und bei anderen aus unserem Vorwahlbereich sogar nur die 9876.

 

Ich habe dafür jetzt zusätzliche DID-Routen angelegt, und es funktioniert, bläht die Inbound Routes jedoch um den Faktor 3 auf.

 

Meine Frage nun: ist das ein Fehler auf der Telekom-Seite, dass die Nummern nicht sauber umgeschrieben werden, oder ist das normal und ich muss diese Fälle lokal behandeln?

 

Grüße

Thomas Herrmann

Telekom hilft Team
Hallo @tobox,

herzlich willkommen in unserer Community. Schön, dass Sie mit Ihrem Anliegen den Weg zu uns gefunden haben.
Vielen Dank für Ihren Beitrag und auch Ihre bereits gefundene Lösung.

Ich frage bei der Fachseite dazu nach und melde mich Anfang der nächsten Woche erneut.

Lieben Gruß Melanie B.

@tobox 

So weit ich weiß muss ausgehend E.164 eingehalten werden (1TR118). Eingehend ist alles möglich, bei On-Net Calls auch 0123456791012. By the way: Ich kann auch eine Rufnummer im nicht kanonischen Format erfolgreich registrieren und nutzen. Auch bei anderen Anbietern.

So, nachdem das Forum jetzt zum dritten mal meine Antwort gefressen hat:

 

Danke, damit decken sich unsere Beobachtungen ziemlich genau. Ich habe mittlerweile den incoming Context von Asterisk so umschreiben können, dass alle Telefonnummern im E.164-Format kommen:

 

https://community.freepbx.org/t/solved-pattern-matching-on-did-rewriting-dids-in-inbound-routes/5703...

 

Außerdem habe ich noch eine Catchall-Inbound-Route angelegt, so dass zumindest alle Gespräche irgendwo rauskommen sollten.

 

Danke für die Hinweise!

Alle eingehenden Anrufe werden im E.164 Format signalisiert.

 

Der einzige Grund für Nicht-E.164 Rufnummern kann sein, dass das falsche Header-Feld ausgewertet wird.

Offensichtlich wertet ihr das To-Feld aus, anstatt korrekterweise die Request-Line zu nutzen.

 

Das to-Feld ist nicht für das Call-Routing geeignet, siehe RFC3261:

8.1.1.2 To

   The To header field first and foremost specifies the desired
   "logical" recipient of the request, or the address-of-record of the
   user or resource that is the target of this request.  This may or may
   not be the ultimate recipient of the request.

Aus diesem Grund ist das To-Feld nicht für das Callrouting zu nutzen und wird daher auch nicht in das E.164 Format normalisiert.

 

Das Thema ist in der "technischen Unterlage SIP-Trunk" unter 11.20 (Seite 35) auch noch einmal näher erläutert.

Ich muss hier noch einschränkend sagen, wenn ein SIP-Trunk genutzt wird und die Registrierung nach RFC3261, nicht nach RFC6140 (wie bspw. in SIP Connect 1.1 vorgeschlagen), erfolgt, kann das Routing natürlich nicht mit der Request-Line erfolgen, sondern nur anhand der P-Called-Party Feld des eingehenden INVITEs.

 

Hintergrund: Erfolgt die Registrierung nach RFC3261, enthält das eingehende INVITE in der Request-Line den Adress of Record, d.h. den Nutzer und die Domain aus dem Contact-Feld der Registrierung. Nur bei Registrierung gemäß RFC6140 wird in der Request-Line die vollständige Rufnummer signalisiert.


Der einzige Grund für Nicht-E.164 Rufnummern kann sein, dass das falsche Header-Feld ausgewertet wird.

Offensichtlich wertet ihr das To-Feld aus, anstatt korrekterweise die Request-Line zu nutzen.

Vielen Dank für den Hinweis! Ich bin bei meinen ersten Tests darüber gestolpert, dass die Gespräche immer nur zur Hauptrufnummer geroutet wurden, und es gab zahlreiche Hinweise bei FreePBX dass man in dem Fall den To-Header benutzen soll, als auch einige Foreneinträge, die gleiches behauptet haben:

 

https://www.ip-phone-forum.de/threads/freepbx-did-telekom-deutschlandlan-sip-trunk.300561/#post-2290...

 

Nachdem ich die Datei SIP-Trunk-Technische-Unterlage.ps in SIP-Trunk-Technische-Unterlage.pdf umbenannt hatte, konnte ich sie auch öffnen, und mit den darin enthaltenen Infos werde ich jetzt mal versuchen, das ganze "korrekt" umzustellen.

 

Vielen Dank für die detaillierten Infos!


@tobox  schrieb:

 

Vielen Dank für den Hinweis! Ich bin bei meinen ersten Tests darüber gestolpert, dass die Gespräche immer nur zur Hauptrufnummer geroutet wurden, und es gab zahlreiche Hinweise bei FreePBX dass man in dem Fall den To-Header benutzen soll, als auch einige Foreneinträge, die gleiches behauptet haben:

Das hört sich stark danach an, dass die Registrierung nicht gemäß RFC6140 vorgenommen wird, sondern nach RFC3261. Dann muss das P-Called-Party-ID Feld für das Callrouting genutzt werden.

Telekom hilft Team
Hallo @tobox,

leider benötige ich noch etwas Zeit, tut mir leid.
Ich melde mich Anfang der nächsten Woche dazu erneut.

Lieben Gruß, Melanie B.
Telekom hilft Team
Hallo @tobox,

von der Fachseite kommt dazu die Info, dass hier auf die Schnittstellenbeschreibung der Telekom für den SIP-Trunk 1TR118 zu verweisen ist.
Die Beschreibung finden Sie hier.
https://www.telekom.de/hilfe/geraete-zubehoer/telefone-und-anlagen/informationen-zu-telefonanlagen/s...


Lieben Gruß, Melanie B.

von der Fachseite kommt dazu die Info, dass hier auf die Schnittstellenbeschreibung der Telekom für den SIP-Trunk 1TR118 zu verweisen ist.
Die Beschreibung finden Sie hier.
https://www.telekom.de/hilfe/geraete-zubehoer/telefone-und-anlagen/informationen-zu-telefonanlagen/s...


Hallo Melanie,

 

der Link funktioniert bei mir leider nicht Traurig

 

Thomas

Telekom hilft Team
Hallo @tobox,

danke für den Hinweis. Ich kann den Link öffnen.

Haben Sie es mal mit einem anderen Browser probiert?

Lieben Gruß, Melanie B.
Stimmt, jetzt gehts. Der Browser hat rumgemuckt.