Vodafone Sip-Trunk

[bitn2]

Das passiert nicht automatisch. Da muss jemand geklickt haben.

Es sei denn es ist eine NFR Lizenz die hosted by 3cx genutzt wird oder die SMB.

 

[fxbastler]

Ah, die NFR hosted - ja, die könnte es auch sein. Haben wir nicht. Brauchen wir selber, hier

 

[Josef L]

Könnte das Problem auch daran liegen das man nicht an allen Stellen den Codec angepasst ist, bin ich auch schon einmal darüber gestolpert. Hatte in den Systemeinstellungen und bei den Usern mit IP-Telefon den Codec angepasst, leider war noch im Siptrunk ein Codeceinstellung unter Optionen übersehen. Als der dann noch angepasst wurde funktionierte alles.

 

[mbehrens]

Könnte das Problem auch daran liegen das man nicht an allen Stellen den Codec angepasst ist, bin ich auch schon einmal darüber gestolpert. Hatte in den Systemeinstellungen und bei den Usern mit IP-Telefon den Codec angepasst, leider war noch im Siptrunk ein Codeceinstellung unter Optionen übersehen. Als der dann noch angepasst wurde funktionierte alles.

Durchaus eine Möglichkeit, Logs zeigen das.
Es besteht in der Regel keine Notwendigkeit von PCM A-law als primären Codec abzuweichen. Eine Transkodierung sollte vermieden werden.

 

[INNO-ML]

Kurzes Update: Seit V20 U8 ist auch das "Vodafone Registration" Template an Board mit dem R6 problemlos angebunden werden konnte.

 

[icom]

Hallo 3CX-Volk!
Nun möchte ich auch meinen Senf dazu geben. Ich beschreibe wie immer "kurz" die ganze Situation und meine Lösungsansätze.
Also, wir hatten schon immer Vodafone Trunk mit 4 Leitungen. Ohne Registrierung, IP-basiert, fand ich schon immer *cheisse, da man Trunk Failover (alle 4 Leitungen belegt) nicht erkennen kann. Aber es hat funktioniert, eigentlich auch ohne großen Probleme.
Nun sollten wir auf R6 mit Registrierung umstellen. Auch wie bei euch, sollten wir einen Testtrunk anlegen. Gesagt getan, wir packens an.
Ich habe aber praktisch keinen Test-Trunk angelegt, sondern gleich einen richtigen, aber eher vorläufigen Trunk angelegt. In der Annahme, wenn es funktioniert, steigen wir direkt um und löschen den alten. So die Idee.
Also wie habe die Umstellung genau vollzogen:
1. Zugangsdaten unter Vodafone erstellt (sagen wir mal Passwort gesetzt).
2. Zweiten "neuen" Trunk parallel erstellt (Vorlage von 3CX, "Vodafone registred" oder so ähnlich). Und in Ausgangsregeln nach unten verschoben, vorerst.
3. Mit Trunk Checker alles grün, aber ausgehender Testanruf -> keine Chance. Es ruft an, tutu lala, aber kein Anruf im Ziel. Irgendwann auf die Idee gekommen, es von einer Nebenstelle aus zu probieren und siehe da, funktioniert. Ok. Ein bisschen rumgetestet, geht. Vodafone gemeldet und Termin vereinbart.
4. System ausgehend auf den neuen Trunk umgestellt (Regel nach oben geschoben). Also kamen nun eingehende über "alten" Trunk, ausgehend wurde über den "neuen" telefoniert. Ca. eine Woche lang so gefahren, bis zum Termin halt.
5. Nebenbei die selben DIDs auf dem neuen Trunk angelegt und den Nebenstellen zugeordnet. Wusste nicht dass das geht, aber habe angenommen: wenn es umgestellt ist, müsste es sofort funktionieren. Alten Trunk löschen, gehen die Zuordnungen mit den "alten" DIDs mit dem Löschen vom "alten" Trunk weg.
6. Stunde der Wahrheit, Tag der Umstellung. Vodafone schaltet eingehende auf den neuen Trunk, funktioniert.
7. Alten Trunk exportiert und gelöscht, somit alte DIDs weg, neue sind bereits drin und funktionieren. Das war ja einfach, dachte ich mir, aber nun ein paar Probleme festgestellt.
Probleme die aufgetaucht und teilweise gelöst sind:
1. Wir hatten parallel Umstellung aller mobilen Verträge von Vodafone auf Telekom. Was habe ich dann feststellen müssen: Unsere mobile Bereitschaftsnummer die dumm alles an eine der Durchwahlen umleitet, wurde warum auch immer nicht an die entsprechende Warteschleife weitergeleitet sondern an die zentrale Trunk Nummer. Ich habe dann im Anrufprotokoll gesehen, dass als DID die Mobilfunk Nummer drin steht. Ok, dachte ich mir, ich probiere es aus. Ich habe unsere mobile Nummer ebenfalls als DID im Trunk angelegt und diese dann auf die Warteschleife ausgerichtet und, geht)Der Anruf wird richtig in die Warteschleife reingeroutet. Problem gelöst dachte ich, ohne nun die Hintergründe dahinter zu verstehen, aber Hauptsache es geht.
2. Nun, nach einer Woche Benutzung, hat sich herausgestellt, dass manche externen Anrufe auf der Hauptnummer landen und nicht in der Nebenstelle, obwohl richtige Durchwahl gewählt wird. Auch hier kein Ding verstanden warum das so ist, bis ich mich an das erste Problem mit der Bereitschaft erinnert habe. Ich vermute nun hier, und teilweise ist es auch schon bestätigt, dass wenn Anrufe aus dem Telekomnetz kommen, werden sie nicht richtig geroutet. Irgendetwas ist bei Telekom anders, als bei anderen Providern. Ich bin nun kein SIP Maestro und kennen mich da "nur" im Allgemeinen aus, aber ich bleibe dran bis das Problem aus der Welt ist.

Meine mögliche Problemlösung:
Ich habe in den Release Notes gesehen, dass die Vodafone Vorlage in V20U9 Alpha aktualisiert wurde. Meine Hoffnung nun, einfach den Trunk neu anlegen, mit der neuen Vorlage, und dann noch einmal testen. Also werde ich mein System bis auf die neuste Version aktualisieren (ich weiß, es ist Beta, aber bei meinem Umfang sollte das gehen) und den Trunk neu anlegen. DIDs neu anlegen und zuweisen und Daumen drücken. Was ich mir noch vorstellen könnte, vllt die DIDs auch im Format 03677xxxxx anzulegen, parallel zu +49xxx oder eingehende im Trunk umzuschreiben, da bin ich aber auch etwas überfragt und müsste es durch Ausprobieren rauskriegen ob es funktioniert.
Die allgemeine Frage wäre ja, was macht Telekom anders als der Rest. Ich meine dass alle anderen Provider problemlos funktionieren, was hat Telekom da wieder für ein Ding drin was die Anlage nicht zuordnen kann.
Kennt jemand vllt genau das Problem und die Ursache und natürlich auch eine vernünftige, saubere Lösung welche stabil bei allen Providern läuft?
Also ich bin für jede vernünftige Lösung zu haben. Aber bitte keine Anrufskripte oder ähnliches, da bin ich kein Freund von.

Ich werde erst einmal die zweite DID mit der Null anlegen, mal sehen was dabei rum kommt) ich berichte hier im Anschluss)
Ich hoffe es wird nicht langweilig beim Lesen von meinen Romanen hier im Forum)

P.S.: Ich verwende immer internationales Format für Nummern und ich verwende auch HD Codec, er ist auch in der Vodafone Beschreibung an der ersten Stelle und man hört einfach besser lauter und klarer, vor allem bei den mobilen Android Clients usw. Also bei den Codecs bisher keine Probleme gehabt oder zumindest keine festgestellt.

 

[icom]

Ich werde erst einmal die zweite DID mit der Null anlegen, mal sehen was dabei rum kommt) ich berichte hier im Anschluss)

In der Tat! Es funktioniert. Zusätzlich eine DID mit der Null angelegt, also nationales Format 03677... und nun kommen Anrufe auch von der Telekom durch und landen in der richtigen Nebenstelle. Ich kann mir das nur so erklären, das die Telekom die gewählte Nummer nicht im internationalen Format mitschickt. Also müsste man auch dieses Feld "To" ins int. Format konvertieren. Weiß jemand wie das in Trunk Einstellungen geht?
Danke vorab für eure Hilfe!

 

[antrill]

Irgendetwas ist bei Telekom anders, als bei anderen Providern. Ich bin nun kein SIP Maestro und kennen mich da "nur" im Allgemeinen aus, aber ich bleibe dran bis das Problem aus der Welt ist.

Das kann ich jedenfalls bestätigen. Bei uns war es so, dass uns Telekom Festnetzanschlüsse (nicht mobile) gar nicht erreichen konnten. (Ansage: "Teilnehmer nicht verfügbar")
Es lag an einem Fehler der Trunk-Template für V6 die ich aus diesem Forum hatte, es war aber wohl eine sehr frühe Version. Als wir umgestellt wurden auf V6 gab es in 3CX noch keine mitgelieferte Vorlage.
Bei allen Tests war das kein Problem, weil wir halt kein Telekom-Festnetz abgehend verwendet haben. Bei allen anderen Providern funktionierte alles. Die umgekehrte Richtung zur Telekom hin klappte ebenfalls.

Nach viel tracen und mit KI-Hilfe fand ich heraus, dass in der xml-Datei so gemappt wurde:
von To User Part -> CalledNum
Richtig wäre aber:
Request Line URI User Part -> CalledNum

Technischer:
Falsch:

"InboundParams": [
{ "Custom": "", "ParamId": 6, "ValueId": 10 },
{ "Custom": "", "ParamId": 9, "ValueId": 9 },
{ "Custom": "", "ParamId": 9, "ValueId": 8 }
]

Richtig:

"InboundParams": [
{ "Custom": "", "ParamId": 1, "ValueId": 10 },
{ "Custom": "", "ParamId": 9, "ValueId": 9 },
{ "Custom": "", "ParamId": 9, "ValueId": 8 }
]

Da man eigentlich in 3CX V20 keine bestehenden Trunks ändern kann, sondern nur löschen und neuanlegen, hat ChatGPT zu meiner Verwunderung ein Python-Script gebaut, das den Parameter über die API-Verbindung doch ändern konnte. Seitdem sind wir auch wieder für Telekomkunden erreichbar.
Es ist wirklich ein Trauerspiel mit VoIP, wie viel da so subtil kaputt gehen kann. Vor Jahren (noch mit Panasonic-Anlage, vor 3CX) hatten wir ebenfalls bei eingehenden Calls von O2 mobile immer eine Trennung nach genau 90 Sekunden. Toll, wenn man aber mit denen kein Vertragsverhältnis hat sondern mit Vodafone. Erst als ich einen Test-Trunk über Sipgate geschaltet habe und die Calls dort nicht gedroppt wurden und ich VF mit Kündigung drohte, wurde das eskaliert. Am Ende war die Ursache eine Konfig-Änderung bei O2, es waren Tausende deutschlandweit betroffen.
Wie schön war das homogene Netz mit Analog / ISDN. Testanruf -> Geht, alles OK. Das war mal.

 

[Reflecting God]

Genau im TO- Header wird seitens Vodafone R6 die Nummer übertragen wie sie vom abgehenden Provider gewählt wurde übertragen , ausgewertet muss laut Schnittstellenbescheriebung, bei eingehenden Gesprächen aber der P-Called-Party-ID Header ..dort steht dann die Rufnummer immer im E164 Format (+49xxxxxxx) drin…. Wie du schon schreibst ,das es den „einen Standard“ gibt war einmal.

 

[bitn]

Ohne jetzt alles gelesen zu haben aber ein DID kann man nach wie vor auch mit *Rufnummer anlegen. Dann braucht man das nicht doppelt Pflegen.

 

[icom]

Hallo!
Ich berichte hier noch einmal das Ergebnis von meinen Tests!
Wie angekündigt, habe ich nun die Anlage auf die neueste Version (inzwischen v20 U9 RC) gehoben und den Trunk mit dem neuen Template wieder mal parallel angelegt und dann umgeschwenkt und siehe da, alles funktioniert wie gewollt. Ich würde behaupten, dass das Template für VF Trunk V6 nun vollständig funktioniert, auch wenn DIDs im int. Format hinterlegt sind. Also wäre das Problem hiermit gelöst.
Eine schöne Zeit Euch!