[PROBLEM] Gesprächsanfang abgeschnitten

[hehol]

Hallo,

wir haben ca. 250 Apparate (300, 320, 360 und 1 x 370) an mehreren Asterisk-Servern (>= 1.2.9.1) im Einsatz. Uns ist aufgefallen, daß grundsätzlich die ersten ca. 500 ms jedes Gespräches (z.B. die erste Silbe, die der Anrufer spricht) auf beiden Seiten nicht gehört werden. Das Problem betrifft alle uns bekannten Firmwareversionen (getestet ab Version 5.5). Haben andere hier diesen Effekt auch? Gibt es irgendeine Möglichkeit, das Problem durch geeignete Konfiguration der Telefone oder der Asterisk-Server zu umgehen? Wir haben einen Test mit einem Thomson 2030 und einem Polycom 501 gemacht und diesen Effekt dort nicht festgestellt. Einen grundsätzlichen Konfigurationsfehler würde ich daher erstmal nicht annehmen.

Gruß
Henning

 

[stefanwillmerot]

Es könnte ein Asterisk-Thema sein, hatte ich auch mal. Prüfe mal die Dial-Optionen beim Rufaufbau nach extern, ob die Optionen "r" oder "R" benutzt werden und versuche statt dessen "early B3" falls Deine Hardware sowas kann oder lass "r" mal weg.

 

[0verkill]

Genau dieses Problem habe ich auch.
Dachte erst Codec, die habe ich aber jetzt wirklich alle auf G711a...
Ich versuche im moment bezahlten Support zu erhalten...

UPDATE:
Das mit dem Early B3 habe ich versucht. Leider bin ich kein Asterisk-Experte...
Ich verwende die Trixbox - habe dort meinen Dialstring auf "CAPI/ISDN1/$OUTNUM$/B" - so wie ich das sehe macht das "/B" einen echten B3, ein "/b" würde hier fake-B3 machen? Momentan sehe ich praktisch keinen uhnterschied zwischen B und b...

Von SNOM selbst gibt es auch eine erste Reaktion - hier ein kurzer Auszug:
"[...] Es handelt sich dabei um ein kürzlich entdecktes Phänomen, dass auftritt, weil Asterisk bei einem Rufaufbau den (vorher schon ausgehandelten) Codec wechselt und unser DSP damit eine kurze Verzögerungspause einlegt. [...]"

Habe daraufhin das Logfile nochmals gecheckt - bevor ich alle Codecs auf a-law hatte hatte ich soetwas im Log:
"chan_sip.c: Oooh, we need to change our formats since our peer supports only 0x8 (alaw) and not 0x4 (ulaw)"
Soetwas passiert aber definitiv nicht mehr...

 

[hehol]

Es könnte ein Asterisk-Thema sein, hatte ich auch mal. Prüfe mal die Dial-Optionen beim Rufaufbau nach extern, ob die Optionen "r" oder "R" benutzt werden und versuche statt dessen "early B3" falls Deine Hardware sowas kann oder lass "r" mal weg.

Daß die Dial-Optionen "r" und "R" Probleme am Gesprächsanfang verursachen, war mir schon bekannt. Die Optionen verwende ich nicht. ISDN-Optionen nützen leider auch nichts, denn die Gesprächslücke tritt auch bei Gesprächen von einem Snom-Apparat zum anderen auf - also ganz ohne daß ISDN im Spiel ist.

Von SNOM selbst gibt es auch eine erste Reaktion - hier ein kurzer Auszug:
"[...] Es handelt sich dabei um ein kürzlich entdecktes Phänomen, dass auftritt, weil Asterisk bei einem Rufaufbau den (vorher schon ausgehandelten) Codec wechselt und unser DSP damit eine kurze Verzögerungspause einlegt. [...]"

Habe daraufhin das Logfile nochmals gecheckt - bevor ich alle Codecs auf a-law hatte hatte ich soetwas im Log:
"chan_sip.c: Oooh, we need to change our formats since our peer supports only 0x8 (alaw) and not 0x4 (ulaw)"
Soetwas passiert aber definitiv nicht mehr...

Heißt das, daß das Problem bei Dir immernoch auftritt, obwohl Du durchgängig nur noch alaw in Asterisk erlaubst und G.711a als erster Codec auf dem Telefon eingestellt ist?

Gruß
Henning

 

[0verkill]

Ja - das Problem besteht auch mit durchgehendem G711a.
Inzwischen bin ich mit dem SNOM-Support weitergekommen:
Der Asterisk schickt ein Päckchen "SIP 183 Session Progress Message" zu Beginn des Gespräches. Darin fordert er das bereits ausgehandelte Codec nochmals an. Das führt zu einem Reset des DSP im SNOM, was zum Aussetzer führt.

Um das zu verhindern habe ich jetzt in die sip.conf folgendes eingefügt: "progressinband=never". Jetzt bekomme ich zumindest kein 183-Päckchen mehr am Anfang. Muss aber noch weiter testen, ob es das Problem wirklich abschließend behebt.

Übrigens habe ich alle Codecs im SNOM auf G711a gesetzt -> wusste mir nicht zu helfen, wie ich das sonst erzwinge. Etwas wie "use prefered codec only" gibt es ja leider nicht...

Die SNOM-Leute haben auf jeden Fall einen Trace von mir mit dem Fehler -> Hoffentlich arbeiten sie auch daran^^

 

[hehol]

Ja - das Problem besteht auch mit durchgehendem G711a.
Inzwischen bin ich mit dem SNOM-Support weitergekommen:
Der Asterisk schickt ein Päckchen "SIP 183 Session Progress Message" zu Beginn des Gespräches. Darin fordert er das bereits ausgehandelte Codec nochmals an. Das führt zu einem Reset des DSP im SNOM, was zum Aussetzer führt.

Ich habe das gerade auf einem unserer Asterisk-Server überprüft. Dort wird kein 183 session progress geschickt. Laut Doku ist ...

"progressinband=never". Jetzt bekomme ich zumindest kein

... auch die Default-Einstellung von Asterisk. Mein Test-Telefon schickt ein INVITE, der Server antwortet mit 100 Trying und dann mit 200 OK, wobei der erste Codec in der RTP map unverändert bleibt. Der von Snom beschriebene DSP-Reset muß also auch auftreten, wenn der Codec am Gesprächsanfang nicht erneut ausgehandelt wird oder das ist nur eine mögliche Ursache für das Problem.

Gruß
Henning

 

[hehol]

Hallo 0verkill,

gibt's irgendwelche Neuigkeiten von Snom?

Gruß
Henning

 

[0verkill]

Hi Henning!

Nein - aus dem Hause SNOM gibt es keine echten Neuigkeiten...
Case wird aber noch bearbeitet -> Ich habe inzwischen eine ganze Palette Traces geliefert, angeblich haben die auch noch ein Testsystem aufgesetzt...
Habe jetzt auch die neue Firmware 6.5.10 getestet -> aber das hilft auch nicht weiter.


Ich glaub´s wenn ich eine Lösung habe...

Natürlich werde ich die dann auch sofort hier posten

 

[mkubitza]

Hallo,

auch wir haben das gleiche Problem mit ca. 30 SNOM 360 Telefonen. Als erstes dachten wir das es an der junghanns quadBri Karte liegen würde - doch Herr Junghanns persönlich hat die Konfiguration getestet und als fehlerfrei abgenommen....

...auch wir hängen gerade dem Snom-Support in den Ohren - haben aber noch keine Lösung bzw. Tips erhalten.

zur Info:
mit einem Grandstream GXP-2000 tritt der Fehler nicht auf! Es liegt zu 98%iger Wahrscheinlichkeit an SNOM.....!?

Gruß
Martin

 

[0verkill]

Ich hab den SNOMies auch einen trace von einem Thompson 2030 geschickt -> Das funktioniert auch tadellos...

 

[hehol]

Hallo Martin,

wir haben von Snom den Hinweis erhalten, "progressinband=never" in die sip.conf einzufügen. Das löst das Problem aber nicht. Wenn man sich die RTP Payload im PCAP-Trace anhört, dann hört man auch den vollständigen Audiodatenstrom. Der Gesprächsanfang wird im Telefon abgeschnitten. Da man das im PCAP-Trace nicht erkennen kann, hoffe ich sehr, daß Snom das Problem nicht als unwichtig oder nicht reproduzierbar abtut :-/

Wir hatten inzwischen schon einige Beschwerden von Anwendern. Wenn der Anrufer z.B. "zu früh" seinen Namen sagt, dann muß man nach dem Namen immer nochmal nachfragen. Für den Betrieb an der Telefonzentrale oder in einem Callcenter ist das sehr lästig.

Henning

 

[mkubitza]

Den "progressinband=never" Hinweis habe ich auch von den SNOM-Technikern bekommen - aber, wie von Dir schon geschildert, ohne Erfolg!

Wir werden jetzt den Druck auf die Fa. SNOM massiv erhöhen, da dieser Fehler ein k.o.-Kriterium für die gesamte VoIP-Lösung darstellt! Wenn von denen keine Lösung zeitnah erarbeitet wird, gehen die SNOM-Telefone zurück an den Hersteller .... das Telefon ist bei uns halt - neben dem Computer - das wichtigste Werkzeug! Und das muss/sollte zu 99,995% funktionieren....

Schau' mr mal was wir erreichen können...!

Gruß

Martin

 

[oozoo]

Frage: Geht das bei euch ueber ne ISDN-Leitung raus?

oh - verlesen - tatsache. also bei uns ist gleiches aufgetreten mit quadBRI Karten von Junghanns und seitdem wir die durch Sirrix ersetzt haben hat sich das Problem erledigt.

 

[hehol]

Hallo oozoo,

oh - verlesen - tatsache. also bei uns ist gleiches aufgetreten mit quadBRI Karten von Junghanns und seitdem wir die durch Sirrix ersetzt haben hat sich das Problem erledigt.

Bist Du sicher, daß die Audioübertragung wirklich ab dem allerersten Moment funktioniert? Wenn ja, hast Du Asterisk trotz Sirrix-Karte noch mit Bristuff in Betrieb? Wir haben in unseren Servern, auf denen ich getestet habe, auch ISDN-Karten (S0 und/oder E1), aber das Problem tritt auch auf, ohne das ISDN im Spiel ist (also bei Gesprächen von SIP zu SIP oder wenn man z.B. die Voicemail abruft).

Gruß
Henning

 

[oozoo]

Hallo,

das Problem ist in unterschiedlichen Ausmassen aufgetreten, egal welche Konfiguration am laufen war, folgendes Szenario:

Wir haben die Mailbox eines Mitarbeiters mehrere Hundert Male mit Testanrufen bombadiert, dabei kam ein relativ klares Bild zustande und zwar, dass geringfuegige Aussetzer am Gespraechsanfang immer wieder auftraten aber nie 100% reproduzierbar, egal ob einfache ZapHFC Karten, Sirrix oder mISDN.

Mit Bristuff und der Junghanns Karte war es leider dann so dass regelmaessig nicht nur kleine Silben sondern mehrere Worte (!) fehlten (die Mailbox ist relativ zuegig beim Ansagen).

Also haben wir jetzt die Sirrix im Einsatz, sie ist dus.net (SIP-Provider) quasi ebenbuertig was die Aussetzer angeht (minimal und nicht immer) und das wichtigste: Der kleine Versatz faellt eigentlich niemandem auf - waehrend das Problem bei der quadBRI so massiv war dass es regelmaessig Beschwerden gehagelt hat.

Beispiel:
Originalansage: "Dies ist die IP-Phony Voicebox"
Kleiner Versatz: "ies ist die IP-Phony Voicebox"
quadBRI ".... IP-Phony Voicebox"

Nachtrag: Der Sirrix-Asterisk laeuft noch Bristuffed

 

[mkubitza]

Wie bereits gesagt: Das Problem tritt nur bei den SNOM-Telefonen auf. Wir haben eine zweite quadBRI Karte für eine alte Siemens-TK-Anlage eingebaut. Deren Systemtelefone haben beim Telefonieren "durch" die Asterisk-Anlage raus ins Telekom-Netz keine derartigen Probleme. Ich sehe den Fehler eindeutig auf der Seite der SNOM-Telefone ... natürlich lasse ich mich gerne eines Besseren belehren ... ;-)

Gruß

Martin

 

[jhansen]

Hallo,

ich habe das Problem auch, bei mehreren Kunden. Gibt es schon eine Lösung?

Viele Grüße

Jens

 

[galileo5]

Hallo, ich bemerke das Problem hier auch. Verwende Asterisk mit misdn und IAX / SIP und bin der Meinung, dass es nicht an der ISDN Karte (beronet) liegt sondern auch eher an den Telefonen, da ich die Aussetzter auch habe wenn ich intern telefoniere.

 

[mkubitza]

Zur Info:

Heute habe ich zwei SNOM 360 Phones mit dem wohl recht neuen Firmware 7.1.6 aktualisiert. Erste Tests waren vielversprechend - bei allen Testanrufen war der Gegenüber sofort hörbar!!

Ich werde am Freitag weitere Tests durchführen ... Info folgt!

Gruß

Martin

 

[hehol]

Heute habe ich zwei SNOM 360 Phones mit dem wohl recht neuen Firmware 7.1.6 aktualisiert. Erste Tests waren vielversprechend - bei allen Testanrufen war der Gegenüber sofort hörbar!!

Ich habe gerade mal ein snom 320 auf 7.1.6 aktualisiert. Das Verhalten ist tatsächlich besser als vorher, aber die (geschätzt) ersten 2-3 RTP-Pakete sind leider immernoch nicht zu hören. Ich habe das unter anderem mit der Ansage "Etwas geht hier fürchterlich daneben.", die in den deutschen Asterisk-Prompts enthalten ist, ausprobiert. Mit der Firmware 6.5.8 höre ich

"s geht hier fürchterlich daneben."

Mit der Firmware 7.1.6 höre ich

"was geht hier fürchterlich daneben." (manchmal auch "twas geht hier fürchterlich daneben.", aber das T am Anfang kann auch Einbildung sein)

Gruß
Henning