15
Asterisk Latenz Probleme -- HILFE!!
Wir haben hier ein Problem mit einem Asterisk Server von einem Kunden. Ich habe das eidige Thema bekommen, finde aber keine Lösung.
Wenn ich ein Telefon sowohl Intern als auch nach extern führe bekomme ich zwischen der 28sec und der 32 sec einen Gesprächsabbruch (ich versteh den Teilnehmer nicht mehr) danach geht es norml weiter. Bei 1 min das gleiche Spiel wieder. Die Intervalle die danach kommen sind nicht immer davon betroffen. Was mich wundert ist das es IMMER zur selben Zeit ist bei dem Telefonat.
Ich hoffe mir kann jemand helfen.
Der Asterisk läuft als VM in einem Debian.
Wenn ich ein Telefon sowohl Intern als auch nach extern führe bekomme ich zwischen der 28sec und der 32 sec einen Gesprächsabbruch (ich versteh den Teilnehmer nicht mehr) danach geht es norml weiter. Bei 1 min das gleiche Spiel wieder. Die Intervalle die danach kommen sind nicht immer davon betroffen. Was mich wundert ist das es IMMER zur selben Zeit ist bei dem Telefonat.
Ich hoffe mir kann jemand helfen.
Der Asterisk läuft als VM in einem Debian.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 238291
Url: https://administrator.de/contentid/238291
Printed on: April 24, 2024 at 20:04 o'clock
15 Comments
Latest comment
(auch ohne Gruß)
Ok,
Syslog von Debian und Asterisk gecheckt?
Syslogs der Switches gecheckt?
Ggfs. Cronjobs auf Host und Gast vorhanden?
Host und Gast mit aktuellen Patches versorgt?
CPU/RAM Auslastung Host und GAst i.O?
VLAN Config i.O.?
QoS Einstellungen an allen beteiligten Switches i.O.?
Problem mit einem Asterisk Server von einem Kunden
Manchmal frag ich miuch schon was da für Dienstleister unterwegs sind, die bei einem Problem ein Internetforum befragen müssen...Ok,
Syslog von Debian und Asterisk gecheckt?
Syslogs der Switches gecheckt?
Ggfs. Cronjobs auf Host und Gast vorhanden?
Host und Gast mit aktuellen Patches versorgt?
CPU/RAM Auslastung Host und GAst i.O?
VLAN Config i.O.?
QoS Einstellungen an allen beteiligten Switches i.O.?
1
Hallo,
das Problem taucht bei das erstemal auf, wir hatten vorher nie Problem.
das Problem taucht bei das erstemal auf, wir hatten vorher nie Problem.
Syslog ist ok. Im Asterisk bekomme ich genau zu der Zeit folgende Fehler:
[2014-05-16 09:30:10] DEBUG[3834]: rtp.c:2796 ast_rtp_raw_write: Difference is 16008, ms is 2021
[2014-05-16 09:30:10] DEBUG[3834]: rtp.c:941 ast_rtcp_read: Got RTCP report of 76 bytes
[2014-05-16 09:30:12] DEBUG[2566]: chan_sip.c:2229 __sip_autodestruct: Auto destroying SIP dialog '3c26702fd785-23pv47w4ku60'
[2014-05-16 09:30:12] DEBUG[2566]: chan_sip.c:3662 sip_destroy: Destroying SIP dialog 3c26702fd785-23pv47w4ku60
Really destroying SIP dialog '3c26702fd785-23pv47w4ku60' Method: REGISTER
Cronjobs sind vorhanden, diese Prügen das System alle 5 min oder alle 24 Stunden.
QoS ist aktiviert, CPU und RAM sind bei unter 10%
[2014-05-16 09:30:10] DEBUG[3834]: rtp.c:2796 ast_rtp_raw_write: Difference is 16008, ms is 2021
[2014-05-16 09:30:10] DEBUG[3834]: rtp.c:941 ast_rtcp_read: Got RTCP report of 76 bytes
[2014-05-16 09:30:12] DEBUG[2566]: chan_sip.c:2229 __sip_autodestruct: Auto destroying SIP dialog '3c26702fd785-23pv47w4ku60'
[2014-05-16 09:30:12] DEBUG[2566]: chan_sip.c:3662 sip_destroy: Destroying SIP dialog 3c26702fd785-23pv47w4ku60
Really destroying SIP dialog '3c26702fd785-23pv47w4ku60' Method: REGISTER
Cronjobs sind vorhanden, diese Prügen das System alle 5 min oder alle 24 Stunden.
QoS ist aktiviert, CPU und RAM sind bei unter 10%
Asterisk selber hat damit auch gar nichts zu tun. Es stellt lediglich die Verbindung zwischen den Telefonie Teilnehmern per SIP her.
Die eigentliche Voice Übertragung geschieht immer direkt per RTP zwischen den Telefonen ohne das Asterisk dazwischen ist.
Folglich kann dieses Problem also nur ein problem der Endgeräte sein und weniger von Asterisk selber....
Deshalb stellt sich die Frage ob QoS wirklich aktiviert ist ? Dann die viel wichtigere Frage WIE QoS aktiviert ist ??
Ist es Layer 2 QoS mit 802.1p oder Layer 3 QoS mit DiffServ DSCP ??
Das muss auf allen Switches im LAN konfiguriert sein an die Voice Komponenten angeschlossen sind.
Dann die Frage WIE ist es dort implementiert. Manche billigen Layer 2 LAN Switches können gar kein L3 QoS. Usw usw. Ist der Voice Traffic in einem separaten VLAN isoliert wie es eigentlich sein sollte ??
Dazu leider keinerlei Aussagen vom TO
Die eigentliche Voice Übertragung geschieht immer direkt per RTP zwischen den Telefonen ohne das Asterisk dazwischen ist.
Folglich kann dieses Problem also nur ein problem der Endgeräte sein und weniger von Asterisk selber....
Deshalb stellt sich die Frage ob QoS wirklich aktiviert ist ? Dann die viel wichtigere Frage WIE QoS aktiviert ist ??
Ist es Layer 2 QoS mit 802.1p oder Layer 3 QoS mit DiffServ DSCP ??
Das muss auf allen Switches im LAN konfiguriert sein an die Voice Komponenten angeschlossen sind.
Dann die Frage WIE ist es dort implementiert. Manche billigen Layer 2 LAN Switches können gar kein L3 QoS. Usw usw. Ist der Voice Traffic in einem separaten VLAN isoliert wie es eigentlich sein sollte ??
Dazu leider keinerlei Aussagen vom TO
Hi,
also die Switche sind richtig eingestellt(ist gerade Kontrolliert wurden) Das VLAN ist extra nur für diese Kommunikation zuständig. Es hängen 30 Clients in diesem VLAN. Ich glaube das die Pakete beim Asterisk erst garnicht raus gehen aber ich wüsste nicht wo oder wie ich da suchen sollte. Wenn ich ein Telefonat mit einem client mache dann bekomme ich in Wireshark auch den Abbruch angezeigt. Ausgewertet habe ich das iax2 Protokoll. Wenn der Ton fehlt dann kommt ein ping und als Antwort ein Pog. Danach geht es mit einem ACK weiter undab dem Moment höhre ich den gegenüber auch Ohne Probleme wieder
also die Switche sind richtig eingestellt(ist gerade Kontrolliert wurden) Das VLAN ist extra nur für diese Kommunikation zuständig. Es hängen 30 Clients in diesem VLAN. Ich glaube das die Pakete beim Asterisk erst garnicht raus gehen aber ich wüsste nicht wo oder wie ich da suchen sollte. Wenn ich ein Telefonat mit einem client mache dann bekomme ich in Wireshark auch den Abbruch angezeigt. Ausgewertet habe ich das iax2 Protokoll. Wenn der Ton fehlt dann kommt ein ping und als Antwort ein Pog. Danach geht es mit einem ACK weiter undab dem Moment höhre ich den gegenüber auch Ohne Probleme wieder
Zitat von @aqui:
Asterisk selber hat damit auch gar nichts zu tun. Es stellt lediglich die Verbindung zwischen den Telefonie Teilnehmern per SIP
her. Die eigentliche Voice Übertragung geschieht immer direkt per RTP zwischen den Telefonen ohne das Asterisk dazwischen
ist.
Das ist so nicht ganz richtig! Asterisk kann durchaus Media-Proxy sein, was bei Übergang von LAN über NAT ins Internet zwingend notwendig ist.Asterisk selber hat damit auch gar nichts zu tun. Es stellt lediglich die Verbindung zwischen den Telefonie Teilnehmern per SIP
her. Die eigentliche Voice Übertragung geschieht immer direkt per RTP zwischen den Telefonen ohne das Asterisk dazwischen
ist.
Dieses Problem klingt nach einer falsch erkannten Packetization, also der Frequenz in der RTP-Pakete geschickt werden.
Wenn sich diese Packetization am Endgerät einstellen lässt, solltest du dies mal fest auf 20ms stellen und der Asterisk für diesen Peer hinterlegen, dass dort ebenfalls ausschließlich 20ms genutzt werden.
In der sip.conf geht das, indem hinter den erlaubten Codec mit Doppelpunkt getrennt einfach eine "20" geschrieben wird - z.B.
disallow=all
allow=g722:20
allow=alaw:20Alternativ kann ein vollkommen abwegig konfigurierter Jitterbuffer Schuld sein. Im LAN kann man auf den JB meiner Erfahrung nach getrost verzichten, sofern
die Telefone nicht noch andere LAN-Daten von irgendwelchen Workstations mit durchleiten.
EDIT: Gerade erst den untersten Beitrag gesehen:
Wie wird die Asterisk denn virtualisiert? Diese benötigt zwingend ein zuverlässiges Timing-Device - entweder ein Pseudo-Timing über die CPU oder über eine
aktive ISDN-Karte.
Je nach Virtualisierungstechnik funktioniert das CPU-Timing mal besser und mal schlechter, insbesondere wenn irgend ein Dienst auf dem Virtualisierungs-Host
noch an der Uhrzeit herumspielt (NTP z.B.).
Wenn du Asterisk schon virtualisierst (das sollte man eigentlich NIE tun), dann ausschließlich so, dass die Asterisk wengistens einen exklusiven CPU-Kern bekommt.
Ansonsten kann man - wenn man auf Codec-Umwandlung verzichtet - 30 Clients auch Problemlos auf einem kleinen Intel Atom betreiben.
Hallo wer immer Du bist,
Mach doch bitte mal eine Skizze.
Zeichne ein:
Anzahl der Switche + Typ und Hersteller
Verbindung der Switche untereinander, Länge, Geschwindigkeit, LWL oder Kupfer,
Wo ist der Asterisk Server angeschlossen
Was hängt alles am Asterisk Server
Ist der Serve physikalisch oder virtuell ?
Was ist die Virtualisierungsplattform ?
Wieviele vCPUs und Speicher ist dem Telefonvogel zugeordnet ?
Wo ist das Phone angeschlossen, das Probleme macht ?
Gibt es Probleme mit internen, externen oder beiden Verbidungnen ?
Wie sind die Uplinks der Switche untereinander ausgelastet, falls vorhaden ?
Seit wann tritt das Problem auf ?
Was wurde seither geändert ?
Gruß
Anton
Mach doch bitte mal eine Skizze.
Zeichne ein:
Anzahl der Switche + Typ und Hersteller
Verbindung der Switche untereinander, Länge, Geschwindigkeit, LWL oder Kupfer,
Wo ist der Asterisk Server angeschlossen
Was hängt alles am Asterisk Server
Ist der Serve physikalisch oder virtuell ?
Was ist die Virtualisierungsplattform ?
Wieviele vCPUs und Speicher ist dem Telefonvogel zugeordnet ?
Wo ist das Phone angeschlossen, das Probleme macht ?
Gibt es Probleme mit internen, externen oder beiden Verbidungnen ?
Wie sind die Uplinks der Switche untereinander ausgelastet, falls vorhaden ?
Seit wann tritt das Problem auf ?
Was wurde seither geändert ?
Gruß
Anton
Hallo Danke für eure Antworten, wir sind dem Problem einen großen Schritt näher gekommen. Wie LordGurke schon festgestellt hat geht auch unsere gesamte Kommunikation über den Asterisk Server. wir haben am Samstag auf dem Asterisk Server mal einen Dumpgemacht und festgestelt das in dieser besagten Zeit 28-32sec der Asterisk Server eine Skew time von -1528 hat. in den ms davor sieht man dann auch wie die Werde schlechter werden bis dann dieser Wert erreicht ist. Danach geht der Wert wieder zurück und das Telefonat kann weitergeführt werden. Damit ist uns schonmal klar dass das Problem am Asterisk liegt.
Da dieser Asterisk aber genau so Installiert wurde wie alle anderen stehen wir ziemlich ratlos da wo wir das Problem suchen könnten.
Da dieser Asterisk aber genau so Installiert wurde wie alle anderen stehen wir ziemlich ratlos da wo wir das Problem suchen könnten.
Der Asterisk ist mit VMware Virtualisiert und hat 8GB RAM 2 eigenen Cores und 4 Socket pro Core. NTP Stimmt
Hallo, es scheint mit den oben beschriebenen Werten geklappt zu haben. Nach dem ich den Wert von allow=ullaw in der sip.conf und in der iax.conf so gesetzt habe war alles einwandfrei. Was ich mich jetzt frage. Muss ich diesen Wert in beiden Dateien setzen oder wirkt das ganze Global und reicht wenn ich es in einer Datei angebe?
ulaw ist in Deutschland tendenziell eher nicht zu verwenden, da es ein hauptsächlich in den USA verwendeter Codec ist.
In europäischen Netzen ist aLaw gebräuchlich, was besser klingt, nicht konvertiert werden muss und keine Tonhöhenverschiebung provoziert
Wenn du es nur in der iax.conf setzt, gilt das auch nur für IAX-Verbindungen, aber nicht z.B. für SIP-Telefone. Der Vollständigkeit halber würde ich es in beiden Dateien setzen.
In europäischen Netzen ist aLaw gebräuchlich, was besser klingt, nicht konvertiert werden muss und keine Tonhöhenverschiebung provoziert
Wenn du es nur in der iax.conf setzt, gilt das auch nur für IAX-Verbindungen, aber nicht z.B. für SIP-Telefone. Der Vollständigkeit halber würde ich es in beiden Dateien setzen.
Danke für die Antwort, leider mussten wir feststellen das die Probleme immer noch bestehen. Ich hatte gestern 10 Test gemacht inkl. Dumps und hatte keine Probleme mehr und seid gestern im Späten nachmittag das selbe Problem wieder. die Skew time ist dort dann an einem Packet sehr hoch und geht in den darauf folgenden Paketen wieder runter. Was mir in den Dumps auffält ist das er alle Pakete die er nicht sendet nachher hinterher schiebt. Sie gehen also nicht verloren nur die gegenseite Antwortet einfache eine ganze Zeit nicht (1-2sec)
Welche Seite schickt denn keine Pakete mehr - die Asterisk?
Passiert das an allen Telefonen oder nur einem bestimmten?
Wenn die Asterisk nichts mehr sendet könnte es an springenden Uhrzeiten oder ggf. auch hängenden Netzwerktreibern für die virtuelle Netzwerkkarte liegen...
Passiert das an allen Telefonen oder nur einem bestimmten?
Wenn die Asterisk nichts mehr sendet könnte es an springenden Uhrzeiten oder ggf. auch hängenden Netzwerktreibern für die virtuelle Netzwerkkarte liegen...
Also die Kommunikation findet zwischen einem Patton GW und einem Asterisk statt. Der Patton Sendet Ordnungsgemäß und der Asterisk hört einfach in diesen besagten sekunden auf zu senden. Er schiebt die Pakete aber nachher hinterher wenn er wieder antwort. Wenn man sich den Dump anschaut könnte man denken er wäre gerade mit was anderem Beschäftigt oder durch irgend was gestört.
Die Uhrzeiten haben wir Kontrolliert die sind einwandfrei. Die Virtuelle Netzwerkkarte könnte es zwar sein, ich wüßte jedoch jetzt gerade nicht wie ich das Kontrollieren könnte. Die anderen Systeme laufen auf der selben Physikalischen Maschine daher glaub ich da nicht so richtig dran
Die Uhrzeiten haben wir Kontrolliert die sind einwandfrei. Die Virtuelle Netzwerkkarte könnte es zwar sein, ich wüßte jedoch jetzt gerade nicht wie ich das Kontrollieren könnte. Die anderen Systeme laufen auf der selben Physikalischen Maschine daher glaub ich da nicht so richtig dran
Ich habe hier mal einen debug von rtcp gemacht vieleicht kannst du damit was anfangen, ich glaube das die Zeit das Problem ist
Got RTCP from IP:4893
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 3091837440
NTP timestamp: 3609752152.0000000000
RTP timestamp: 3618641247
SPC: 1492 SOC: 238720
Internal RTCP NTP clock skew detected: lsr=1918164309, now=1918481392, dlsr=317194 (4:839ms), diff=111
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 51373
Sequence number cycles: 0
Interarrival jitter: 0
Last SR(our NTP): 29268.514903310969339904
DLSR: 4.8400 (sec)
RTT: 65535998(sec)
Got RTCP from IP:4893
PT: 202(Unknown)
Reception reports: 1
SSRC of sender: 3091837440
Received an SDES from 1 IP:4893
Sent(NTP): 1400763353.3541348352
Sent(RTP): 3618642520
Sent packets: 1501
Sent octets: 240160
Report block:
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0001
Their last SR: 1918369792
DLSR: 0.1610 (sec)
Got RTCP from
Sent(RTP): 3618642520 IP:4893
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 3091837440
NTP timestamp: 3609752157.0000000000
RTP timestamp: 3618681247
SPC: 1742 SOC: 278720
Internal RTCP NTP clock skew detected: lsr=1918491989, now=1918809091, dlsr=317194 (4:839ms), diff=92
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 51623
Sequence number cycles: 0
Interarrival jitter: 1
Last SR(our NTP): 29273.514991271899561984
DLSR: 4.8400 (sec)
RTT: 65535998(sec)
Got RTCP from IP:4893
PT: 202(Unknown)
Reception reports: 1
SSRC of sender: 3091837440
Received an SDES from IP:4893
Sent(NTP): 1400763358.3541282816
Sent(RTP): 3618682520
Sent packets: 1751
Sent octets: 280160
Report block:
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0001
Their last SR: 1918697472
DLSR: 0.1610 (sec)
Got RTCP from IP:4893
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 3091837440
NTP timestamp: 3609752152.0000000000
RTP timestamp: 3618641247
SPC: 1492 SOC: 238720
Internal RTCP NTP clock skew detected: lsr=1918164309, now=1918481392, dlsr=317194 (4:839ms), diff=111
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 51373
Sequence number cycles: 0
Interarrival jitter: 0
Last SR(our NTP): 29268.514903310969339904
DLSR: 4.8400 (sec)
RTT: 65535998(sec)
Got RTCP from IP:4893
PT: 202(Unknown)
Reception reports: 1
SSRC of sender: 3091837440
Received an SDES from 1 IP:4893
- Sent RTCP SR to IP:4893
Sent(NTP): 1400763353.3541348352
Sent(RTP): 3618642520
Sent packets: 1501
Sent octets: 240160
Report block:
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0001
Their last SR: 1918369792
DLSR: 0.1610 (sec)
Got RTCP from
Sent(RTP): 3618642520 IP:4893
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 3091837440
NTP timestamp: 3609752157.0000000000
RTP timestamp: 3618681247
SPC: 1742 SOC: 278720
Internal RTCP NTP clock skew detected: lsr=1918491989, now=1918809091, dlsr=317194 (4:839ms), diff=92
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 51623
Sequence number cycles: 0
Interarrival jitter: 1
Last SR(our NTP): 29273.514991271899561984
DLSR: 4.8400 (sec)
RTT: 65535998(sec)
Got RTCP from IP:4893
PT: 202(Unknown)
Reception reports: 1
SSRC of sender: 3091837440
Received an SDES from IP:4893
- Sent RTCP SR to IP:4893
Sent(NTP): 1400763358.3541282816
Sent(RTP): 3618682520
Sent packets: 1751
Sent octets: 280160
Report block:
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0001
Their last SR: 1918697472
DLSR: 0.1610 (sec)
