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

[umagaur]

Ich weiß nicht warum die Asterisk den Kontaktbenutzer so setzt.
Eingetragen ist die Telefonnummer (war auch schon immer die Telefonnummer)
Das kann man im Beitrag 11 Bild 3 auch sehen. Das einzige was ich da mal variiert habe ist anstelle von 089 004989 und +4989
Geändert hat das aber nichts.
Habe ich nocht eine andere Möglichkeit der Asterisk zu sagen wie der Kontaktbenutzer aussehen soll ausser über pjsip erweitert kontaktbenutzer ?

 

[gehtdoch]

Hmm, ja - das riecht nach Bug. Was steht denn in der
/etc/asterisk/pjsip.registration.conf unter dem entsprechenden Trunk bei der Variable contact_user?

Zu erwarten ist sowas in der Art:

[DeinTrunkname]
type=registration
transport=0.0.0.0-tcp
outbound_auth=[DeinTrunkname]
retry_interval=60
fatal_retry_interval=0
forbidden_retry_interval=10
max_retries=10000
expiration=660
line=yes
endpoint=[DeinTrunkname]
auth_rejection_permanent=yes
contact_user=+49... oder evtl. Deine UserID
server_uri=sip:sip-trunk.telekom.de
client_uri=sip:+49[Rufnummer]@sip-trunk.telekom.de

 

[gehtdoch]

So, ich konnte Dein Contact-Problem im INVITE mittlerweile nachstellen. Das Problem ist, dass er als Contact im INVITE den User asterisk nimmt, solange kein "From user" definiert ist (der ist bei Dir leer). Im From im INVITE wird dann jeweils die Outbound Caller ID verwendet.

Wird ein "From user" verwendet, wird dieser sowohl für den Contact als auch für das From im INVITE verwendet (ich habe #20 entsprechend korrigiert). Der Contact im INVITE scheint nicht einzeln konfigurierbar zu sein.

Allerdings hat das natürlich den Nachteil, dass als From immer statisch dieselbe Nummer rausgeht. Daher müsstest Du bei "CID Options" "Jede Anruferkennung zulassen" und gleichzeitig "Send RPID/PAI" aktivieren - da wird dann entsprechend der "CID Options" die CID eingetragen, die beim Caller angezeigt werden soll. Ob das aber in der Form tatsächlich unterstützt wird, müsstest Du prüfen. Bei easybell geht es jedenfalls so.

 

[umagaur]

Ich habe
RPID/PAI aktiv gesetzt
Jede Anrufkennung zulassen gesetzt
und folgende Kombinationen, mit beiden Trunks aktiv; ohne erfolg bei ausgehenden Anrufen getestet

1) Contakt User / From User beide +49xxx
2) Contakt User / From User beide Benutzername
3) Contakt User / From User +49xxx / Benutzername
4) Contakt User / From User Benutzername / +49xxx

Ich danke dir und Meester Proper für die Hilfe. Ich habe die Einstellungen wieder zurückgestellt und beende die Tests hier. Ich werde mit einem aktiven Trunk arbeiten.
Den zweiten Trunk werde ich bei Bedarf entweder über einen anderen Anbieter realisieren oder ggf. eine zweite Asterisk aufsetzen und über IAX anbinden.
Ich hätte die Lösung zwar gern gefunden, aber hier steht Aufwand und Kosten in keinem Verhältnis.

 

[gehtdoch]

Kann ich verstehen. Trotzdem würde mich noch interessieren, ob Du tatsächlich sichergestellt hast, dass

1. der Call über den korrekten Trunk rausging (d.h., abgehende Rufnummer / From bzw. PAI muss zum Trunk (sprich Contact) passen) und
2. der Contact im INVITE tatsächlich gesetzt war

Beides siehst Du, wenn Du Dir den ausgehenden INVITE anschaust. Wenn nämlich einer der beiden Punkte nicht gegeben ist, wird es wohl auch nicht funktionieren. Wenn es hier Diskrepanzen gegeben hätte, müsstest Du das Routing korrigieren.

Wenn Du aber absolut keine Zeit mehr hast ist das auch ok.

 

[umagaur]

Als Abschlußinformation

Wir haben am WE komplett vom PMX auf SIP umgestellt. Die Umstellung erfolgte von Freitag Nacht auf Samstag morgen.
Ich mußte alle inboundrouten und den SIP Trunk anpassen dann lief es. Allerdings wollte die Asterisk einen Reboot damit das umleiten von Anrufen funktionierte. Rausrufen an sich ging, aber einen Anruf der Reinkam auf ein Handy umzuleiten (per Timecondition) lief bis zu einem Reboot auf Fehler.

Aktuell haben wir noch 2 Probleme für die Tickets bei der Telekom eröffnet sind
Bei Auslandsanrufen ist es wie beim blinken - geht - geht nicht. Die selbe Nummer ist in 5 Versuchen 1 bis 2 mal erreichbar und läuft 3 bis 4 mal beim Verbindungsaufbau auf Fehler.
Einige Firmen können uns nicht anrufen. Was ich herausgefunden habe ist, das die alle ebenfalls einen SIP Trunk der Telekom nutzen. Wir können diese Nummern anrufen. Die erste Reaktion der Telekom war das es unsere Anlage ist die auflegt. Die Ansage die die betroffenen hören passt dazu, (The Number you have dialed is not in Service) aber ich sehe auf der Asterisk im Log nicht mal den Versuch einer Verbindung. Ich denke die Routen den call an einen falschen SIP Trunk.

Noch einmal vielen Dank für eure Hilfe

 

[ubsyathEe]

Ich glaube nicht, dass die Telekom falsch routet. Ich habe mehrere SIP-Trunks am laufen und halte den SIP-Trunk für ein sehr gutes Produkt, das sehr stabil läuft. Jedenfalls hatte ich bisher noch nie Probleme damit (außer anfangs die schon speziellen Vorgaben der Telekom zu verstehen). Der ALL-IP Anschluss hat dagegen Schwächen, um es mal vorsichtig auszudrücken.

Bitte mal die SIP-Konfiguration hier angeben. Wahrscheinlich ist das Problem relativ leicht zu sehen.

 

[umagaur]

welche Dateien hättest Du gerne, ich lade die dann direkt von der Asterisk hoch ?
Ich nutze ja sonst die FreePBX Weboberfläche für die konfig und die ist schwierig mit screenshots hier einzustellen.

Du meinst tatsächlich das es eine einstellungssache ist, obwohl wir mehr als 500 fehlerfreie Anrufe am Tag haben nur ein halbes dutzend Firmen (in den ersten 3 Tagen) die alle einen Telekom SIP Trunk haben können uns nicht erreichen. (Wir sie aber schon) und das obwohl die Asterisk im Log nicht mal den Versuch eines Verbindungsaufbaus zeigt ?
Ich mein der Teufel ist ja bekanntlich ein Eichhörnchen und ich lerne jeden Tag dazu. ergo schließe ich nicht aus das du recht hast.

Drei der Kunden haben mir erzählt das sie nach der Umstellung die selben Probleme hatten und das die Telekom eine Woche gebraucht hat um das zu bereinigen (das Leute Sie nicht anrufen können) Einer hatte noch das Ticket der Telekom in denen Sie im Abschluss Bericht von Routingproblemen sprachen.

 

[ubsyathEe]

Ja, ich halte das für wahrscheinlich.

Es geht hier ja anscheinend nicht um eigene Anrufe, sondern um Erreichbarkeit und das könnte mit der Registrierung zusammenhängen. Verwendest Du in FreePBX chan_sip oder den neueren PJSIP-Stack? Nur der PJSIP-Stack macht die von der Telekom verlangten NATPR/SRV Abfragen richtig.

Unabhängig davon, was ist der Konsolenoutput von "sip show registry" bzw. "pjsip show registrations"? Gibt es schon Merkwürdigkeiten, wenn man mehrere Minuten lang "sip set debug on", bzw. "pjsip set logger on" eingibt? Statt sip.conf oder pjsip.conf wird das später dann hier mit pjsip show aor ..., pjsip show registration ..., etc weitergehen. Mit der FreePBX-Oberfläche kenne ich mich nicht aus, weiß aber, welche Parameter funktionieren.

Nicht alle wichtigen Fehlermeldungen tauchen in den Log-Dateien auf...

 

[umagaur]

Wie du schreibst hat es mit dem chan_sip nicht funktioniert. Nur mit dem PJSIP geht die Telefonie.

sv-pbx-01*CLI> pjsip show registrations
<Registration/ServerURI..............................> <Auth..........> <Status.......>
==========================================================================================
551133XXXXXX/sip:sip-trunk.telekom.de:5060 551133XXXXXX Registered
Objects found: 1


sv-pbx-01*CLI> pjsip show registration 551133XXXXXX
<Registration/ServerURI..............................> <Auth..........> <Status.......>
==========================================================================================
551133XXXXXX/sip:sip-trunk.telekom.de:5060 551133XXXXXX Registered
ParameterName : ParameterValue
=====================================================================
auth_rejection_permanent : false
client_uri : sip:[email protected]:5060
contact_user : +498935XXXXX
endpoint : 551133XXXXXX
expiration : 480
fatal_retry_interval : 300
forbidden_retry_interval : 300
line : true
max_retries : 10
outbound_auth : 551133XXXXXX
outbound_proxy : sip:reg.sip-trunk.telekom.de
retry_interval : 60
server_uri : sip:sip-trunk.telekom.de:5060
support_path : false
transport : 0.0.0.0-tcp


Ich sehe auf den ersten Blick bei pjsip logger on keine Auffälligkeiten.

Evtl habe ich für die Auslandsanrufe (Problem 1 ausgehend) etwas gefunden. Ich habe gelesen das einige Provider länger brauchen um die Bestätigung für ein "connect" bzw "ring" zurückzugeben. Deshalb habe ich im Lync den Timeout für den Failovertimeout verdoppelt. Das kann ich aber erst morgen verifizieren da der Server dafür booten muß.

EDITH sagt: Beim debug sind die Daten ja recht umfangreich. Ich kenne die Telefonnummern der Kunden die nicht bei uns anrufen können (eingehend Problem 2) Gibt die Asterisk ein erweitertes Debug her bei der ich den Debug auf die Daten diese Telefonnummer betreffend eingrenzen kann ? (Falls du den Befehl dafür parat hast wäre ich dankbar dafür) Dann würde ich den Kunden anrufen und ihn bitten einen Anruf zu machen. Kommt er an liegt es wohl an mir wenn nicht ist die Telekom schuld.

Falls so ein Debug nicht möglich ist würde morgen das ganze mit einem TCP Dump probieren.

 

[ubsyathEe]

Ich kann auch keine Auffälligkeiten entdecken. Der einzige Unterschied bei ist bei mir "loose routing" für die "server_uri":

server_uri               : sip:sip-trunk.telekom.de

 

[umagaur]

hast Du den edit noch gelesen ?

Kennst du zufällig den genauen Befehl wie ich am besten den Debug einstelle um quasi jeden kommunikationsversuch zu erkennen ?

 

[ubsyathEe]

Die erste Reaktion der Telekom war das es unsere Anlage ist die auflegt. Die Ansage die die betroffenen hören passt dazu, (The Number you have dialed is not in Service) aber ich sehe auf der Asterisk im Log nicht mal den Versuch einer Verbindung.

Das ist mit einem pcap-Trace leicht rauszukriegen wer rausruft, bzw. versucht reinzurufen. Streng genommen sind obige Angaben widersprüchlich, da man nicht auflegen kann, wenn nichts reinkommt, was bei der Ansage der Fall wäre. Es könnte aber gemeint sein, dass der Anruf nicht entgegengenommen wird, d.h. signalisiert wurde, aber sich die Anlage nicht für zuständige gehalten hat.

Testweise würde ich einen s-Kontext aufmachen, so wie etwas in der Form _X. um wirklich alles abfangen zu können was rein kommt. Kann man später wieder löschen.

--

Kennst du zufällig den genauen Befehl wie ich am besten den Debug einstelle um quasi jeden kommunikationsversuch zu erkennen ?

Ich würde hier tcpdump auf der WAN-Schnittstelle vorziehen, damit man wirklich mit Wireshark sieht was von draußen vom Walde kommt. Kann sein, dass mit "core set debug 5", oder so, auch noch sinnvolle Nachrichten reinkommen.

 

[umagaur]

Dann mache ich morgen mal einen TCP Dump auch wenn ich nicht daran glaube das es meine Anlage ist.
Damit die Ansage kommt müsste meine Anlage ja vom Sip Trunk einen Call bekommen für den Sie sich nicht zuständig sieht und ihn dann abweisen.

Dieselbe Nummer die die Kunden mit dem Fehler anrufen wird ja von 100+ anderen ohne Fehler erreicht. Ich habe unsere zentrale mit 004989... +4989.... 089xxxx und xxxxx angerufen und kam immer durch.

Wenn ich die ergebnisse des Dumps habe werde ich berichten oder wenn die Telekom sich meldet.

 

[ubsyathEe]

... mir ist das schon passiert. Seitdem habe ich anfangs immer einen Fliegenfänger im Wählplan. So kann man dann auch bestimmter gegenüber der Telekom auftreten.

 

[umagaur]

Damit wir auch vom selben sprechen der Fliegenfänger ist quasi eine Inboundroute in der Form _X und die leitest Du dann ins Nirwana oder an deine Telefonanlage ?
Ich bin ja nicht so Firm mit der Asterisk und die Inboundrouten kann man ja nicht in eine Reihenfolge setzen die gehen falls ich das Konzept richtig verstanden habe von genauer zu ungenauer wenn ich als zum Beispiel
_x
_+4989[123]4567X
+498912345678

hätte würde als erstes die route an nummer 3 ziehen dann die an 2 und die erste alles nehmen was übrigbleibt - korrekt oder Denkfehler ?

 

[ubsyathEe]

Ich kenne mich mit FreePBX nicht so gut aus, aber man braucht keine Reihefolge festzulegen (wird von Asterisk intern gehandhabt). Der Einfachheit halber würde ich die Muster _X. (der Punkt is wichtig!), _+X., und s an eine lokales Gerät weiterleiten. In Asterisk selbst würde man das nicht machen, sondern nur mit Verbose() was auf die Konsole schreiben um zu sehen, was da wie ankommt.

 

[umagaur]

Entspannung an allen Fronten …...

Die Auslandsgespräche liefen heute Morgen ohne Probleme. Da war die Erhöhung des Failover Timeouts, beim Outbound Routing, auf dem Lync Server die Lösung

Das Problem der nicht ankommenden Inlandsgespräche konnte ich dank dir ebenfalls lösen. Ich habe ein Inbound Route mit _X. konfiguriert die ich auf ein SIP Telefon neben meinem Schreibtisch laufen lasse. So konnte ich sehen das die Telekom nicht nur +4989XXXX reinroutet sondern auch 089XXX und XXX.
Die letzten beiden allerdings nur von SIP Trunks der Telekom. Alle anderen Netze oder zb ISDN vervollständigen sie anscheinend. Das hat uns der Telekomtechniker bei der Planung des SIP Trunks zwar anders kommuniziert aber was solls.

Dir vielen Dank, Du hast mir mit deiner Idee eine Menge Arbeit erspart.

Ich habe jetzt zusätzliche Routen angelegt um die anderen Übergaben abzudecken. Also
_+498935XXXXX
_08935XXXXX und
35XXXXX
gibt es einen Trick um aus den dreien eine route zu machen ?

 

[Meester Proper]

Kann es sein, dass hier fälschlicherweise nach dem To-Header geroutet wird und nicht nach der P-Called-Party-ID (insofern die Registrierung nicht nach RFC6140 erfolgt)?
Letztere liefert immer eine E.164 (+49..) Rufnummer.

 

[umagaur]

Die Telekom übergibt natürlich alle Felder aber ich kann die soweit ich es sehe mit der Asterisk 16 und der Benutzeroberfläche FreePBX 14 für das Routing nicht auswerten. Dort kann ich als Match für die Inboundroute nur die DID angeben. Ich habe keine Möglichkeit anzugeben welches Feld ausgewertet wird. Oder habe ich die Frage falsch verstanden ?