Onderwerp: Elastix : geluidsbestanden worden te snel afgespeeld

Beste,

Omdat er mij werd gevraagd een IVR systeem op te zetten, heb ik een computergesproken tekst opgenomen. Deze tekst (in mp3) klinkt prima op mijn laptop. Na omzetting naar WAV (PCM Encoded, 16 Bits, at 8000Hz) klinkt het nog steeds prima. Ik upload deze WAV file naar de server, en beluister dit (via System Recordings) : prima. Als ik dit koppel aan een telefoonnummer en dit telefoonnummer bel : vééél te snel afgespeeld. Vraag is...wat kan de oorzaak zijn?

Het originele bestand zoals geupload naar de server : https://www.dropbox.com/s/ctmp16xyct6vxsz/KrisTest2.wav
Hetzelfde bestand zoals Elastix het afspeelt : bel 09 394 94 03 (voor NL : +32 9 394 94 03 -- Opgelet : Belgisch vast nummer, dus internationaal gesprek)

Alle hulp hierover is zeker welkom!

Geen idee of dit de oorzaak is...

Rond 20u merkte ik dat de datum/tijd van de server verkeerd was. Dus even "ntpdate ntp.telenet.be" ingetypt en daar was de juiste datum. Super...
Nu, 5 minuten geleden, merkte ik op dat de datum weer fout stond (om 23u was het 2u30 s nachts)!


[root@voip ~]# ntpdate ntp.telenet.be
5 Sep 23:01:46 ntpdate[6360]: step time server 195.130.132.18 offset -12839.874771 sec

[root@voip ~]# ntpdate ntp.telenet.be
5 Sep 23:05:46 ntpdate[6822]: step time server 195.130.132.18 offset -248.141270 sec

[root@voip ~]# ntpdate ntp.telenet.be
5 Sep 23:07:09 ntpdate[6983]: step time server 195.130.132.18 offset -90.584976 sec

[root@voip ~]# ntpdate ntp.telenet.be
5 Sep 23:07:23 ntpdate[7005]: step time server 195.130.132.18 offset -15.453637 sec

[root@voip ~]# ntpdate ntp.telenet.be
5 Sep 23:07:55 ntpdate[7057]: step time server 195.130.132.18 offset -33.596415 sec


De VOIP server is overigens een VM op een Xen server, mocht dit belangrijk zijn...

Van bepaalde virtualisatie software is bekend dat (mede afhankelijk van de versie) de tijd niet super stabiel is (zoals gewenst met telefonie). Zoeken op "clock skew" en vergelijkbare termen kan hier meer informatie over geven.

Dag Mark17,

Ik vermoed dat het probleem inderdaad daar aan ligt. Echter heb ik al gekeken naar diverse oplossingen maar tot op heden geen gevonden.

Oorspronkelijk geplaatst door IT-worX

Dag Mark17,

Ik vermoed dat het probleem inderdaad daar aan ligt. Echter heb ik al gekeken naar diverse oplossingen maar tot op heden geen gevonden.

Deze ziet er relevant uit :
http://manurevah.com/blah/en/blog/Xe...lies..Too-Fast

Dag Visser,

Blij dat je mij hier ook ter hulp schiet!

Dit lijkt inderdaad relevant, maar brengt geen soelaas :s

[root@voip clocksource0]# cat current_clocksource
jiffies
[root@voip clocksource0]# echo "xen" > current_clocksource
[root@voip clocksource0]# cat current_clocksource
jiffies

"jiffies" wilt hij dus niet vervangen door "xen"

Oorspronkelijk geplaatst door IT-worX

Dag Visser,

Blij dat je mij hier ook ter hulp schiet!

Dit lijkt inderdaad relevant, maar brengt geen soelaas :s

[root@voip clocksource0]# cat current_clocksource
jiffies
[root@voip clocksource0]# echo "xen" > current_clocksource
[root@voip clocksource0]# cat current_clocksource
jiffies

"jiffies" wilt hij dus niet vervangen door "xen"

Tsja, dan zul je echt moeten gaan nadenken :-)
Het lijkt me wel dat je in deze richting het probleem (en oplossing) moet zoeken. Nu is tijd/timing and virtualisatie een ietwat beruchte combinatie, en twee virtualisatie lagen boven elkaar lijkt me al helemaal een risico recept.
Waarom is dat eigenlijk, dat je binnen Xen een VM draait ?

Ik zou het eerst simpeler maken door te kijken of je met (hooguit) één laag (elastix op xen, of elastix op een VM) toe kunt.

Ik vermoed eveneens dat de oplossing daar ligt.

Hoe bedoel je, twee virtualisatielagen boven elkaar? Het is gewoon Elastix die op xen draait op dit moment als VM.
Reden waarom ik een VM draai : iets makkelijker naar backup toe, maar eveneens : nu is er ruimte om naast de centrale nog iets anders te draaien. Een dedicated machine enkel en alleen voor voip is beetje overkill, nietwaar? :-)

Oorspronkelijk geplaatst door IT-worX

Ik vermoed eveneens dat de oplossing daar ligt.

Hoe bedoel je, twee virtualisatielagen boven elkaar? Het is gewoon Elastix die op xen draait op dit moment als VM.
Reden waarom ik een VM draai : iets makkelijker naar backup toe, maar eveneens : nu is er ruimte om naast de centrale nog iets anders te draaien. Een dedicated machine enkel en alleen voor voip is beetje overkill, nietwaar? :-)

Ah, ik las 'vm op een xen server' als 'xen -> vmware/virtualbox/parallels -> elastix ' .

Maar het is dus

bare metal -> xen hypervisor -> xen vm0 -> elastix
?

Wat voor type xen virtualisatie gebruik je ?

Heb je hier iets aan ?
https://www.hostvirtual.com/kb/161/M...or-drifts.html

Lees ook http://asteriskfaqs.org/tag/timing-source over welke timing source asterisks gebruikt.

Dag Visser,

Mijn excuses voor de verwarring, ik draai inderdaad Xen op een bare metal bak, en één van de VM's daar is Elastix.
Ik gebruik overigens Xen PV.
De link die je hier aanbrengt heb ik ook gevonden, maar deze bracht eveneens geen soelaas

Ik weet niet of het helpt

Misschien kan het aan de voip comressie liggen?
kloppen de standaarden?

Mbt de tijd op de server de meste vm' s nemen de tijd over van de host tenzij anders ingesteld
wat geeft de systeemklok van de host aan?

Hebben de andere vm's geen tijd afwijking?