Da es keine Möglichkeit mehr gibt per ! in das Unix Terminal zu wechseln und somit das SIP Debugging nahezu unmöglich geworden ist, würde ich mich freuen, wenn ich in den SIP Accounts im Backend die letzten SIP Header einsehen könnte, um Probleme ohne Support debuggen zu können.
2 Likes
Hallo,
eventuell könnte das pascom Team mal versuchen sngrep in ihre Container zu implementieren. Bei einem Docker Container bekommt man es hin! sngrep ist ein sehr hilfreiches Tool, womit ich bei anderen Asterisk anlagen schon so manchen Fehler gefunden habe.
3 Likes
Mehr Debbuging Möglichkeiten würden wir auch begrüßen!
Das wäre unserer Ansicht nach “more power to the partner” 
ich hab das gefühl, das die partner hier gar nicht mehr debbugen sollen 
allein ein wireshark mitschnitt würde schon helfen… aber ich bekomm das bei “komischen” probleme, zum glück, dann von meinem provider
Ja das ist schon richtig früher konnte man ja noch in den Container ausbrechen das geht ja jetzt auch nicht mehr. Was ich durchaus aus Sicherheitsgründen verstehen. Aber ja so ein TCP Dump ware schon ne feine Sache.
Hallo,
wie schon vermutet sind es primär Sicherheitsgründe, weshalb der Zugriff auf die Shell/Abseits der Asterisk CLI unterbunden wurde. Natürlich käme es auch uns gelegen - gerade bezogen auf das Debugging - unseren Partnern und Kunden hier mehr Möglichkeiten bereitzustellen.
Eine, wenn auch zugegeben unübersichtliche, Möglichkeit an die SIP Nachrichten heranzukommen, gibt es aber auch innerhalb der AsteriskCLI:
pjsip set logger {on|off|host <name/subnet>
Für reproduzierbare Fälle kann man dann das Logging via “pjsip set logger on” bespielsweise für alle Nachrichten aktivieren, nachstellen und sich das hierüber ansehen. Bei sporadischen Problemen ist das natürlich nicht sehr sinnvoll. Meist ist aber ohnehin der SIP Provider gefragt, der i.d.R. die SIP Logs für 48h vorhält.
Bei Problemen mit bestimmten Standorten/Benutzern/Endgeräten hat mir die Vergangenheit häufig aufgezeigt, das sich der Kunde nicht für ein “sehen Sie hier fehlt dieses Paket/ist diese Information in diesem Header falsch” interessiert und man meistens mit einem “sehen Sie: diese Konstellation funktioniert zuverlässig, das Problem muss also an dieser Stelle liegen” auf mehr Verständnis stößt.
Probleme mit bestimmten Endgeräten/SIP Providern/bestimmten Zielen bei bestimmten SIP Providern, welche dann wirklich die tiefergreifende Analyse bedürfen, müssen dann ohnehin wir mit entsprechenden Stellen im direkten Kontakt (oder eigenen “Laborbedingungen”) klären.
Grüße,
Steve
Da ich ja leider der einzigste bin, der gnTel verwendet, kann ich leider nur von mir sprechen: wir als Partner können direkt mit dem Support reden und dieser kann uns dann den Trunk loggen, auswerten oder auch mal an der Firewall prüfen was kommt 
So haben wir dann festgestellt, das bei aktivierter TLS option im generischen SIP Amt keine Anfragen mehr von der pascom Cloud an der gntel Firewall ankommen, und sich deshalb sich der Trunk auch nicht mehr registrieren kann. Da leider dieser Support, den gntel liefert, nur MIR als Partner einen Mehrwert bietet, nicht aber der pascom, wird weder der gntel trunk zertifiziert noch erhalte ich Support bei Probleme am Trunk
falls jemand diese Vorteile auch wichtig wären, einfach melden 
Bei allen andere Providern: es wäre durchaus sinnvoll, den Partner etwas debug Möglichkeiten zu geben… gerade wenn z. B. Das magenta T im logo ist
Das funktioniert in der Theorie, jedoch nicht in der Praxis, da die CLI jede Aktivität sofort anzeigt und weiterscrollt und man sich den Log nicht ansehen kann. Wenn es im Backend die Möglichkeit gäbe das Loggen zu starten und einsehen oder noch besser die letzten SIP Logs sofort sehen zu können, würde das enorm weiterhelfen, vor allem dann, wenn die Verbindung zum Provider fehlschlägt.
Wir Debuggen nahezu alles über den Provider, aber einiges hätte ich mit SIP Logs auch ohne Support gelöst bekommen und manches kann ich nur in Pascom debuggen.
Man braucht es nicht oft, aber wenn man es braucht, erspart es Support-Kommunikation.
2 Likes