Aussetzer, snom 320, Fritz!Box

[ollibraun]

Hallo,

wir haben leider immer wieder tageweise deutlich verschlechterte Qualität. Besonders sekundenlange Aussetzer (da ist dann nichts zu hören, auch kein Rauschen).

3CX V8 auf PC mit IP 10.10.10.250,
SIP-Port 5062,
snom 320-Telefone 7.3.30,
FRITZ!Box Fon WLAN 7170 Firmware-Version 29.04.80
sipgate Trunking als Provider

Mir fallen zwei Dinge auf, die damit vielleicht zu tun haben:

1.

Die Priorisierung ergibt ein Bild im Fritz!Box-Online-Monitor, bei dem ich das Gefühl habe, dass nur ein Teil der Gesprächsdaten bevorzugt wird.



In der Fritz!Box sind als "Echtzeitanwendungen" definiert:
Netzwerkgerät - Netzwerkanwendung
Alle Geräte - 3CX
automatisch - Internettelefonie

Als "Netzwerkanwendung 3CX" ist definiert definiert:
UDP Quellport 5062 Zielport beliebig
UDP Quellport 9000-9049 Zielport beliebig

Wenn ich mir das Bild ansehe, habe ich aber den Eindruck, da wird nur ein Teil der Gesprächsdaten bevorzugt.

2.

Das Logfile sieht für mich so aus, als liefen die Gespräche vom Telefon über den Server und dann zum Provider. Ist das richtig, und wie kann ich es umstellen? "Telefonanlage überträgt Audio" bei den Telefonen ist nicht gewählt!

15:06:00.580|.CallLeg.cpp(123)|Log5||CallLeg:nNewCall:[CM500002]: Info on incoming INVITE:
INVITE sip:[email protected]:5060;rinstance=c662565d70ab4915 SIP/2.0
Via: SIP/2.0/UDP 217.10.68.150:5060;branch=z9hG4bKb7b5.0256cd17.0
Via: SIP/2.0/UDP 172.20.40.6;branch=z9hG4bKb7b5.0256cd17.0
Via: SIP/2.0/UDP 217.10.68.150:5060;received=217.10.68.178;branch=z9hG4bK5fb51668
Via: SIP/2.0/UDP 217.10.67.11:5060;received=217.10.67.11;branch=z9hG4bK5fb51668;rport=5060
Max-Forwards: 67
Record-Route:
Record-Route:
Record-Route:
Contact:
To:
From: "03069545132";tag=as00477d8d
Call-ID: [email protected]
CSeq: 103 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
X-LEGID: 0f8e67ce


15:06:00.580|.Line.cpp(281)|Log5||LineCfg::getInboundTarget:Looking for inbound target: called=00493088667911; caller=03069545132
15:06:00.580|.Line.cpp(325)|Log2||LineCfg::getInboundTarget:[CM503012]: Inbound out-of-office hours rule (CR) for 10000 forwards to DN:61
15:06:00.658|.CallCtrl.cpp(161)|Log2||CallCtrl:nIncomingCall:[CM503001]: Call(21): Incoming call from 03069545132@(Ln.10000@sip) to
15:06:00.673|.Line.cpp(1059)|Log2||Line:rintEndpointInfo:[CM505003]: Provider:[sip] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5062]
15:06:00.673|.CallLeg.cpp(951)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:21.1
15:06:00.673|.SLServer.cpp(794)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210000] C:21.1:Offer received. RTP connection: 217.10.77.21:40900(40901)
15:06:00.673|.CallCtrl.cpp(331)|Log3||CallCtrl:nSelectRouteReq:[CM503010]: Making route(s) to
15:06:00.673|.CallCtrl.cpp(446)|Log2||CallCtrl:nSelectRouteReq:[CM503004]: Call(21): Route 1: HuntGrp61:11Ext.11@[Dev:sip:[email protected]:2048;line=ev1i2qoj]
15:06:00.673|.CallCtrl.cpp(446)|Log2||CallCtrl:nSelectRouteReq:[CM503004]: Call(21): Route 2: HuntGrp61:12Ext.12@[Dev:sip:[email protected]:2048;line=b1r71ie6]
15:06:00.673|.CallCtrl.cpp(452)|Log2||CallCtrl:nSelectRouteReq:[CM503017]: Call(21): Target is not registered: HuntGrp61:13
15:06:00.705|.SLServer.cpp(794)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210002] C:21.2:Offer provided. Connection(transcoding mode): 10.10.10.250:7068(7069)
15:06:00.720|.Target.cpp(430)|Log2||Target::makeOneInvite:[CM503025]: Call(21): Calling HuntGrp61:11Ext.11@[Dev:sip:[email protected]:2048;line=ev1i2qoj]
15:06:00.908|.CallLeg.cpp(257)|Log3||CallLeg:nAnswer:[CM503002]: Call(21): Alerting sip:[email protected]:2048;line=ev1i2qoj
15:06:00.908|.Extension.cpp(1067)|Log3||Extension:rintEndpointInfo:[CM505001]: Ext.11: Device info: Device Identified: [Man: Snom;Mod: 3xx series;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom320/7.3.30] PBX contact: [sip:[email protected]:5062]
15:06:05.142|.CallLeg.cpp(951)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:21.2
15:06:05.142|.SLServer.cpp(794)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210001] C:21.2:Answer received. RTP connection[unsecure]: 10.10.10.111:58038(58039)
15:06:05.142|.SLServer.cpp(794)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210003] C:21.1:Answer provided. Connection(transcoding mode[unsecure]):87.234.220.92:9022(9023)
15:06:05.158|.CallCtrl.cpp(567)|Log2||CallCtrl:nLegConnected:[CM503007]: Call(21): Device joined: sip:[email protected]:5060
15:06:05.158|.CallCtrl.cpp(567)|Log2||CallCtrl:nLegConnected:[CM503007]: Call(21): Device joined: sip:[email protected]:2048;line=ev1i2qoj
15:06:05.345|.CallLeg.cpp(491)|Log5||CallLeg:nConfirmed:Session 10708 of leg C:21.1 is confirmed

 

[matictec]

Hallo,

die Fritzbox erkennt im Normalfall selbstständig VoIP (SIP, RTP) und priorisiert diese. Weitere Regeln sind eigentlich nicht notwendig. Bei einem externen Gespräch über einen Provider geht das Gespräch in der Regel über den Provider, da Re-Invite hier meistens nicht unterstützt wird.

Die Aussetzer entstehen somit vermutlich auf dem Server beim Transcoding selbst oder durch unsaubere Leitungen. Einfach mal den Server monitoren auf CPU-Last und Netzwerktraffic. Auch mal ein Wireshark-Capture durchführen und den RTP-Datenstrom prüfen, ob Aussetzer zu erkennen sind.

 

[ollibraun]

Hallo matictec,

@matictec wrote:die Fritzbox erkennt im Normalfall selbstständig VoIP (SIP, RTP) und priorisiert diese. Weitere Regeln sind eigentlich nicht notwendig. Bei einem externen Gespräch über einen Provider geht das Gespräch in der Regel über den Provider, da Re-Invite hier meistens nicht unterstützt wird.

Im Logfile finde ich die Zeile:

"CSeq: 103 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY"

Bedeutet dies, dass sipgate Trunk kein Re-Invite unterstützt? Kann ich es daran zuverlässig sehen? Oder muss ich es anders testen bzw. den Provider direkt fragen?

Die Aussetzer entstehen somit vermutlich auf dem Server beim Transcoding selbst oder durch unsaubere Leitungen. Einfach mal den Server monitoren auf CPU-Last und Netzwerktraffic. Auch mal ein Wireshark-Capture durchführen und den RTP-Datenstrom prüfen, ob Aussetzer zu erkennen sind.

Ich habe ein gewisses Monitoring gestartet, mal sehen. Ich vermute ein Netzwerkproblem im LAN... die CPU-Last auf dem PC liegt bis jetzt unter 10 Prozent.

Grundsatzfrage: Wir haben hier eine Fritz!Box mit aktiviertem QoS für VoIP.

Allerdings ist dort direkt ein einfacher 8-Port-Switch angeschlossen, und in den Büroräumen liegen auch zwei weitere Switches.

Mache ich mir damit das QoS kaputt?

Es gibt auch einfache Switches, die ausdrücklich QoS anbieten (zB Cisco SD 100D-08). Was bringen solche Teile, wo ist der Vorteil gegenüber einem Switch ohne QoS?

 

[matictec]

Mein letzter Stand mit sipgate war, dass sie Re-Invite nicht unterstützen.

Die Fritzbox handhabt das QoS für VoIP soweit ich weiß nur am Internetport. sie sorgt als nur dafür, dass VoIP immer genügend Bandbreit bereitsteht. Im eigenen Netzwerk muss QoS an den Switchen unterstützt werden. Hierfür kommen dann Business Geräte zum Beispiel von Linksys oder Lancom in Frage. Cisco geht natürlich auch.

 

[ollibraun]

@matictec wrote:Mein letzter Stand mit sipgate war, dass sie Re-Invite nicht unterstützen.

Schade.

Die Fritzbox handhabt das QoS für VoIP soweit ich weiß nur am Internetport. sie sorgt als nur dafür, dass VoIP immer genügend Bandbreit bereitsteht. Im eigenen Netzwerk muss QoS an den Switchen unterstützt werden. Hierfür kommen dann Business Geräte zum Beispiel von Linksys oder Lancom in Frage. Cisco geht natürlich auch.

Woran kann man denn erkennen, dass QoS im LAN aktiv ist bzw. genutzt wird?

Die Fritz!Box selber hat ja auch einen eingebauten Switch. Und die Snoms haben faktisch 3 Port-Switches eingebaut.

Da wüsste ich gerne, ob es mit QoS wirklich funktioniert...

 

[matictec]

Ob die Fritzbox das an den internen Netzwerkports beherrscht weiß ich leider nicht. Jedoch muss auch jeder Switch das unterstützen. Um zu testen, ob es wirklich am Netzwerk liegt, einmal die 3CX in einem separaten Netzwerk betreiben. Nur ein Switch mit 3-5 Telefonen und erstmal intern teste. Eventuell auch einen anderen Server mal testen.

 

[ollibraun]

@matictec wrote:Ob die Fritzbox das an den internen Netzwerkports beherrscht weiß ich leider nicht. Jedoch muss auch jeder Switch das unterstützen. Um zu testen, ob es wirklich am Netzwerk liegt, einmal die 3CX in einem separaten Netzwerk betreiben. Nur ein Switch mit 3-5 Telefonen und erstmal intern teste. Eventuell auch einen anderen Server mal testen.

Ich tendiere dazu, die Switches auszutauschen. Cisco SMB mit QoS oder so.

Problem ist, dass es überhaupt nur vier Telefone gibt, und die Probleme treten nur tage- oder stundenweise auf. Das ist das Problem mit dem Testen: Die Fehler lassen sich so schlecht reproduzieren.

Ich poste in den nächsten Tagen mal, was ich mit dem PRTG Network Monitor von Paessler.com beobachte. Da gibt es Möglichkeiten zur gezielten QoS-Messung.

Nur suche ich noch eine Möglichkeit, eindeutig festzustellen, ob QoS innerhalb eines LANs von allen relevanten Geräten unterstützt wird.

 

[matictec]

Wenn Probleme nur sporadisch auftreten, ist eine Analyse immer schwierig. Ein Monitoring des Traffics ist hier eine gute Idee. Für das QoS müssen nicht alle Geräte dieses unterstützen. Wichtig ist vor allem, dass alle Switche es unterstützen. Alle Pakete die nicht entsprechend gekennzeichnet werden, werden normal priorisiert.

 

[anonymous]

@ollibraun wrote:Hallo,

wir haben leider immer wieder tageweise deutlich verschlechterte Qualität. Besonders sekundenlange Aussetzer (da ist dann nichts zu hören, auch kein Rauschen).


Haben wir auch..

SNOM+sipgate+3com switch+Watchguard Router

 

[matictec]

Auch hier mal mit dem Wireshark ein Capture aufnehmen damit man das analysieren kann.

 

[anonymous]

Ich kenn mich mit dem Progr. nicht aus. Was soll denn da gecaptured werden? Reicht es wenn der folgende Filter gesetzt wird?

"ip.dst == 192.168.20.21" <- IP vom SNOM Telefon

Und soll ich dann den ganzen "Mittschnitt" hier reinstellen?

 

[matictec]

Am besten kein Filter setzen. Captures nicht hier veröffentlichen. Entweder als PM, sofern möglich, oder sonst auch gerne über unser Support Center support.matic-tec.de. Bei Gelegenheit würde ich mir das mal anschauen.