Ver­bin­dung tes­ten

Dein IP-Pho­ne, dei­ne Web App oder dei­ne Desk­top App funk­tio­nie­ren nicht rich­tig, sind “off­line” oder ha­ben kei­ne Ver­bin­dung zur NFON Cloud? Dann musst Du den Feh­ler ein­gren­zen, wir nen­nen das auch Trou­ble­shoo­ting.

In den meis­ten Fäl­len ist das Com­pu­ter-Netz­werk (LAN) de­fekt oder dein In­ter­net­an­schluss streikt. In wirk­lich sehr sel­te­nen Fäl­len ist die NFON Platt­form ge­stört. Schaue hier, ob bei NFON ei­ne Stö­rung vor­liegt:

• sta​tus​.nfon​.com

Wenn bei NFON “al­les grün” ist, dann musst Du die Stö­rung in dei­nem Haus oder bei dei­nem In­ter­net-Pro­vi­der su­chen.

Fire­wall prü­fen

Als NFON-Ad­mi­nis­tra­tor kennst Du ver­mut­lich das NFON-Merk­blatt “Plug & Play 2.0” aus­wen­dig:

• https://www.nfon.com/de/systemspecifictopics/merkblatt-plug-play-20/b‑router-/-firewall-einstellungen
• https://www.nfon.com/de/systemspecifictopics/merkblatt-plug-play-20/a‑anforderungen

Im Ab­schnitt “Fire­wall Ein­stel­lun­gen” er­kennt man drei Be­rei­che:

1. Für die ers­te In­be­trieb­nah­me von neu­er Hard­ware (IP-Pho­nes, a/b‑Adapter, DECT-Ba­sis­sta­tio­nen…) muss das End­ge­rät mit dem je­wei­li­gen Ge­rä­te­her­stel­ler (Ye­al­ink, Grand­stream, Gi­ga­s­et…) kom­mu­ni­zie­ren kön­nen.
2. Die grund­le­gen­den Netz­diens­te wie DHCP, DNS und NTP soll­ten in je­dem Netz­werk zur Ver­fü­gung ste­hen. Die NFON weist den IP-Pho­nes beim Pro­vi­sio­ning ei­nen NFON-NTP-Ser­ver zu.
3. Die­se bei­den Re­geln sind “man­da­to­ry” und nicht dis­ku­ta­bel. Das Ziel­netz 109.68.96.0/21 ist ein­deu­tig und um­faßt al­le Diens­te der NFON-Platt­form. Es müs­sen al­le De­sti­na­ti­on-Ports frei­ge­ge­ben wer­den, da bei VoIP die Ports dy­na­misch aus­ge­han­delt wer­den.

Dein Netz­werk-Ad­mi­nis­tra­tor soll­te wis­sen, ob die oben ge­nann­ten Fire­wall-Ein­stel­lun­gen in dei­nem Netz­werk um­ge­setzt wur­den.

Wei­te­re An­for­de­run­gen aus dem NFON-Merk­blatt:

• ICMP-Pa­ke­te mit Typ 3 (De­sti­na­ti­on un­re­acha­ble) nicht blo­ckie­ren
• Kei­ne DNS- / FQDN-ba­sier­ten Fil­ter­re­geln
• UDP-NAT Time­out zwi­schen 120 und 130 Se­kun­den
• De­ak­ti­vie­rung von SIP-ALG (Ap­pli­ca­ti­on Lay­er Gate­way)
• UDP-Frag­men­tie­rung er­lau­ben

Rou­ter prü­fen

Der In­ter­net­rou­ter soll­te kei­ne Te­le­fo­nie­funk­tio­nen be­reit­stel­len! Ins­be­son­de­re soll­te der Rou­ter über DHCP kei­ne Op­ti­on 66 (BOOTP-Ser­ver) an­bie­ten. Die Te­le­fo­ne im Netz­werk über­neh­men die­se Op­ti­on und funk­tio­nie­ren ver­mut­lich nicht rich­tig.

Netz­werk prü­fen

Kommst Du ins In­ter­net? Wenn nein, dann ist ver­mut­lich dein In­ter­net-An­schluss ge­stört. Kannst Du dei­nen In­ter­net-Rou­ter (Fritz­Box, Di­gi­ta­li­sie­rungs­box, Lan­com…) er­rei­chen? Öff­ne auf dei­nem Win­dows-PC ei­ne Ein­ga­be­auf­for­de­rung (cmd) und ge­be fol­gen­den Be­feh­le ein:

Die Screen­shots zei­gen, wie es aus­se­hen soll­te. Die Screen­shots zei­gen, dass die Ver­bin­dung zu NFON-Platt­form grund­sätz­lich OK ist.

(*) Die IP-Adres­se 109.68.96.128 wur­de am 20.09.2024 von NFON de­ak­ti­viert.

(**) Er­setzt ein­fach kxxxx ge­gen die ID eu­rer NFON Cloud-Te­le­fon­an­la­ge.

NTP-Ser­ver

NFON hat im Rah­men von lan­ge zu­vor an­ge­kün­dig­ten War­tungs­maß­nah­men den zen­tra­len Re­gis­trie­rungs­ser­ver (ZREG) 109.68.96.128 ab­ge­schal­tet. Die­ser Ser­ver wur­de ur­sprüng­lich auch als NTP-Ser­ver für Sys­tem­te­le­fo­ne ver­wen­det.

NFON ver­sorgt al­le Sys­tem­te­le­fo­ne in der Pro­vi­sio­ning-Pha­se, al­so bei der In­be­trieb­nah­me, mit vie­len Sys­tem­pa­ra­me­tern. Den Sys­tem­te­le­fo­nen wird u.a. ei­ne neue IP-Adres­se für den NTP-Ser­ver mit­ge­teilt.

An­schei­nend ha­ben nicht al­le Sys­tem­te­le­fo­ne die­se Än­de­rung von NFON er­hal­ten und so kann es sein, das Sys­tem­te­le­fo­ne nach ei­nem Re­boot die fal­sche Zeit und fal­sche Ruf­lis­ten an­zei­gen.

NFON emp­fiehlt den NTP-Ser­ver 162.159.200.123. Die­se Adres­se ist au­ßer­halb der NTP-Platt­form und die Er­reich­bar­keit (UDP- NTP ==> Al­le Net­ze) ist über das NFON-Merk­blatt “Plug & Play 2.0” er­for­der­lich. Sie­he Ab­schnitt Fire­wall prü­fen

Bei Pro­ble­men soll­te der NFON-Ad­min den NTP-Ser­ver in die Stand­ort-Kon­fi­gu­ra­ti­on ein­tra­gen. Kon­fi­gu­ra­ti­ons­por­tal ==> Ad­mi­nis­tra­ti­on==> Stand­or­te

Clou­dya Net­work As­sess­ment

Der NFON Speed­test ist ei­ne Cli­ent-Ser­ver-An­wen­dung und be­steht aus zwei Kom­po­nen­ten: Ei­nen Web-Ser­vice im Re­chen­zen­trum der NFON und der An­wen­dung BCSWinApp.exe von der Fir­ma Vi­su­al­wa­re Inc. Die An­wen­dung läuft auf dei­nem PC.

Die Nut­zung ist z.Zt. noch et­was um­ständ­lich, da das Clou­dya Net­work As­ses­ment in dei­nem Netz­werk auf ei­ne be­stimm­te Adres­se zu­grei­fen möch­te um die lo­ka­le An­wen­dung zu er­rei­chen.

Zu­nächst öff­nest Du den fol­gen­den Link, lädst und star­test die An­wen­dung:

• https://​speed​test​.nfon​.net/

Die An­wen­dung ist recht un­spek­ta­ku­lär und “lauscht” auf dei­nem PC auf die Adres­se 127.0.0.1 (lo­cal­host)

FRITZ!Box

Wenn Du den NFON Speed­test ma­chen möch­test und ei­ne FRITZ!Box nutzt, dann wer­den Do­main­ab­fra­gen auf lo­ka­le Adres­sen von der FRITZ!Box un­ter­bun­den. Man nennt das auch DNS-Re­bind-Schutz. Du kannst die­sen Schutz der FRITZ!Box je­doch an­pas­sen.

Mel­de dich an dei­ner FRITZ!Box an und ge­he zu Heim­netz => Netz­werk => Netz­werk­ein­stel­lun­gen => wei­te­re Ein­stel­lun­gen => DNS-Re­bind-Schutz

Tra­ge hier die Adres­se bcs​.vi​su​al​wa​re​.com ein. Tes­te den Ein­trag mit ping bcs​.vi​su​al​wa​re​.com.

hosts-Da­tei

Wenn Du den NFON Speed­test ma­chen möch­test, kei­ne FRITZ!Box hast oder dir der Zu­griff auf die FRITZ!Box fehlt, dann kannst Du “auf die har­te Me­tho­de” die Na­mens­auf­lö­sung er­zwin­gen. Star­te ei­nen Text­edi­tor wie z.B. No­te­pad++ im Ad­min-Mo­dus und öff­ne die Da­tei %windir%\system32\drivers\etc\hosts

Tra­ge dort fol­gen­de Zei­le ein und spei­che­re die Da­tei ganz vor­sich­tig 😉

127.0.0.1 bcs.visualware.com

Tes­te den Ein­trag mit ping bcs​.vi​su​al​wa​re​.com.

Test aus­füh­ren

Nun kannst Du den ei­gent­li­chen Test durch­füh­ren. Die Er­geb­nis­se wer­den wie folgt dar­ge­stellt:

Web­RTC-Test

Die Web App nutzt die im Chrom-Brow­ser in­te­grier­ten Web­RTC-Funk­tio­nen. Wenn Du Web­RTC tes­ten möch­test, dann bie­tet sich ein an­de­rer Test an. Öff­ne auf dei­nem PC den Chro­me Web-Brow­ser und star­te den Web­RTC-Test:

• https://​web​casts​.com/​w​e​b​r​tc/

Der Web­RTC-Test baut ei­ne Ver­bin­dung zu ei­nem Ser­ver auf und prüft Ka­me­ra, Mi­kro­fon und Netz­werk­ver­bin­dung:

Das rech­te Bild zeigt deut­lich: Das Netz­werk ist nicht ge­eig­net. Hier muss zwin­gend Dein Netz­werk-Ad­mi­nis­tra­tor ran.

Mo­bi­le App Log­files

Die Mo­bi­le App kann sich auch gut zur Netz­werk-Ana­ly­se nut­zen. Das ne­ben­ste­hen­de Bild zeigt ei­nen Screen­shot der Mo­bi­le App.

Über Sup­port => Log­files kann man das Log­ging ak­ti­vie­ren und die Meß­wer­te aus­le­sen.

Ne­ben vie­len kryp­ti­schen In­for­ma­tio­nen kann man für Emp­fangs (rx) und Sen­de­riuch­tung (tx) die über­tra­ge­nen Da­ten se­hen.

Die Zah­len für Dis­card, Loss, Re­or­der, Du­pli­ca­te soll­ten klein sein und nicht stei­gen.

Sprach­qua­li­tät prü­fen

Sie­he auch:

• Pho­ner­Li­te
• Trou­ble­shoo­ting