Asterisk mit 2 SIP Trunk Pure - ein Trunk geht / zwei Trunks keine ausgehenden Gespräche

umagaur

Neuer User
Mitglied seit
8 Jul 2019
Beiträge
26
Punkte für Reaktionen
3
Punkte
3
Hallo,

ich habe hier eine Asterisk 16 mit FreePBX 14 auf CentOS 7. Wir müssen unseren PMX auf SIP umziehen und ich teste gerade die Einstellungen.
Die Telekom hat uns 2 SIP Trunks Pure zur verfügung gestellt und ich habe beide über PJSIP eingerichtet. Die Trunks unterscheiden sich in der Rufnummer und Benutzernamen / Kennwort.
Outbound Proxy, from Domain, Server URI, Context und SIP Server sind gleich. Jeder Trunk für sich funktioniert, eingehend wie ausgehend.

Sobald ich jedoch beide Trunks einschalte ist nur noch eingehende Telefonie möglich. Direkt nachdem ich den Button Konfiguration anwenden drücke kommt von der Asterisk ein besetzt.

Ein tcpdump ergab das die Telekom bei zwei Trunks anstelle eines 401 mit anschließendem invite, ein 404 not found zurückgibt.
Auf der Firewall sehe ich das die Asterisk beide Verbindungen über einen tcp Port nach aussen leitet.

Laut Telekom liegt der Fehler auf unserer Asterisk da nicht 2 Verbindungen über einen tcp Port geleitet werden dürfen.

Meine Frage an euch wäre jetzt weiß jemand ob es einen Parameter auf der Asterisk gibt welcher Die Asterisk anweist jedem PJSIP trunk einen eigenen ausgehenden Port zuzuweisen ?
Ist die Asterist multiregistrierungsfähig und falls ja muß man das irgendwo einschalten oder ist das eine Grundfunktion ?

Falls jemand sonst eine Idee hat wieso 2 Trunks ausgehend über PJSIP nicht funktionieren einer jedoch problemlos (ohne konfigänderung nur an und abschalten) nur raus damit.
 
Laut Telekom liegt der Fehler auf unserer Asterisk da nicht 2 Verbindungen über einen tcp Port geleitet werden dürfen.
Das ist bei Asterisk / pjsip tatsächlich so. Beobachte ich hier auch - funktioniert hier aber, weil zwar mehrere Rufnummern (= Trunks) aber nur ein Account. Du hast unterschiedliche Accounts und möchtest die Nummern auf unterschiedliche Trunks binden (geht ja nicht anders). Damit hat die Telekom nun ein Problem, weil offensichtlich auch in diesem Fall der gleiche lokale Port für alle Verbindungen genutzt wird.

Lösungsansatz / Workaround:
Ich würde (falls möglich) eine (oder mehrere) Alias-IPs auf dem Server definieren und die Trunks an unterschiedliche IPs hängen. Damit sollte das Problem mit der Telekom bereinigt sein.
Falls das nicht geht weiß ich gerade auch keine Lösung - hab mal bei den Entwicklern nachgefragt.

--

Es ist derzeit nicht möglich, einen lokalen TCP Port an einen Trunk zu binden. In pjsip gibt es zwar dieses Feature neuerdings - aber noch keinen absehbaren Support in Asterisk dafür.
 
Zuletzt bearbeitet von einem Moderator:
Asterisk/PJSIP kann auch den "line" Parameter. Wenn "line" gesetzt ist und ein zugehöriger "endpoint", dann findet die Zuordnung nicht mehr über IPs, Namen, etc statt, sondern nur noch über den zufälligen "line" Parameter. Ob das anschliessend die Telekom selbst noch unterscheiden kann, weiss ich (noch) nicht.

Die eigentliche PJSIP Konfiguration wäre jetzt interessant: pjsip show endpoint/aor/identity/auth ... Nutzer und Kennwörter natürlich nicht.
 
Man könnte vielleicht eine bintec be.IP plus (oder Digitalisierungsbox Smart / Premium) als Session Border Controller dazwischen hängen.
 
Der line-Parameter ist in FreePBX 14 standard (geht gar nicht anders). Ist aber auch nicht das Problem - zumal ja inbound eh nicht das Problem ist (-> dafür wird der line-Parameter genutzt) sondern "nur" outbound!
 
Sorry, hatte ich überlesen. Da die Konten unterschiedlich sind, kann ich mir das nicht erklären. Reinkommend schon eher...
 
Die Angabe „der Telekom“ ist falsch.

Wenn sich beide SIP-Trunks in der selben TCP-Session registriert haben, können auch beide SIP-Trunks darüber kommunizieren.

Sind die PAI/PPI-Header in den ausgebenden INVITEs korrekt? So dass die Telekom die Calls korrekt zu den Registrierungen zuordnen kann...
 
@gehtdoch Ist das Produkt (ein account unterschiedliche Rufnummern / Trunks) von der Telekom ? Unser Vertriebler sagte bei unserem Produkt sei dies nicht vorgesehen sondern nur ein Account eine Rufnummer.

Line und endpoint Parameter habe ich nicht selbst eingetragen ist aber in der config vorhanden. Scheint also "Standard" zu sein.

Die Idee einen Session Border Controller dazwischenzusetzen hatte ich auch zuerst. Dann hätten wir aber eine weitere Komponente die ich redundant vorhalten muss. (zusätzlich zum Lync und der Asterisk) Wir sind eine Spedition das Telefon ist unverzichtbar. Deshalb sollte es so einfach und robust wie möglich sein.

@Meester Proper Ich habe ja 2 TCP Dumps einen mit Trunk A und einen mit Trunk A und B Die Meldungen die ich zur Telekom schicke sind in beiden Fällen absolut identisch.
Zum Testaufbau. Es ist ein Cisco Telefon mit dem ich mein eigenes Handy anwähle. (Die outboundroute für den Testtrunk zeigt nur auf mein Handy) Ich rufe an es geht tcpdump links - ich schalte den zweiten trunk an und drücke apply config und rufe erneut dieselbe Nummeran - fehler tcpdump rechts.
Ich erkenne im schritt 2 dem trying keinen unterschied zwischen einem oder zwei trunks auch das Session initiationProtocoll sieht für mich gleich aus
Ich erkenne keinen Grund warum bei einem Trunk ein 401 und bei zweien ein 404 kommt.
 

Anhänge

  • Session Trunks.PNG
    Session Trunks.PNG
    108.7 KB · Aufrufe: 24
  • Session Trunks_2.PNG
    Session Trunks_2.PNG
    159 KB · Aufrufe: 20
  • Session Trunks_3.PNG
    Session Trunks_3.PNG
    164.4 KB · Aufrufe: 14
Das Format in den FROM-Headern ist nicht korrekt.
Bei mehreren Trunks muss die Plattform zweifelsfrei unterscheiden können, über welchen Trunk das Gespräch geführt wird.
Dazu muss die Nummer im E.164 Format sein, also +4930123456.

Wenn nur ein Trunk registriert ist, kann über die TCP-Session die eindeutige Identifizierung vorgenommen werden.
 
@gehtdoch Ist das Produkt (ein account unterschiedliche Rufnummern / Trunks) von der Telekom ? Unser Vertriebler sagte bei unserem Produkt sei dies nicht vorgesehen sondern nur ein Account eine Rufnummer.
Ja klar - ALLIP standard - mit bis zu 10 Rufnummern. 0815... Läuft hier schon seit vielen Jahren schon mit den üblichen 3 Rufnummern - und sicher nicht nur hier!

Die Idee einen Session Border Controller dazwischenzusetzen hatte ich auch zuerst. Dann hätten wir aber eine weitere Komponente die ich redundant vorhalten muss. (zusätzlich zum Lync und der Asterisk) Wir sind eine Spedition das Telefon ist unverzichtbar. Deshalb sollte es so einfach und robust wie möglich sein.
-> keep it stupid and simple -> vollkommen korrekter Ansatz. Würde ich exakt auch so machen.

Ansonsten würde ich tatsächlich mal testen, den PAI-Header zu setzen. Das kannst Du in FreePBX machen pro Trunk (Hauptleitung). Findest Du bei pjsip Einstellungen -> erweitert -> Send RPID / PAI
Gleichzeitig muss dann aber auch Outbound CallerID in General gesetzt sein (Format weiß ich in Deinem konkreten Fall nicht - aber ich würde es mal mit +49... oder 49... oder 0049... versuchen). Und bei den CID-Options müsste dann Force Trunk CID gesetzt sein (damit asterisk da auch immer die eigene Rufnummer reinsetzt). Wie dann allerdings bei weitergeleiteten Calls die Original-Inbound-Rufnummer rausgeht, weiß ich nicht - das wäre dann evtl. der nächste zu klärende Punkt - das macht auch jeder anders - falls CLIP no Screening überhaupt unterstützt wird von diesem Produkt.

Wichtig bei einem Trace wäre übrigens der Invite. Hier ein Bsp. Den bekommst Du übrigens direkt in der Asterisk Shell:
Auf die Maschine, auf der asterisk läuft als root anmelden, dann:
Code:
[root@ast mnt]# asterisk -r
Asterisk 16.4.0, Copyright (C) 1999 - 2018, Digium, Inc. and others.
Created by Mark Spencer <[email protected]>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Connected to Asterisk 16.4.0 currently running on ast (pid = 1240)
ast*CLI> pjsip set logger on
PJSIP Logging enabled
Mit
Code:
pjsip set logger off
kannst Du alles wieder abschalten. Und dann die Rufnummer anonymisieren zum Posten.

--

Hier findest Du übrigens ein grundsätzliches Konfigurationsbeispiel für FreePBX 14 (allerdings für Telekom ALLIP - die Domain und Hostnamen musst Du anpassen). Ich glaube aber kaum, dass die formalen Anforderungen sich grundsätzlich unterscheiden - ist aber natürlich nicht ausgeschlossen. Ist zwar für TLS - aber dann nimmst Du eben den TCP-Transport.
 
Zuletzt bearbeitet von einem Moderator:
Ich teste das gerade mit den Send RPID / PAI Einstellungen und werte das log aus. Gehen tut es nicht aber vielleicht steht was im log.
Die Einstellungen von T-Online ist leider nicht so einfach übertragbar. Bei mir muss zwingend beim Usernamen die Anschluss Kennung drinstehen. Das ist auch das was Meester Proper wahrscheinlich stört. da kann beim Username kein +49xxx drinstehen da als Username die Anschluss Kennung gesetzt ist.

--

Das AllIP Produkt kommt mit bis zu 10 Rufnummern nicht in frage ich brauche Minimum ca. 300 Rufnummern und mindestens 20 Kanäle.
EDITH sagt Natürlich brauche ich nur eine Rufnummer aber mit 300 Durchwahlnummern Momentan haben wir einen 1000der Rufnummernblock am PMX
 

Anhänge

  • einstellung trunk 1_LI.jpg
    einstellung trunk 1_LI.jpg
    786.4 KB · Aufrufe: 17
  • einstellung trunk 2_LI.jpg
    einstellung trunk 2_LI.jpg
    736.7 KB · Aufrufe: 16
  • einstellung trunk 3.PNG
    einstellung trunk 3.PNG
    45.7 KB · Aufrufe: 13
Zuletzt bearbeitet von einem Moderator:
Hmm, habe mal ein wenig gestöbert und bin auf diese URL gekommen.
Teilweise scheinst Du es ja so gemacht zu haben. Entscheidend ist aber u.a., dass dort ein eigener Kontext eingezogen wurde, weil die Telekom gerne ihre eigenen Standards setzt ... .
 
Genau die Seite habe ich genommen um die Trunks zu konfigurieren. Den Context habe ich ebenfalls genauso eingetragen der ist aber ja für eingehende Gespräche relevant nicht für die ausgehenden oder liege ich hier falsch ?
 
Hast Recht - ich hatte es nur überflogen. Zusammenfassend nochmal: wenn Du nur einen Trunk aktivierst (entweder a oder b), funktioniert alles wie gewünscht - sobald Du beide aktivierst, geht outbound nicht mehr.

Wie gesagt - ich würde versuchen, mit zwei unterschiedlichen lokalen IPs rauszugehen. Habe das gerade spaßeshalber bei mir hier mal grundsätzlich getestet, ob die Einstellungen möglich wären - und sie sind möglich. Daher würde ich diesen Weg jetzt mal gehen.

Andere Variante - aber wesentlich aufwändiger - wäre, den beiden Trunks unterschiedliche Destination Server zu verpassen. Dazu müsstest Du einen eigenen Bind laufen lassen und eine geeignete RPZ anlegen und den Trunks unterschiedliche Zielservernamen verpassen oder sonst irgendwie sicherstellen, dass beide Trunks jeweils zu einem anderen Server gehen. Habe ich hier mal grundsätzlich beschrieben.
 
@Meester Proper Ich habe ja 2 TCP Dumps einen mit Trunk A und einen mit Trunk A und B Die Meldungen die ich zur Telekom schicke sind in beiden Fällen absolut identisch.
Zum Testaufbau. Es ist ein Cisco Telefon mit dem ich mein eigenes Handy anwähle. (Die outboundroute für den Testtrunk zeigt nur auf mein Handy) Ich rufe an es geht tcpdump links - ich schalte den zweiten trunk an und drücke apply config und rufe erneut dieselbe Nummeran - fehler tcpdump rechts.
Ich erkenne im schritt 2 dem trying keinen unterschied zwischen einem oder zwei trunks auch das Session initiationProtocoll sieht für mich gleich aus
Ich erkenne keinen Grund warum bei einem Trunk ein 401 und bei zweien ein 404 kommt.
Der Unterschied ist, dass wenn zwei Registrierungen in einer TCP-Session vorgenommen werden, die SIP-Trunk Plattform eine korrekte E.164-Nummer benötigt, um die Zuordnung zum SIP-Trunk bzw. dessen Registrierungen vorzunehmen.

Sendest du denn im INVITE im Contact-Feld die korrekte Rufnummer, also [email protected] (als Bespiel)? Die Plattform benötigt mindestens ein Feld mit korrekter E.164-Nummer, damit die Zuordnung zur Registrierung / Trunk vorgenommen werden kann.

Wenn nur eine Registrierung besteht, kann die Zuordnung über die aufgebaute TCP-Verbindung erfolgen, daher funktioniert dies auch.
 
Ich hatte ja auch schon darum gebeten, dass er mal einen INVITE posted (gewonnen, wie ich es beschrieben habe) - das würde wahrscheinlich am Weitesten bringen. Irgendwas scheint ihn davon abzuhalten. Sonst ist das alles hier nur Kaffeesatzleserei und Zeitverschwendung.
 
Noch was: Geht der INVITE über den korrekten zugehörigen Trunk raus? Das könnte evtl. auch ein Problem sein - dann wäre das Outboundrouting falsch.

Bitte die INVITEs für einen Outboundcall für beide Trunks posten - Du kannst die Nummern und User anonymisieren - aber die grundsätzliche Form muss beibehalten werden - genauso gleiche Strings müssen auch anonymisiert jeweils gleich sein.
Hilfreich wären u.U. auch die REGISTER für jeden Trunk - auch da bitte so anonymisieren, dass gleiche Strings im REGISTER die gleichen sind wie im INVITE. Am Besten die REGISTERs / INVITEs in einen Editor kopieren und auf kritische Strings einen globalen search and replace machen. IP-Adressen kannst Du auch anonymisieren - solange gleiche IPs auch immer gleich bleiben.
 
sorry das ich nicht sofort geantwortet habe, aber ich habe nicht immer einfluß darauf wieviel Zeit ich für diese Problemstellung habe.
Ich habe 2 Traces hier einen mit einem trunk und anruf der funktionierte und einen mit beiden Trunks aktiv auf dieselbe Rufnummer
Ich muß noch die Anonymisierung machen und lade sie dann hoch

--

Hi hier sind die beiden pjsip traces der erste mit 2 Trunks und RPID PAI an geschaltet in dem es ebenfalls zum 404 not found kommt und der zweite mit einem trunk aktiv wo der call zustandekommt.
Invite finde ich nur im tcpdump da habe ich ein Bild eingestellt das den gesammten Invite part zeigt unter contakt steht da aber die Asterisk. denke das ist nicht das richtige.
Das ist kein t-online account hier erfolgt die Registrierung nicht mit der Rufnummer sondern mit dem telefoniebenutzernamen. Siehe Bild 4 die Registrierung eines Trunks. Die Registrierung kann imho auch nicht das Problem sein da ohne korrekte Registrierung Inbound calls nicht funktionieren würden. Sollte das nicht korrekt sein lerne ich gern dazu.

Momentan tendiere ich dazu den zweiten Trunk nicht zu nutzen oder falls es unumgänglich ist eine zweite Box mit einer Asterisk aufzusetzen die ich über IAX anbinde.
dann hätte ich sicher einen anderen Sourceport.
 

Anhänge

  • trace_1_passerted identity_2_trunks.txt
    8.1 KB · Aufrufe: 4
  • trace_2_1trunk_call.txt
    29.1 KB · Aufrufe: 3
  • invite_tcpdump.PNG
    invite_tcpdump.PNG
    126.9 KB · Aufrufe: 7
  • registrierung.PNG
    registrierung.PNG
    11.6 KB · Aufrufe: 8
Zuletzt bearbeitet von einem Moderator:
Im Contact-Header muss sowohl in der Registrierung als auch INVITE deine Rufnummer im E.164-Format (+4989...) stehen.
Also statt
Contact: <sip:[email protected]:5060;transport=TCP>

Contact: <sip:[email protected]:5060;transport=TCP>

Das PAI-Feld muss ebenfalls als E.164-Nummer übermittelt werden.
 
Die Anpassungen für den Contact sollten über die Einträge in der jeweiligen Hauptleitung unter pjsip-Einstellungen -> Erweitert unter Kontaktbenutzer durchgeführt werden.

Allgemein zur Bedeutung einiger Felder in pjsip-Einstellungen -> Erweitert:

Client-URI: -> wird im REGISTER für To und From verwendet
From-User: -> wird im INVITE z.B. für From und Contact verwendet
Kontaktbenutzer: -> wird im REGISTER und im INVITE z.B. als Contact verwendet

In Deinem Fall würde ich für den Kontaktbenutzer einfach mal die UserID (Telefoniebenutzernamen) eintragen und verifizieren, dass er die auch wirklich nimmt.

Der derzeitige Contact
Contact: <sip:[email protected]:5060;transport=TCP>
macht eben nicht so viel Sinn ...
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.