IP-S400 , be.IP Plus, Telekom All-IP: Kein Rufzeichen ausgehend, Verbindung kommt aber zustande

G.Nagus

Neuer User
Mitglied seit
3 Mrz 2016
Beiträge
30
Punkte für Reaktionen
0
Punkte
6
Hallo Kollegen,

mich beschäftigt ein Problem, das ich mit dem IP-S400 auf 2 betreuten Anlagen habe:

Bei einem ausgehenden Anruf von besagtem Telefon hört der Anrufer kein Rufzeichen. Jedoch meldet sich der angerufene TN ganz normal, das Gespräch verläuft im Weiteren problemlos.

Für den Anrufer ist das natürlich lästig, wenn er nicht sicher sein kann, ob es an der Gegenstelle klingelt und der Angerufene nach einer Periode der Stille plötzlich einfach dran ist.

Ansonsten hat das Telefon keine Probleme - eingehende Anrufe und sonstige Funktionen verlaufen normal.

Beide betroffenen Anlagen hängen an einem All-IP-Anschluss der Telekom.

Eine der betroffenen Anlagen hat intern ein weiteres ISDN-Telefon angeschlossen. Hier treten diese Probleme nicht auf.

Das IP-S400 hat die aktuelle Firmware V5.240. Die betroffenen Anlagen haben unterschiedliche Firmware-Stände (einmal etwas älter, einmal aktuell), die Symptome sind jedoch gleich.

Weiß jemand Rat, woher das kommt und wie man das beheben kann?

Besten Dank im Voraus!
G.N.
 
Ich würde mal den Audio Codec auf G711 aLaw festlegen.
 
Hallo Kalle,

Dankeschön für die rasche Antwort.

Ist das so zu verstehen, daß ausschließlich dieser Codec verwendet werden soll?
Standardmäßig sind doch da auch der G711 uLaw und der 729 aktiv, wenn ich nicht irre.

Ich bin mir nicht sicher, ob ich den Fehler intern oder extern suchen muß. Würde denn eine vom internen ISDN-Apparat nach außen per VoIP-Verbindung aufgebaute Verbindung nicht genau so unter einem unpassenden Codec leiden?

Merkwürdig ist auch, daß dieses Verhalten nicht sofort nach Inbetriebnahme der Anlage zu beobachten war, sondern erst seit ca. 2 Monaten (ohne zwischenzeitlichen Eingriff ins System).

Was ich noch vergessen hatte zu erwähnen: An beiden betroffenen Telefonen ist außerdem die Sprachqualität in Senderichtung nicht überzeugend. Das Phänomen könnte man als eine Art digitales Übersteuern beschreiben (Knacken, Kratzen, Aussetzer - immer wenn von diesen Telefonen aus gesprochen wird). Die Empfangsrichtung scheint in Ordnung.

Danke & Gruß,
G.N.
 
Hallo,
das liegt definitiv nicht am Codec. Wenn der Codec nicht passt, würde mindestens in einer Richtung kein Audiosignal übertragen werden.
Da der VoIP-Verbindung nach außen ein Codec-Profil zugeordnet ist, sollte es keine Rolle spielen, von welcher Endgeräteart das Telefonat ausgeht. Bei einem IP-Endgerät ist zu beachten, dass da nicht nur das Codec-Profil zum VoIP-Anbieter greift, sondern auch das, was dem Endgerät selbst zugeordnet ist.

Ich habe im Büro ein IP-S400 im Einsatz (... noch ...) und beobachte gelegentlich das gleiche Phänomen in Verbindung mit einer hybird 300 seitdem ich auf IP-Telefonie umgestellt habe. Bislang kann ich aber keine Regelmäßigkeit feststellen - außer der Tatsache, dass nur Externgespräche betroffen sind. Ich kann es auch nicht an der Art der Gegenstelle (klassich analog, klassisch ISDN, IP) festmachen.
Das mit dem Übersteuern habe ich noch nicht beobachtet.
bintec elmeg empfiehlt an einem Telekom-Anschluss den Codec G.711a und DTMF zu aktivieren.

Generell sind die IP-S-Systemtelefone wohl nicht ganz unkritisch. Ich telefoniere seit zwei Jahren über IP. Seitdem haben sich die IP-S-Telefone in einigen Fällen als Störenfriede gezeigt. Einige Fehler wurden mittlerweile durch neuere Firmware in der Anlage behoben.
Aufgrund dieser Erfahrungen setze ich nach Möglichkeit keine IP-S-Telefone ein.

Übrigens: Bei einer Wahl über eine TAPI-Anwendung (z.B. ESTOS ProCall) tritt das Phänomen nicht auf.
 
Hallo SFA1492,

danke für das (beunruhigende) Statement. Es ist zwar schön, wenn man nicht der einzige ist, aber...

Interessant finde ich den Teil, wonach das Problem nicht auftritt, wenn per TAPI gewählt wird. Dann ist ja die Verbindung zwischen Anlage und IP-S400 auch quasi eine interne Verbindung. Den externen Teil erledigt die TAPI-Anwendung.

Sprich, für mich sieht es zunächst so aus, als funktioniere etwas im Zusammenspiel zwischen IP-S400 und be.IP Plus nicht.
Was gegen diese These spricht ist, daß das Phänomen nicht durch eine Änderung an Soft- oder Hardware ausgelöst wurde, sondern spontan aufgetreten und dann geblieben ist. Dies deutet (für mich) darauf hin, daß es eine weitere Komponente geben muß.

In meiner Phantasie (verzeiht mir, liebe Ingenieure und Technikaffine) muß es also etwa so ablaufen:

Bei der Kommunikation mit der außen liegenden Technik der Telekom gelangen Informationen zum anlagen-internen Stack mit nach draußen. Hängt innen ein Gerät mit Signalen, die entweder in der Anlage gewandelt werden (internes ISDN-Telefon) oder die sauber programmiert sind (ESTOS-Schnittstelle), dann gelangen ausschließlich "saubere" Signale aus der Anlage nach draußen - und alles funktioniert bestens.

Ist jedoch etwas unsauber programmiert (IP-S400), gelangen diese Unsauberkeiten mangels weiterer Wandlung ebenfalls nach draußen. Während nun früher die Vermittlungsstelle damit umgehen konnte, hat es vielleicht vor nicht allzu langer Zeit Änderungen an aktiven Komponenten oder Protokollen im Telekom-Netz gegeben, die weniger tolerant für solche Fehler sind. Mithin das fehlende Rufzeichen.

Ich weiß, das klingt alles ein bißchen esoterisch - aber vielleicht kann jemand, der genau weiß, was die Anlage bei Betrieb eines IP-Telefons alles "nach draußen" mitliefert, hier etwas Licht in's Dunkel bringen.

Ich werde also mal ein Codec-Profil anlegen, das ausschließlich (?? diese Frage bleibt) G.711a und DTMF enthält und dies sowohl dem externen Anschluss als auch den IP-S400 zuweisen. Ich hoffe, daß dadurch die ISDN-Telefone nach extern nicht leiden.

Ich erwäge schon, bei den Kunden die IP-S400's auszubauen und stattdessen auf eigene Kosten CS410 einzubauen, sofern verkabelungstechnisch möglich. Problem hier: Das CS410 wird nicht mehr hergestellt :-(

Es ist ein Trauerspiel...wie schön war doch ISDN: Einstecken, adressieren, geht.

Danke alles für's weiter Mitforschen.
G.N.
 
Update:
Ich habe nun auf den betroffenen Anlagen ein Profil mit G.711a und DTMF erstellt und sowohl dem Anschluss als auch den betroffenen Telefonen zugewiesen.

Allerdings hat sich leider kein Erfolg gezeigt. Direkt nach Übernahme des Profils funktioniert's ein paar Mal, danach ist wieder Zapfenstreich.

Sofern hier niemand weitere Ideen hat, werde ich wohl vor der Außerbetriebnahme der IP-S400 nochmal einen Bintec Elmeg Servicefall aufmachen. Es ist zum Wahnsinnigwerden...
 
Es gibt seit letzte Woche ein neues Firmware Release für die be.IP plus. Tritt der Fehler damit auch auf?
 
Hallo,
....Da der VoIP-Verbindung nach außen ein Codec-Profil zugeordnet ist, sollte es keine Rolle spielen, von welcher Endgeräteart das Telefonat ausgeht. Bei einem IP-Endgerät ist zu beachten, dass da nicht nur das Codec-Profil zum VoIP-Anbieter greift, sondern auch das, was dem Endgerät selbst zugeordnet ist. ....

Das kann ich aufgrund meines Problems aber nicht bestätigen: https://www.ip-phone-forum.de/threa...it-be-ip-und-fritzbox-7330-unitymedia.298770/
Es scheint sehr wohl Unterschiede von der Endgeräteart zu geben, wenn man extern telefoniert. In meinem Fall ist das "IP-Telefon" die Fritzbox und trotz Endgeräte und Anbieter 711a Codec, kann das "IP-Telefon" einen Unitymedia Anschluß nicht erreichen, das S560 am ISDN Anschluss der be.ip kann es aber...
habe auch schon die 10.2.2 eingespielt ohne Besserung...

Vielleicht ist hier das Problem ähnlich gelagert. Evtl mal ein "OldSchool" ISDN Systemtelefon mal gebraucht ersteigern/kaufen und damit testen?
 
Hallo,
wie ich schon geschrieben hatte, gibt es in der Anlage bei IP-Telefonen zwei Stellen, wo ein Codec-Profil vorgegeben werden kann:
  1. Codec-Profil zum VoIP-Anbieter
  2. Codec-Profil beim Endgerät
Bei SIP-Telefonen kommt noch die eigene Einstellung hinzu.

Das Problem hier zeigt sich bei der Verwendung eines "Oldschool"-Endgerätes (ab, S0, Up0) nicht.
Die IP-S-Systemtelefone tanzen hier ein wenig aus der Reihe. Eigentlich sprechen die nämlich die gleiche Sprache, wie S0- und Up0-Telefone, allerdings über IP. Offensichtlich liegt aber genau hier die Schwierigkeit.
Bei SIP-Telefonen kommen die Töne nach dem Abheben des eigenen Hörers bis zum Gesprächsaufbau vom Endgerät, bei ab-/S0-/Up0-Geräten von der Telefonanlage.
Z.B. ist meinem Yealink T41P völlig wurst, ob automatische Amtsholung eingestellt ist oder nicht. Sobald ich den Hörer abhebe, höre ich den durchgehenden Freiton - wenn ich im Telefon dann auch noch die Standard-Einstellung belassen habe, kommt der im USA-Stil.
 
Hallo,
Bei SIP-Telefonen kommt noch die eigene Einstellung hinzu.
Bedeutet dieser Umstand, das bei meinem Problem ggf die Fritzbox sogar die Vorgaben der be.ip übersteuert / übersteuern kann? Denn an beiden Stellen in der be.ip hab ich das Codec Profil bereits auf 711a fest eingestellt (auch in der Fritzbox "HD deaktiviert").
Ob das IP-S400 auch "mit anderem Codec "übersteuert""?
Entschuldigung, das ich hier vom eigentlichen Thema ablenke, aber in meinem Ursprungsthread meines Problems finde ich wenig hilfreiches und dies hier schien mir etwas "ähnlich gelagert" zu sein...

Gruß
Achim
 
Hallo,
nach meinem Dafürhalten dürfte die be.IP hinsichtlich der Codec-Wahl nicht übersteuert werden. Ob sie das trotzdem mit sich machen lässt bzw. was genau zwischen den Beteiligten abgeht, würde der SIP-Trace hergeben.

Bei der IP-S400-Problematik geht es ja darum, dass am Endgerät bei manchen Anrufen kein Audio-Feedback zurückkommt, ob es nun auf der Gegenseite klingelt oder besetzt ist. Wenn dort abgehoben wird, kommt das Gespräch normal zustande. Daher halte ich das nach wie vor nicht für ein Codec-Problem.
 
Ich bin der gleichen Meinung wie SFA1492.

Der Codec kommt erst NACH erfolgreichem Rufaufbau wirklich zum Tragen. Die Gesprächspartner handeln den Codec aus, den Sie nach der Annahme des Gesprächs verwenden werden. Der Rufton kommt vorher und wird in aller Regel von der lokalen Telefonanlage oder vom Endgerät generiert werden.
 
Hallo G.Nagus,

ich kann genau über das gleiche Problem an einem unserer Standorte berichten. Das Problem an dem IP-S400 trat auch erst später auf und war dann plötzlich da. Bis heute konnte ich keinen Fehler finden und das auch nicht abstellen. Ich spiele nun mit dem Gedanken wieder ein altes CS410 einzusetzen.

Ein anderes IP Tel, vom Typ elmeg-IP620 am selben Standort hatte exakt das gleiche Problem. Das Problem ist zeitgleich mit dem Problem am IP-S400 aufgetreten, ist nun aber wieder verschwunden.
Ich vermute fast ein Problem innerhalb der Serie. Das betroffene IP-S400 hat die Seriennummer 1735051796. Bitte teile mir doch mal rein informativ die Seriennummer von Deinem Gerät mit, falls das möglich ist.

Vielleicht hast Du zwischenzeitlich auch eine Lösung gefunden?
 
Hallo,
bei SIP-Telefonen (wie z.B. dem IP620) werden Wählton & Co. vom Telefon generiert, bei klassischen Geräten (analog, ISDN) kommen die Töne von der Anlage.
Die IP-S-Telefone gehören in dem Fall aber in die klassiche Rubrik, obwohl sie ihre Daten via IP übermitteln (s. weiter oben)
Daher kann es zwar sein, dass beide Telefone ähnliche Symptome zeigen, aber aufgrund der gerade geschilderten Sachverhalte dürfte das eine andere Ursache haben.

Es ist beim IP-S400 ganz bestimmt ein Problem der Serie - aber der kompletten. Bei meinem IP-S290 habe ich das noch nicht festgestellt, wobei ich das auch äußerst selten benutze.
 
Hallo zusammen,

ein Update auf die allerneueste SW-Variante in der be.IP konnte ich noch nicht einspielen, jedoch zeigt die Revisionshistorie nach meiner Lesart nicht in Richtung einer Lösung für dieses Problem.
Die Anlagensoftware scheint bei mir keine Rolle zu spielen, da die betroffenen Systeme unterschiedliche Softwarestände haben, der Fehler aber identisch ist.

Ich fürchte, daß SFA1492 auf der richtigen Fährte ist - eher aber als Problem des Typs, nicht der Produktiosserie. Die S/N der betroffenen Geräte habe ich nicht zur Hand. Sie haben den gleichen SW-Stand (5.240, weil es leider keine neuen Versionen gibt). Die betroffenen Geräte stammen jedoch aus unterschiedlichen Produktionsjahren (eines ist aus 2015, das andere aus 2017).

Das Erstaunliche ist, daß der Fehler "unterwegs" aufgetreten ist - und nicht von vornherein bestand (und auch nicht mit einerm SW-Update in den betroffenen Anlagen / Telefonen o.ä. zusammenhing).
Und das wiederum spricht ein Stück weit gegen den Serienfehler.
Deshalb klang die Codec-Idee plausibel (weil es durchaus schien, daß etwas "von außen" mitverantwortlich ist). Doch der war's nicht (zumindest nicht der 711.a, den ich mit DTMF aktuell laufen habe).

@SteigerM: Hat stromlos machen und neu im Netz booten bei Deinen betroffenen Telefonen irgendeinen Effekt? Ich meine mich dunkel zu erinnern, daß eines der beiden betroffenen Geräte danach kurzzeitig (!) normal funktioniert hat. Konnte es bei meinen lange nicht probieren, ob die Erinnerung richtig ist.

Es macht mich wahnsinnig (und die armen Nutzer noch mehr).

Danke an alle, die noch irgendwelche Ideen haben (außer dem Rauswurf der Dinger ;) )
 
Die beste Idee dazu ist: Ticket beim Hersteller aufmachen.
 
Hallo Kalle,

das ist im Grundsatz schon richtig.
Der Haken daran ist, daß das Ticket beim Hersteller mehr kostet als die Anschaffung eines CS410 auf Ebay...und das ist den Betroffenen sehr schlecht zu vermitteln :(
Daher hoffte ich hier auf Eingebungen.
 
Hi!

Wenn die Fehler innerhalb der "Gewährleistung" aufgetreten sind, darf ein "Ticket" beim Hersteller, normal keine zusätzlichen Extrakosten verursachen!
 
Stimmt, doch die Gewährleistung ist bereits rum - auf jeden Fall bei einem Gerät, wahrscheinlich auch bei dem anderen. Ich hatte mit denen bereits innerhalb der Gewährleistung eines Gerätes Theater - deswegen bin ich etwas vorsichtig.
 
Nach dem Motto, wer nicht Rechtzeitig richtig reklamiert, hat hinterher leider meistens schlechte Karten.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,382
Beiträge
2,251,164
Mitglieder
374,040
Neuestes Mitglied
nady
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.