Wartemusik Gigaset C430IP am Asterisk

Desdo

Neuer User
Mitglied seit
29 Jun 2020
Beiträge
8
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,
ich habe ein Gigaset C430IP an einem Asterisk angeschlossen. Wenn ich ein Gespräch vom DECT Handy zu einem anderen Asterisk-Teilnehmer weiterverbinden will, dann hört der Wartende nur sonderbare Geräusche. Man kann erahnen, daß es die Wartemusik vom Asterisk ist, klingt aber wirklich nicht gut. Verzerrt und viel zu leise. Der Weiterverbinden selbst funktioniert...

Beim Weiterverbinden mit den Snom-Telefonen am Asterisk hört sich die Wartemusik ganz normal an.

Hat jemand eine Idee, wo das Problem liegen könnte?

Gruß
Desto
 
Welche Sound-Dateien hast Du installiert, auch die sln16? Ansonsten mal die SIP-Nachrichten anschauen, ob neue Audio-Codecs ausgehandelt werden. Aber beides kannst Du schnell ausprobieren, indem Du Deinen Asterisk auf allow=!all,alaw stellst.
 
Hallo sonyKatze,
Danke für Deine Tips! Normal habe ich "allow=!all,g722,alaw,ulaw" Aber wenn man es nur auf den schmalbandigen Codec reduziert, bringt es auch keinen Erfolg. Ich gehe davon aus, daß das Gigaset C430IP (42.259) eine Macke hat. Alle anderen Snom-Telefone funktionieren einwandfrei am Asterisk (16.5.1).

Codec beim Gespräch ist laut "sip show channels" immer g722, auch beim Verbinden. Ein Codecwechsel findet nicht statt. Die Files liegen in allen Varianten vor, auch sln16. Aber im Normalfall transcodiert der Asterisk auch, alles schon getestet.

Ich hatte testweise mal ein Gigaset N510Pro (42.259) angeschlossen, damit funktioniert es einwandfrei. Allerdings signalisieren dann meine C570HX Telefone keine Anrufe in Abwesenheit.

Ich bleibe auf jeden Fall an der Sache dran.

Gruß
Desto
 
Merkwürdig, dass die Gigaset N510 IP Pro funktioniert. Kannst Du eine andere GO-Box 100 testen? In eBay sind die manchmal für unter 15€ zu haben, wenn Du ein ganzes Gigaset GO-Set nimmst, also nach „gigaset go“ suchst. Vielleicht hat nicht das Modell sondern nur Dein Geräte eine Hardware-Macke (oder es gab Hardware-Varianten und die Software hat auf einigen Hardware-Varianten eine Macke).
wenn man es nur auf den schmalbandigen Codec reduziert, bringt es auch keinen Erfolg.
Probiere mal wirklich nur alaw in Asterisk. Und schalte in der GO-Box alles andere außer alaw aus. Ist bei der einen Box die Lizenz für G.729 freigeschaltet und bei der anderen Box nicht? Wilde Spekulation, was soll G.729 damit zu tun haben, aber das ist einer der wenigen Unterschiede, die ich mir vorstellen kann.
keine Anrufe in Abwesenheit
Ist das dieser Software-Bug oder liegt das daran, dass Du kein Pro-Headset nutzt?
 
Ist das dieser Software-Bug oder liegt das daran, dass Du kein Pro-Headset nutzt?
Ich kann aus eigener Erfahrung berichten.
Da ich ein MT habe das nicht nur an einer N510 IP Pro, sondern auch an mehreren anderen TK-Anlagen (HiPath 3000, Octopus E Modell 300/800) arbeitet und dort als Systemmobilteil arbeiten soll, betreibe ich ein Gigaset SL4 professional. Das hat nie MWI gemacht. Ich habe dann, da ich am Standort der N510 IP Pro noch ein zusätzliches MT brauchte, ein SL610H gekauft und angemeldet. Das macht MWI, und seit dieses MT angemeldet ist, das SL4 wie durch Zauberhand auch :)
 
Irgendwie ist das logisch nicht begründbar. Ich würde da auch die Gigaset Basis nicht als Ursache sehen.

Ich kann es auch mit meiner Basis nicht nachstellen.

Wenn ich auf die R-Taste drücke um den Ruf zu vermitteln, dann wird die Asteriskanlage angewiesen MoH als RTP an den Gesprächspartner zu senden. Die Gigasetbasis ist an dem Vorgang der MoH nicht weiter beteiligt.

Hast du mal auf dem Asteriskserver einen tcpdump laufen lassen und dir die RTP-Streams dann angehört?
 
So, ich habe noch etwas getestet.

Es ist von G.722 abhängig!! Sobald ich diesen Codec im Gigaset C430IP aktiv habe, klingt die Wartemusik verzerrt und extrem leise. Man kann nur noch erahnen, daß es die Wartemusik vom Asterisk sein soll. Unabhäng davon, was ich im Asterisk an Codecs zulasse. Selbst bei "allow=!all,alaw" passiert der Fehler!

Sobald ich der C430IP Bx nur den Codec G.711a aktiv habe, funktioniert es einwandfrei! Auch bei "allow=!all,g722,alaw,ulaw" im Asterisk. In diesem Fall transcodiert der Asterisk zu G.722 vom anderen Teilnehmer.

N510 und S650H Pro funktioniert immer, egal welchen Vorrang die Codecs in den Einstellungen haben. Selbst das C570HX funktioniert an der N510 Pro Box, halt nur ohne Benachrichtigung der Anrufe in Abwesenheit.

> Kannst Du eine andere GO-Box 100 testen?

Leider nicht, ich habe nur die eine und die N510 mit dem S650H ist von einem Freund ausgeliehen

G.729 ist bei beiden Boxen freigeschaltet und beide Boxen haben die aktuelle Firmware drauf, die über das automatische Update kam.

Wie gesagt, G.722 scheint wohl einen Bug zu haben bei der C430IP...

Danke für die Tips!

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney


Hast du mal auf dem Asteriskserver einen tcpdump laufen lassen und dir die RTP-Streams dann angehört?

Nein, bisher noch nicht. Wie bereits eben geschrieben, es muß etwas mit diesem G.722 zu tun haben. Der Fehler passiert auch nur, wenn ich beim Gigaset auf die "R-Taste" drücke. Der andere Teilnehmer hört dann die verkorkste Wartemusik. Drück der Teilnehmer am Snom die "R-Taste" hört sich die Wartemussik auf dem Gigaset normal an!

Wie gesagt, wenn ich beim Gigaset C430IP nur den Codex G.711a erlaube ist alles ok. Aber halt nicht Sinn der Sache, wo doch heute alles HQ sein muß. :)
 
Zuletzt bearbeitet von einem Moderator:
bisher noch nicht.
Das wäre der nächste Schritt. Damit wir vielleicht sehen, was die Ursache ist. Normalerweise müsste sich eine GO-Box 100 wie eine N510 IP Pro verhalten. Hast Du an der einen Gigaset-Anlage noch DECT-Repeater im Spiel? Oder hast Du noch weitere „Leitungen“ laufen, nicht dass Du an das zwei-Gespräche-Limit der GO-Box 100 gestoßen bist.
 
Beides Nein, weder Repeater noch noch volle Belegung vom C430! Zwei C570HX sind bei der C430 eingebucht. Wenn, dann telefoniere nur ich alleine über eines der beiden DECT Telefone.
Die Firmware von C430IP und und N510IP Pro müsste trotz gleicher Versionsnummer unterschiedlich sein, weil das Gigaset C430 ja noch einen Analoganschluß hat.

Im Moment habe ich bei dem Gigaset nur den G.711 Codec in der Auswahl, dann funktioniert es. Der Asterisk transcodiert auf G.722
 
Die Firmware […] müsste trotz gleicher Versionsnummer unterschiedlich sein, …
Muss nicht, wenn die Firmware beim Geräte-Start solche Details automatisch erkennt und sich dynamisch anpasst. Auch berichten Einige, dass sie kreuz und quer updaten können. Aber ich wollte etwas ganz anderes damit sagen: Außer den zwei (GO-Box 100) bzw. vier (N510 IP PRO) Leitungen fällt mir nichts ein, was die beiden Geräte auf Seiten der Software unterscheidet sollte. Daher ist das merkwürdig. Ich habe Deinen Fall so gut es mir ging nachgestellt: Gigaset GO-Box 100, Gigaset E370HX, Digium Asterisk 13/chan_sip. Und bei mir kommt die Wartemusik sauber beim ersten Anrufer an – der aber bei mir nicht von extern kommt, sondern auch ein normale Nebenstelle an der Asterisk ist.

Daher bräuchten wir wirklich mehr Informationen in Form eines Paket-Mitschnitts. Vielleicht sehe ich so die Ursache bzw. die Unterschiede im Test-Aufbau. Vielleicht auch auch nur diese eine GO-Box 100 einen Schuss. Aber das sehen wir dann ja auch, wenn alles soweit gleich ist.
 
Du machst Dir ja echt Mühe mit meinem komischen Problem, Danke! Vielleicht sollte ich mir wirklich mal eine zweite Go-Box besorgen und schauen ob die sich gleich verhält. Im Anhang ist ein ZIP-File mit zwei Logfiles. Bei g711.log ist nur der g711 Codec beim C430IP aktiviert. Hier funktioniert die Wartemusik einwandfrei. Beim File g722.log passiert der Fehler. In diesem Fall ist nur der G.722 Codec im Gigaset aktiviert. Der Angerufene hört die verkorkste Wartemusik, wenn das Gigaset die Rückfrage einleitet.

201 (C430) ruft 200 (Snom 345) an. 201 leitet die Rückfrage ein [Wartemusik] 201 beendet die Rückfrage und legt auf.

Aber bitte nicht zuviel Zeit opfern! Ich habe das Gigaset jetzt auf "nur G.711" stehen, damit funktioniert es ja.
 

Anhänge

  • asterisk-c430.zip
    5.7 KB · Aufrufe: 2
Auch in dem Szenario kann ich den Fehler hier bei mir nicht nachstellen:
  1. Nutzt Du the SIP-Channel-Driver chan_sip oder chan_pjsip?
  2. Nur zur Kontrolle: Ist bei Dir direct_media aktiv – ich bin kein Freund davon –, laut den Logs hast Du es explizit deaktiviert.
  3. Nur zur Kontrolle: Du nutzt eine zwei Jahre alte Version von Asterisk, 16.5.0. Aktuell ist 16.22.0. Woher hast Du diese Version bzw. besteht ein bestimmter Grund, dass Du noch auf dieser Version bist?
  4. Nur zur Kontrolle, weil es auch damit bei mir nicht passiert: Du hast G.722-only genommen. War das auch im Ursprung so oder war dort G.722 + G.711?
  5. In der Web-Oberfläche der Gigaset Box existiert ein Menü-Punkt Warte-Melodie. Ich habe keine Ahnung wann die greift (nur zwischen DECT-Telefonen?). Hast Du damit schon gespielt?
  6. Über die Systemeinstellungen eines Mobilteils kannst Du die DECT-Verschlüsselung deaktivieren. Hast Du mal probiert?
damit funktioniert es ja.
Ja, aber wenn Einer das Problem hat und es in ein Diskussionsforum trägt, haben normalerweise Andere das Problem auch. Kann ein Konfigurationsfehler sein, ein Software-Fehler in der Box (allgemein oder Konfiguration verrenkt) oder ein Hardware-Fehler. Kann aber auch ein Fehler in Digium Asterisk sein. Daher sollte man sich so Sachen immer anschauen. Vielleicht profitiert die Community am Ende vom Ergebnis.

Schön wäre, wenn Du PCAP-Mitschnitte, also direkt Wireshark oder Ähnliches erstellen könntest. Dort dann auf „sip || rtp“ gefiltert. Das kann ich schneller lesen; dank der vielen VoIP/SIP-Features in Wireshark. Außerdem wäre so auch der Audio-Medienstrom (RTP) enthalten. Die Logs habe ich mir angeschaut, aber bisher nichts Auffälliges gefunden.
 
Zuletzt bearbeitet:
Hey sonyKatze,
ich habe mir jetzt ein Gigaset C430A bei eBay-Kleinanzeigen organisiert um einen Hardwarefehler auszuschließen. Es tritt der gleiche Fehler auf! Sobald G.722 in der Codecauswahl vom Gigaset aktiv ist, tritt der Fehler auf. Bei dem neuen Gigaset habe ich erst mit der installierten Firmware 42.243 probiert, aber genau das gleiche Problem wie bei der aktuellen 42.259

Zu Deinen Fragen:
1. Ich nutze chan_sip (veraltet, ich weiß)
2. directmedia=no
3. Faulheit bzw. noch nicht dazu gekommen. Die Software habe ich direkt bei asterisk.org als tar.gz geladen
4. Ursprünglich waren alle Codecs aktiviert. Aber Fehler ist nur weg, wenn ich G.722 aus der Liste der verfügbaren Codecs entferne
5. Hatte ich bereits ganz am Anfang gestestet, die Einstellung ändert nichts am Fehler. Ein oder Aus ist egal. (wirkt sich nur bei Verbinden unter den DECT Mobilteilen aus)
6. Gerade ausprobiert, ändert auch nichts

Zu Wireshark; Bisher habe ich mich damit noch nicht beschäftigt. Mal schauen, wenn ich etwas mehr Zeit habe. Aber vorher werde ich die neue Version vom Asterisk ausprobieren.
Im Prinzip habe ich jetzt alles ausprobiert, bleibt eigentlich nur noch der Asterisk selbst. Ich teste das bei Gelegenheit.
 
Ja, dann aktualsiere bitte auf den neusten Asterisk, denn Punkt 3 ist der einzige Unterschied, den ich aktuell sehe. Ich nutze auch chan_sip, ohne Direct-Media, Wartemusik ist auch hier egal sowie DECT-Verschlüsselung ist an. Nur auf Asterisk 16.5.0 möchte ich nicht zurück. Wenn Du eigene Patches eingespielt hast, kannst Du Dich alternativ auch von Version zu Version über die von Digium bereitgestellten Patches hochhangeln … trotzdem seltsam, dass es Deinen Gigaset N510 IP Pro nicht trifft.
 
Problem ist gelöst! Ich habe die letzten Tage endlich mal Zeit gefunden und meinen Asterisk auf die Version 18.9.0 aktualisiert. Gleichzeitig habe ich von chan_sip auf chan_pjsip gewechselt und ausgiebig getestet. MOH ist nun bei allen Endgeräten (Snom und Gigaset) einwandfrei. Firmware der Endgeräte wurde nicht verändert. Es lag wohl wirklich an der alten Version 16.5.0 vom Asterisk.

Vielen Dank für die Hilfe!
 
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.

IPPF im Überblick

Neueste Beiträge