wir haben das Problem, dass bei manchen Telefonkonferenzen (nicht über die MobyDick gemanaged) die Verbindung einfach nach einer gewissen Zeit unterbrochen wird.
Zuerst dachte ich, das läge am Konferenzsystems unseres Kunden, jedoch habe ich dieses Phänomen nun schon häufiger bei verschiedenen Konferenzen und unterschiedlichen Konferenzsystemen (Lync, Webex, Telekom, u.a.) beobachten können. Es scheint gehäuft dann aufzutreten, wenn das Telefon auf “mute” geschaltet wurde und wir nur zuhören. Die Zeit, nachdem das Problem auftritt schwankt zwischen 5 und 12 min. Manchmal passiert es garnicht.
Ich habe natürlich schon etwas im Internet recherchiert und z.B. den Parameter “rtpholdtimeout” als mögliche ursache gefunden. Dieser ist jedoch standardmässig in der MobyDick auf 600 Sek gestellt… das passt nciht zu den 5 min-Unterbrechungen.
Als Anlage nutzen wir die MobyDick in Version 7.09.03, Unsere Telefone sind Snom870 und unser SIP-Provider ist Sipgate mit einem Trunking-Anschluss.
;--------------------------- RTP timers ----------------------------------------------------
; These timers are currently used for both audio and video streams. The RTP timeouts
; are only applied to the audio channel.
; The settings are settable in the global section as well as per device
;
;rtptimeout=60 ; Terminate call if 60 seconds of no RTP or RTCP activity
; on the audio channel
; when we’re not on hold. This is to be able to hangup
; a call in the case of a phone disappearing from the net,
; like a powerloss or grandma tripping over a cable.
;rtpholdtimeout=300 ; Terminate call if 300 seconds of no RTP or RTCP activity
; on the audio channel
; when we’re on hold (must be > rtptimeout)
;rtpkeepalive=<secs> ; Send keepalives in the RTP stream to keep NAT open
; (default is off - zero)
relevant.
Kannst du in der CLI nachvollziehen, was zu diesem Zeitpunkt passiert?
das wäre mein Verdacht, snom hatte mal Probleme mit dem hook switch. Da haben die Geräte mal sporadisch selbst aufgelegt. Kann dir leider jetzt aus dem Stegreif nicht mehr sagen, welche Serie das betroffen hat. Ich muss da nochmal selbst recherchieren.
ob dein snom das Problem mit dem “hook switch” hat, könntest du so verifizieren, indem du den Loglevel vom snom auf 9 setzt und wenn es wieder auftritt im Log überprüfst ob hier ein entsprechender Eintrag vorhanden ist. Sollte dem Eintrag entsprechen, wenn du absichtlich auflegst.