Problem bei mehreren SIP-Trunks zu einem Provider

[x3mike]

Hallo liebe 3CX-ler,
ich hänge immer noch bei dem Problem, dass mehr als ein SIP-Trunk bei ein und dem selben Provider Probleme bereitet.

Meine Konstellation:
3CX: Professional Lizenz 16.0.1.273
3 SIP-Trunks

• SIP1: custno_1 - password1 (Firmenaccount)
• SIP2: custno_2 - password2 (Privataccount)
• SIP3: custno_3 - password2 (Privataccount) - dieser Account ist eine direkte Kopie von SIP2 nur mit anderem Benutzernamen. Also auch identisches Passwort.

"custno" ist hierbei meine Kundennummer beim Provider - also bei allen drei SIPs identisch. Der Benutzername unterscheidet sich jeweils nur durch _1 bis _3.
Der Provider benötigt bei ausgehenden Anrufen Proxy Authentication.

In der Konfiguration der SIP-Trunks sind alle drei Trunks korrekt verbunden - haben also den grünen Punkt.

Eine zusätzliche Nebenstelle zu 00 und eine Ausgangsregel, die ich für meine Tests auf den jeweils zu testenden SIP-Trunk hänge. Tests erfolgen alle mit der 3CX App auf einem iPhone.

Fehlerbeschreibung:
Habe ich mehr als einen SIP-Trunk bei dem gleichen Provider, gehen die ausgehenden Anrufe nur mehr bei einem der SIP-Trunks. Also Anmeldung geht, ausgehender Anruf nicht.

Probeweise habe ich durch ein falsches Passwort den funktionierenden SIP-Trunk "lahmgelegt". Dann geht einer der beiden anderen, der vorher nicht ging.

Fehlermeldung vom Provider auf Netzwerkebene:

Status-Line: SIP/2.0 403 Forbidden​

Tests für ausgehende Anrufe:
Begriffe: "geht" bedeutet, dass ein ausgehender Anruf klappt. "geht nicht" bedeutet, dass die Anmeldung auf Netzwerkebene zum Provider fehlschlägt.

• Alle 3 SIP-Trunks verbunden: SIP1 und SIP2 gehen nicht, SIP3 geht.
• SIP3 falsches PWD: 2 Trunks verbunden: SIP1 geht nicht, SIP2 geht
• SIP2 und SIP3 falsches PWD: SIP1 geht.
• Sobald nur ein SIP-Trunk verbunden ist, kann über diesen ein ausgehender Anruf getätigt werden - egal welcher Account dies ist.

Hinweis:
In den gemeinsamen Nachforschungen mit meinem Provider ist folgende Vermutung aufgetaucht: Der Provider verlangt bei ausgehenden Anrufen eine erhöhte Sicherheit durch Proxy Authentication. Es könnte sein, dass bei der 3CX die PA-Hashes bei gleichem Provider "verwechselt" oder falsch zugeordnet werden und damit die Anmeldung fehlschlägt.

Hinweis 2:
Dieses Fehlverhalten tritt bei der 3CX hinter der Firewall und auch komplett frei am Router - wo alle Firewall Tests OK sind - auf. Dies können wir als Ursache ausschließen.


Danke für Eure Hilfe!
Michael

 

[matictec]

Moin. Eure Vermutung dass irgendwas falsch zugeordnet ist,würde ich teilen. Am besten mal einen Wireshark-Capture machen und sich die Passwort Hashes bzw. die Authentifizierung mal genauer anschauen.

 

[x3mike]

Hallo Martin,
danke für die Rückmeldung! Ich hatte schon versucht, mit Wireshark die Unterschiede zu erkennen. Die Hashes kann ich hier leider nicht prüfen, denn diese werden mit jedem Verbindungsaufbau neu generiert und auf die internen Caches der 3CX hab ich keinen Zugriff - oder bekomme ich diese irgendwie heraus?
An den Provider werden sie nach der Anforderung für Proxy Authentication jedoch übermittelt.

 

[matictec]

Versuche mal folgende markierte Option zu aktivieren:


Eventuell musst Du dann aber die Parameter noch anpassen, damit es funktioniert.

Der Authentifizierungsprozess ist hier (https://andrewjprokop.wordpress.com/2015/01/27/understanding-sip-authentication/) noch mal sehr gut beschrieben. Wenn ich mir das so durchlese, dann dürfte das eigentlich nicht das Problem sein. Die Zuordnung an sich ist irgendwie krumm, die Option müsste zu einer strikteren Trennung führen.

 

[x3mike]

Hallo Martin,
nochmals danke! Der Artikel von Andrew Prokop beschreibt recht schön, was auch auf meinem System auf Netzwerkebene in Richtung Provider abläuft.
Interessanterweise tritt in meiner Konstellation das Problem nur dann auf, wenn ein weiterer SIP-Trunk erstellt wird. Habe ich nur einen, funktioniert dieser einwandfrei (INV > 407 > INV > OK). Sobald ich einen weiteren anlege - auch einen bis auf den Benutzernamen komplett identischen - funktioniert nur noch dieser.
Meine Vermutung liegt darin, dass die 3CX beim zweiten INVITE sich mit dem Nonce oder der internen Zuordnung verhaspelt. Mit nur einem SIP-Trunk funktioniert es ja einwandfrei und sobald ein weiterer hinzukommt, geht der erste, der zuvor funktioniert hat nicht mehr - bei ansonsten identischen Einstellungen des Gesamtsystems.
Die Eingangsparameter hab ich probiert - hilft leider nicht. Laut Text ist diese Option für Provider, die IP-basiert arbeiten.