Toggle sidebar Toggle sidebar

Spontane Probleme mit den Telekom Trunks

Hallo nochmal,

ich wollte mich noch mit einer anderen Erkenntnis zu Wort melden. Da wir noch einen 2ten Kunden hatten der nur Telekom Trunks eingerichtet hat, wollte ich dort ebenfalls die Anpassung des Transportprotokolls vornehmen. Dort kam es dann zu einem komischen Fehler. Nachdem ich die Trunks umgestellt habe haben diese sich dauernd wieder verbunden und getrennt. Danach hatte ich das Transportprotokoll zurück auf TCP gesetzt und es war wieder alles normal. Wurde also nur ein Teil der Anschlüsse umgestellt?

Liebe Grüße
Dennis Lamatsch
 
Hallo an alle,

auch wenn das nicht wirklich zu einer Lösung beiträgt will ich nochmal berichten was nun bei unserer Anlage der Fall ist.
Heute hatte ich für ein paar Test die Einstellungen im Telekom Trunk verändert. Als ich alles wieder normal gestellt habe verhielten sich die Trunks wieder sehr komisch. Es ist jetzt wieder abwechselnd angemeldet und abgemeldet. Änderung des Transportprotokolls har gar nicht geändert. Ich schaue mal wie es morgen aussieht glücklicherweise benötigen wir die Trunks nichts.
Ach ja und was die Kunden angeht dort ist soweit alles ruhig also spielen die Trunks wohl nur verrückt wenn man Sie verändert?

Liebe Grüße
Dennis Lamatsch
 
@Dennis Lamatsch
Ich habe bei meinem Trunk zur Telekom (tel.t-online.de) es soeben nochmal nachgestellt. Steht das Transportprotokoll auf Alle ist der Trunk sofort offline, schalte ich zurück auf UDP oder ALLE - ist er wieder grün.
M.e. hat die Änderung seitens Telekom immer noch Bestand, für Magenta Anschlüsse, wie auch Deutschland LAN IP oder auch Company Start 100 Verträge.
 
@Hermicus
Danke für deine Antwort. Ich habe es ebenso nochmal mit dem Transportprotokoll auf UDP probiert und nun scheint der Trunk wieder normal zu laufen. Muss ich gestern wohl übersehen haben.
 
Hallo zusammen,
ich hatte gerade ähnliche Probleme. Nach einem Neustart der Telefonanlage ohne das Veränderungen an Einstellungen vorgenommen wurden, haben sich alle 3 SIP-Trunks nicht mehr verbunden. Bei mir war das Transportprotokoll auf "alle" eingestellt, damit bekam ich keine Verbindung mehr. Dann habe ich das Transportprotokoll auf UDP eingestellt und hatte sofort eine Verbindung. Keine Ahnung was das soll. Will sich die 3CX wenn "alle" eingestellt ist in manchen Fällen trotzdem per TCP verbinden? Egal, jetzt Funktionierts wieder wenn das Transportprotokoll auf UDP eingestellt ist.
Noch ein paar Eckdaten:
- Telekomvertrag: Magenta Zuhause XL mit 3 Rufnummern die jeweils als eigener Sip-Trunk angelegt sind
- Telefonanlage läuft lokal im Heimnetzwerk
 
Ich hole mal den Thread nochmal hoch. Leider scheint mein Problem wohl das gleiche zu sein.
Folgende Konfiguration habe ich in meiner Praxis:
Telekom Magenta (wie oben erwähnt das Problemkind)
DynDNS
OPNSense mit Unbound und AdGuard
3CX on prem
3cx per Firewall Regel völlig freilaufen lassen mit DNS festgetackert, aber gleiches Problem.

Nun gibt es hier ja die vorgeschlagene Lösung, finde aber unter den Optionen bei den Trunks in der V20 nicht mehr die Möglichkeit die Transportprotokolle auf "alle" zu stellen. Ich glaube ich bin ein wenig blind...
Kann mir da jemand auf die Sprünge helfen?

Grüße!
 
hundsboog schrieb:
Nun gibt es hier ja die vorgeschlagene Lösung, finde aber unter den Optionen bei den Trunks in der V20 nicht mehr die Möglichkeit die Transportprotokolle auf "alle" zu stellen. Ich glaube ich bin ein wenig blind...
Kann mir da jemand auf die Sprünge helfen?
Zum Vergrößern anklicken....
Das ist im Template fest hinterlegt.
 
Möglichkeit 3 (komplett mit Bordmitteln in der 3CX):
  1. ändere unter Admin / Erweitert / Parameter den 3CX Parameter DEVELOPMENT_DNTABLE_EXPOSE von 0 auf 1
  2. lade die Browserseite neu (F5)
  3. oben in den nun zusätzlichen Tab Wählcode-Eigenschaften wechseln
  4. dort im Auswahlfeld oben den SIP Trunk mit dem richtigen Namen suchen
  5. dessen Parameter TRANSPORT_RESTRICTION auf ANY setzen
fertig
 
... oder eben wieder mal per Powershell und 3CX REST API:

Code: 
$tcxurl="mypbx.mydomain.de"     # needs port if not 443

$jsonauthbody = (@{
    Username="988"              # 3CX user, maybe email address
    Password="Super_Secret0815" # 3CX user password
    SecurityCode=""
} | ConvertTo-Json)

Add-Type -AssemblyName Microsoft.VisualBasic

$LoginResponse = Invoke-RestMethod -Uri "https://$tcxurl/webclient/api/Login/GetAccessToken" -Body $jsonauthbody -Method POST -ContentType "application/json"

if( $LoginResponse.Status -ne "AuthSuccess" ) {
    Write-Host "abort: authentication not successful"
    exit -1
}

$headers = @{Authorization = "Bearer $($LoginResponse.Token.access_token)"}

$uri="https://$tcxurl/xapi/v1/Trunks"
$tcxtrunks=(Invoke-RestMethod -uri $uri -headers $headers -Method GET -ContentType "application/json").Value

Write-Host "found SIP trunks:"
Foreach( $tcxtrunk in $tcxtrunks) {
    Write-Host "trunk ID:  $($tcxtrunk.Id)       name:  $($tcxtrunk.Gateway.Name)"
}

$title = 'get trunk ID'
$msg   = 'enter trunk ID to change TransportRestrictions to Any or enter 0 to leave'
$tcxtid = [Microsoft.VisualBasic.Interaction]::InputBox($msg, $title)

If( ($tcxtid -ne 0) -and  ($tcxtid.Length -ne 0) ) {
    Write-Host "change SIP trunk with ID  $($tcxtrunk.Id)  and name $($tcxtrunk.Gateway.Name) to TransportRestriction=Any"
    $uri="https://$tcxurl/xapi/v1/Trunks($tcxtid)"
    $tcxtbodyjson=@{TransportRestriction="Any"} | ConvertTo-Json
    Invoke-RestMethod -uri $uri -headers $headers -Method PATCH -body $tcxtbodyjson -ContentType "application/json"
}

Stichwort: Schnipsel
 
Zuletzt bearbeitet:
  • Like
Reaktionen: mbehrens und hundsboog
fxbastler schrieb:
... oder eben wieder mal per Powershell und 3CX REST API:

Code: 
$tcxurl="mypbx.mydomain.de"     # needs port if not 443

$jsonauthbody = (@{
    Username="988"              # 3CX user, maybe email address
    Password="Super_Secret0815" # 3CX user password
    SecurityCode=""
} | ConvertTo-Json)

Add-Type -AssemblyName Microsoft.VisualBasic

$LoginResponse = Invoke-RestMethod -Uri "https://$tcxurl/webclient/api/Login/GetAccessToken" -Body $jsonauthbody -Method POST -ContentType "application/json"

if( $LoginResponse.Status -ne "AuthSuccess" ) {
    Write-Host "abort: authentication not successful"
    exit -1
}

$headers = @{Authorization = "Bearer $($LoginResponse.Token.access_token)"}

$uri="https://$tcxurl/xapi/v1/Trunks"
$tcxtrunks=(Invoke-RestMethod -uri $uri -headers $headers -Method GET -ContentType "application/json").Value

Write-Host "found SIP trunks:"
Foreach( $tcxtrunk in $tcxtrunks) {
    Write-Host "trunk ID:  $($tcxtrunk.Id)       name:  $($tcxtrunk.Gateway.Name)"
}

$title = 'get trunk ID'
$msg   = 'enter trunk ID to change TransportRestrictions to Any or enter 0 to leave'
$tcxtid = [Microsoft.VisualBasic.Interaction]::InputBox($msg, $title)

If( ($tcxtid -ne 0) -and  ($tcxtid.Length -ne 0) ) {
    Write-Host "change SIP trunk with ID  $($tcxtrunk.Id)  and name $($tcxtrunk.Gateway.Name) to TransportRestriction=Any"
    $uri="https://$tcxurl/xapi/v1/Trunks($tcxtid)"
    $tcxtbodyjson=@{TransportRestriction="Any"} | ConvertTo-Json
    Invoke-RestMethod -uri $uri -headers $headers -Method PATCH -body $tcxtbodyjson -ContentType "application/json"
}

Stichwort: Schnipsel
Zum Vergrößern anklicken....

Okidoki!! Du hast mir schon einmal vor etwas längerer Zeit geholfen! Ich habe das jetzt mal mit den Bordmitteln umgestellt. Ich habe ja mehrere Rufnummern resp. Trunks. Muss ich das mit der Telekom eigenen Rufnummer machen oder mit *allen* MSNs machen? Auf jeden Fall vielen vielen Dank!!!! Das war grossartig!
 
Okay, habs mal selbst getestet. Nach umstellen von UDP auf ANY kommt keine Registrierung mehr zustande... ich glaube ich muss da wohl weiter suchen. Trotzdem habe ich wieder eine Menge gelernt!
 
Gut, also leider immer noch das selbe Problem. Meine Anlage de-registriert sich sporadisch 1-2 mal am Tag, gefühlt bei höheren Telefonie aufkommen (so meine Beobachtung)
Hier der Fehler:

Code: 
Call or Registration to number@(Ln.10001@Deutsche Telekom Hauptrufnummer) has failed. sip:xxx.xxx.xxx.xxx:5060;lr replied: Service Unavailable (503)

Nach einer manuellen Reistrierung beim Trunk läuft wieder alles einwandfrei.Es ist nur richtig unangenehm, da wir nicht wissen, ob die Anlage geht und wir erreichbar sind. Wir müssen immer erst uns selbst anrufen bzw. irgendwen anrufen um festzustellen, dass mit der Meldung am Fanvil Telefon ein "Not found" kommt. Daraufhin kommt die Notification Email, die das manuelle neuregistrieren nötig macht.

Was wurde bereits getan?

1. In OPNSense Firwall of "Conservative" gestellt
2. DNS Problematik ausgeschlossen (nslookup findet alles)
3. Firewall Check läuft problemlos durch.
4. Telekom kontaktiert, seriöse Mitarbeiterin, Leitung meines ALL IP wurde geprüft - alles ok. SIP Abteilung der Telekom kontaktiert.
5. NTP Server gecheckt, Zeitabgleich der 3CX VM (Debian), des Hosts (UnRaid) - alles syncron.
6. Im Telekom Telefonie Center Easy Login etc abgeschaltet.
7. In der OPNSense static port für die IP der 3cx und statt any UDP.
8. STUN Server Abfrage alle 120 Sekunden.
9. Veränderung von Dyn auf Static IP In der GUI der 3CX brachte keine Veränderung, Fehler bleibt

Es wundert mich einfach nur, weil dieses Fehlerbild urplötzlich aufgetaucht ist. Kann mich einer in die richtige Richtung weisen? Mit meinem 3CX Partner bin ich sowohl die Einstellungen in der OPNSense als auch in der 3CX per TV durchgegangen. Langsam gehen mir einfach die Ideen aus.

Erwähnenswert ist vielleicht noch, dass über das Wochenende, wo gar nicht telefoniert wird, die Registrierung erhalten bleibt.

Es tut mir leid, wenn ich nochmals schreibe.

Ganz liebe Grüße!
 
Zuletzt bearbeitet:
Seltsam denn ich habe die gleichen Einstellungen wie Du. Allerdings musste ich bei mir die Parameter auf UDP ändern. Mit ALL ging es auch nicht. Du hast wahrscheinlich auch ne Dynamische IP,oder ? Vielleicht liegt hier der Hase im Pfeffer ?
 
  • Like
Reaktionen: hundsboog
wallymgbh schrieb:
Seltsam denn ich habe die gleichen Einstellungen wie Du. Allerdings musste ich bei mir die Parameter auf UDP ändern. Mit ALL ging es auch nicht. Du hast wahrscheinlich auch ne Dynamische IP,oder ? Vielleicht liegt hier der Hase im Pfeffer ?
Zum Vergrößern anklicken....

Sorry, das habe ich auch geändert, ich füge das gleich noch hinzu! DIe Telekom refreshed ja alle 180 Tage. Damit gab es bekantermaßen Probleme, das stimmt. Allerdings hat das verstellen leider nicht gebracht. Der Fehler blieb leider! Danke, dass Du mich nochmal darauf auferksam gemacht hast!
 
Das mit der Telekom, ANY und UDP beschäftigt so einige. Bei unseren wenigen restl. Kunden mit so einem Anschluss funktioniert das aktuell über Monate hinweg ohne wieder dran rumfrickeln zu müssen. Sind alles 3CX ENT mit tlw. dyn. IP, Router Zwangstrennung wurde auf nachts nach 4 Uhr angenagelt (Modem Neustart per Software oder Zeitschaltuhr).

zu 5. Was läuft denn noch alles auf dem Unraid? Wir sind mit der Virtualisierung dort höchst unzufrieden gewesen. Letztendlich alle Tests eingestellt, sinnlos viel Zeit verplempert. Das kommt nicht wieder in die Werkstatt!

zu 7. Was meinst du mit und statt any UDP. ? Etwas in der OpnSense oder den Trunk in der 3CX? In der Firewall sollte static Port generell für die IP der 3CX aktiviert sein.

zu 8. STUN in dieser Zeitspanne: da kann es dir passieren, dass mal irgendwann gar keiner mehr antwortet, sonst andere testen, das kann man ja.
 
fxbastler schrieb:
zu 5. Was läuft denn noch alles auf dem Unraid? Wir sind mit der Virtualisierung dort höchst unzufrieden gewesen. Letztendlich alle Tests eingestellt, sinnlos viel Zeit verplempert. Das kommt nicht wieder in die Werkstatt!
Zum Vergrößern anklicken....

Hm, eigentlich läuft UnRaid hier super problemlos. Auch bei 10 meiner Kollegen gibt es da wenig Probleme und Beschwerden. Es laufen dort 28 Docker Container verschiedenster Dienste und 12VMs hauptsächlich mit Windows für die Praxis und die Abrechnung und eben Debian Maschinen inkl. der 3CX. Alles sehr problemlos und seit den Problemen von vor 3-4 Wochen wurde auch am Server nichts geändert.

Zu 7:

Bildschirmfoto vom 2024-10-10 17-40-57.png

Mein nächster natürlich ehrlich gesagt komplett überfälliger Plan ist, die 3CX in ein VLAN zu überführen oder mit einer 4 NIC Karte ihr eine echte Schnittstelle zu gönnen. Ob es aber daran liegt? Ich weiß es schlicht nicht, es kommt ohne dass ich was feststellen konnte, einfach im laufenden Betrieb. Lustigerweise änder sich auch die Farbe des Tunks nicht in rot sondern bleibt einfach grün. Vermaledeit! :-D
 
hundsboog schrieb:
Mein nächster natürlich ehrlich gesagt komplett überfälliger Plan ist, die 3CX in ein VLAN zu überführen oder mit einer 4 NIC Karte ihr eine echte Schnittstelle zu gönnen
Zum Vergrößern anklicken....
Gönn der testweise mal einen eigenen Computer mit nur einer NIC, einfach so.
hundsboog schrieb:
Lustigerweise änder sich auch die Farbe des Tunks nicht in rot sondern bleibt einfach grün.
Zum Vergrößern anklicken....
Ja, das ist es was nervt. Man sieht die reale Unerreichbarkeit nicht und kann das so eben auch nicht prüfen lassen.

Sonst wie immer der Rat: alle wichtigen Nummern auf einen echten Trunk eines anderen Provider portieren.
 
Um antworten zu können musst du eingeloggt sein.

Einstieg für Admins

Statistik des Forums

Themen
44.752
Beiträge
233.658
Mitglieder
78.496
Neuestes Mitglied
FS-CG
3CX Logo Footer Copyright © Sitemap Datenschutz Impressum
Oben Unten