Hallo!
Derzeit habe ich einen Lancom 1723 zum Testen für meinen offenbar extrem seltsamen Anwendungsfall, nämlich die Nutzung dieses Geräts als Unteranlage am internen S0 einer ISDN-Hauptanlage, um daran WLAN-Telefone anzubinden. Nachdem ich schon mit zwei Geräten anderer Fabrikate nicht rundum zufrieden war bzw. bin (Horstbox Pro - kommt mit internem S0 nicht klar, kein sauberes QoS, schlechte Sprachqualität; Funkwerk TR200bw - bisher das beste Gerät, aber kann kein Outband-DTMF (mit G.711), hat große Latenzen in beide Richtungen und kommt immer wieder an Speicherlimits), wollte ich noch etwas anderes testen und kam da auf die Lancom-Geräte, die mir ein Bekannter nahelegte und mir auch für einige Wochen nun eines zum Testen zur Verfügung stellen kann.
Meine folgenden Fragen habe ich schon an Lancom geschrieben, aber da immer wieder zu lesen ist, daß in der Regel solche Mails unbeantwortet bleiben, habe ich nun etwas Hoffnung, vielleicht in diesem Forum einen Tip bekommen zu können, der mit eine Kaufentscheidung erleichtern kann.
1. Latenzverhalten
Da ich klassisches ISDN- und Analogtelefonieren bevorzuge, lege ich auf Sprachqualität (und Zuverlässigkeit) höchsten Wert, und leider hat der 1723 hier Licht und Schatten in extremer Weise beieinander:
Bei einem Gespräch von einem SIP-Teilnehmer zu einem ISDN- oder auch am 1723 angeschlossenen Analogteilnehmer ist die Latenz hervorrangend niedrig, wenn man die "Sprechrichtung" von SIP zu ISDN/Analog betrachtet. Leider ist der Rückweg um Welten schlechter - von ISDN/Analog zum SIP-Telefon sprechend ist eine sehr hohe Latenz zu beobachten.
Warum ist dies der Fall? Wenn es in die eine Richtung mit kleinem Jitter-Puffer geht, müßte es umgekehrt doch auch möglich sein? Es sind LAN-Idealbedingungen mit maximal 4-5 ms Paketlaufzeiten, d.h. der adaptive Puffer sollte auf sein Minimum zurückgehen können.
Interessanterweise gibt es auch noch einen Nebeneffekt: wenn der 1723 neugestartet wird, ist in der ersten Zeit danach die Latenz deutlich niedriger, etabliert sich nach mehreren Gesprächen aber wieder auf dem sehr auffälligen, hohen Wert.
Mit verschiedenen Codecs und dem Ein- und Ausschalten der Echokompensation habe ich schon experimentiert, diese haben aber offenbar keinen Einfluß auf diese Verzögerung.
2. Vermitteln an einer übergeordneten TK-Anlage
Ein weiteres Problem, wie aber offenbar bei den meisten Geräten dieser Art, ist die Annahme, daß sie sich direkt am Amt befinden - eine Vermittlungssteuerung an übergeordneten Anlagen scheint nicht möglich, obwohl bei Lancom der Fall (17xx als Unteranlage) sogar im Handbuch beschrieben ist.
Gibt es hier irgendwelche Tricks, ggf. mit dem Call-Routing sowas einrichten zu können?
Zusätzlich fällt mir auf, daß an den Analogports während eines Gesprächs nicht auf die R-Taste reagiert wird, das Gespräch wird nicht gehalten (was beim SIP-Endgerät wiederum geht). Habe ich etwas übersehen, daß das erst funktionieren kann, wenn bestimmte Einstellungen gesetzt sind?
Über jeden konstruktiven Tip, auch nur zu einer der Fragestellungen, würde ich mich sehr freuen - alternativ auch über eine Info, ob in einer kommenden Version der Firmware hier evtl. Verbesserungen möglich bzw. zu erwarten sind.
Besten Dank und freundliche Grüße,
Hans-Jürgen
1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermitteln
Moderator: Lancom-Systems Moderatoren
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hallo Hans-Jürgen,
genannten „kurzen“ Flash (80 bis 150 ms).
Das ist doch klar, SIP ist doch rein Digital. Und nicht wie bei Analog-Telefonen, wo die "R-Taste" eine kurze Leitungsunterbrechung im Millisekundenbereich erzeugt, die dann noch richtig (zeitgerecht) Ausgelöst werden muß.
Grüße
Cpuprofi
Was meinst Du damit genau? Sind Störungen bei der Sprache (Unterbrechungen, verschluckte Laute) zu beobachten?1. Latenzverhalten...von ISDN/Analog zum SIP-Telefon sprechend ist eine sehr hohe Latenz zu beobachten...
Welchen Flash haben den Deine Analog-Telefone? LANCOM Business-VoIP-Router erwarten einen so2. Vermitteln an einer übergeordneten TK-Anlage...Zusätzlich fällt mir auf, daß an den Analogports während eines Gesprächs nicht auf die R-Taste reagiert wird, das Gespräch wird nicht gehalten.
genannten „kurzen“ Flash (80 bis 150 ms).
...was beim SIP-Endgerät wiederum geht...
Das ist doch klar, SIP ist doch rein Digital. Und nicht wie bei Analog-Telefonen, wo die "R-Taste" eine kurze Leitungsunterbrechung im Millisekundenbereich erzeugt, die dann noch richtig (zeitgerecht) Ausgelöst werden muß.
Grüße
Cpuprofi
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hallo Cpuprofi,
danke für die erste Rückmeldung
OK, dann kläre ich mal schnell die Frage/Mißverständnisse:
==> Latenzverhalten: grundsätzlich meinte ich mit Latenz eine (unnötig) hohe Verzögerung, auch oft "Delay" genannt. Wenn der entfernte Tln ein akustisch und/oder elektrisch schlecht entkoppeltes Telefon hat, bekomme ich durch diese Latenz massive Echos an meinem SIP-Apparat.
Daß bei der Verarbeitung ein gewisses Delay entsteht ist unvermeidlich, allerdings sind alle Bedingungen auf Low-Latency/Low-Jitter optimiert: SIP nur im LAN, QoS vollständig aktiviert (wär aber bei Niedriglast eh nicht so wichtig), usw.
Das Komische ist, daß dieses Verhalten unidirektional ist, d.h. die vom SIP-Tln zum Analog- oder ISDN-Tln. fließende Sprache hat Delay/Latenz von geschätzt unter 40 ms, in Gegenrichtung (Sprechrichtung von Analog/ISDN zu SIP) ist das Delay massiv größer, geschätzt > 100 ms.
Um Mißverständnisse zu vermeiden: es geht mir mit dem Begriff "Sprechrichtung" um ein- und dasselbe Gespräch, in dem dieses asymmetrische Verhalten zu bemerken ist, es geht NICHT darum, welcher Tln. den Ruf initiiert o.ä.!
Absolut unlogisch wird das Verhalten, wenn man bedenkt, daß gerade aus ISDN/analog keinerlei Quell-Jitter entsteht und daher kein unnötig großer FIFO-Puffer erforderlich sein sollte.
==> Rückfrageverhalten: die "Gleichsetzung" von R-Taste und SIP-Signalisierung war nur logisch gemeint, daß es physikalisch anders läuft ist klar. Flash sollte an den betroffenen Tln auf 100 ms sein, werde ich aber nochmal prüfen, ob da ggf. sich was verstellt hat. Gegen zu langen Flash spricht, daß das Gespräch bestehenbleibt und nicht ausgelöst wird, was die übliche Nebenwirkung zu "langen" Flashes wäre.
Sofern die Flash-Zeit stimmt, was ich heute abend prüfen werde, sollte dann das Gespräch in einen Halte-/Rückfragezustand gehen, oder ist hierfür eine weitere Einstellung als Vorbedingung erforderlich? Im Call-Routing habe ich die beiden Standard-Einträge verwendet, die eine "direkte Amtsholung" erlauben und für Lancom-lokale Gespräche einen Stern als Präfix erfordern. Immerhin ist damit schonmal eine Transparenz der internen Teilnehmernummern gegeben, die problemlos an der Hauptanlage gerufen werden, ohne daß die am 1723 hängenden Tln Inkonsistenzen in der Bedienung haben.
Wie gesagt, bisher macht der Lancom auf mich einen der besten Eindrücke, was Qualität und Stabilität der Funktionalität betrifft - mit der Signalisierung an internen S0-Bussen tun sich manch andere "Kistchen" deutlich schwerer. Man merkt, daß ISDN schon eine Stärke der deutschen Hersteller ist, denn nur das Funkwerk-Teil bietet hier ein ähnliches Niveau. Neben der Horstbox habe ich noch ein anderes "ausländisches" Fabrikat im Test, das im SIP-Teil besser ist als Funkwerk und Lancom (da macht z.B. der adaptive Puffer was er soll und minimiert die - symmetrische - Latenz schrittweise innerhalb der ersten ca. 30 Gesprächssekunden), aber wo das ISDN ziemlich ächzt...
Besten Dank und schöne Grüße,
Hans-Jürgen
danke für die erste Rückmeldung
OK, dann kläre ich mal schnell die Frage/Mißverständnisse:==> Latenzverhalten: grundsätzlich meinte ich mit Latenz eine (unnötig) hohe Verzögerung, auch oft "Delay" genannt. Wenn der entfernte Tln ein akustisch und/oder elektrisch schlecht entkoppeltes Telefon hat, bekomme ich durch diese Latenz massive Echos an meinem SIP-Apparat.
Daß bei der Verarbeitung ein gewisses Delay entsteht ist unvermeidlich, allerdings sind alle Bedingungen auf Low-Latency/Low-Jitter optimiert: SIP nur im LAN, QoS vollständig aktiviert (wär aber bei Niedriglast eh nicht so wichtig), usw.
Das Komische ist, daß dieses Verhalten unidirektional ist, d.h. die vom SIP-Tln zum Analog- oder ISDN-Tln. fließende Sprache hat Delay/Latenz von geschätzt unter 40 ms, in Gegenrichtung (Sprechrichtung von Analog/ISDN zu SIP) ist das Delay massiv größer, geschätzt > 100 ms.
Um Mißverständnisse zu vermeiden: es geht mir mit dem Begriff "Sprechrichtung" um ein- und dasselbe Gespräch, in dem dieses asymmetrische Verhalten zu bemerken ist, es geht NICHT darum, welcher Tln. den Ruf initiiert o.ä.!
Absolut unlogisch wird das Verhalten, wenn man bedenkt, daß gerade aus ISDN/analog keinerlei Quell-Jitter entsteht und daher kein unnötig großer FIFO-Puffer erforderlich sein sollte.
==> Rückfrageverhalten: die "Gleichsetzung" von R-Taste und SIP-Signalisierung war nur logisch gemeint, daß es physikalisch anders läuft ist klar. Flash sollte an den betroffenen Tln auf 100 ms sein, werde ich aber nochmal prüfen, ob da ggf. sich was verstellt hat. Gegen zu langen Flash spricht, daß das Gespräch bestehenbleibt und nicht ausgelöst wird, was die übliche Nebenwirkung zu "langen" Flashes wäre.
Sofern die Flash-Zeit stimmt, was ich heute abend prüfen werde, sollte dann das Gespräch in einen Halte-/Rückfragezustand gehen, oder ist hierfür eine weitere Einstellung als Vorbedingung erforderlich? Im Call-Routing habe ich die beiden Standard-Einträge verwendet, die eine "direkte Amtsholung" erlauben und für Lancom-lokale Gespräche einen Stern als Präfix erfordern. Immerhin ist damit schonmal eine Transparenz der internen Teilnehmernummern gegeben, die problemlos an der Hauptanlage gerufen werden, ohne daß die am 1723 hängenden Tln Inkonsistenzen in der Bedienung haben.
Wie gesagt, bisher macht der Lancom auf mich einen der besten Eindrücke, was Qualität und Stabilität der Funktionalität betrifft - mit der Signalisierung an internen S0-Bussen tun sich manch andere "Kistchen" deutlich schwerer. Man merkt, daß ISDN schon eine Stärke der deutschen Hersteller ist, denn nur das Funkwerk-Teil bietet hier ein ähnliches Niveau. Neben der Horstbox habe ich noch ein anderes "ausländisches" Fabrikat im Test, das im SIP-Teil besser ist als Funkwerk und Lancom (da macht z.B. der adaptive Puffer was er soll und minimiert die - symmetrische - Latenz schrittweise innerhalb der ersten ca. 30 Gesprächssekunden), aber wo das ISDN ziemlich ächzt...
Besten Dank und schöne Grüße,
Hans-Jürgen
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hallo Hans-Jürgen,
Wie schaut es aus mit dem IP-Telefon selber? Das verursacht ja in der beschriebenen Richtung im Normalfall auch eine gewisse Latenz.
Und dann kommt das WLAN dazu. Hast Du da mal drüber nachgedacht? Hast Du denn mal mit einem schnurgebundenen IP-Telefon getestet?
Von welcher Firmware-Version reden wir hier überhaupt?
G.726 würde ich (im LANCOM) aus anderen Gründen (Inkompatibilität, entspricht nicht aktueller RFC) abschalten (unter VoIP-Call-Manager -> Codecs)
G.729 würde ich ebenfalls nicht abschalten (kommt eigentlich in der Praxis selten zur Anwendung, nur für extrem geringen Bandbreiten, hat übrigens eine zusätzliche algorithmische Verzögerung von ca. 10 ms pro Audio-Frame mit 5 ms look-ahead)
Viele Grüße,
Jirka
na ja, extrem selten würde ich nicht sagen...hjm82 hat geschrieben:für meinen offenbar extrem seltsamen Anwendungsfall, nämlich die Nutzung dieses Geräts als Unteranlage am internen S0 einer ISDN-Hauptanlage, um daran WLAN-Telefone anzubinden.
Wie hast Du denn das gemessen? Oder einfach ausprobiert und Hörer der anderen Seite ans Ohr?hjm82 hat geschrieben:Bei einem Gespräch von einem SIP-Teilnehmer zu einem ISDN- oder auch am 1723 angeschlossenen Analogteilnehmer ist die Latenz hervorrangend niedrig, wenn man die "Sprechrichtung" von SIP zu ISDN/Analog betrachtet. Leider ist der Rückweg um Welten schlechter - von ISDN/Analog zum SIP-Telefon sprechend ist eine sehr hohe Latenz zu beobachten.
Wie schaut es aus mit dem IP-Telefon selber? Das verursacht ja in der beschriebenen Richtung im Normalfall auch eine gewisse Latenz.
Und dann kommt das WLAN dazu. Hast Du da mal drüber nachgedacht? Hast Du denn mal mit einem schnurgebundenen IP-Telefon getestet?
Also in die Richtung ISDN/Analog -> SIP sollte es gar keinen Jitter-Buffer geben, dafür ist das Endgerät zuständig (IP-Telefon).hjm82 hat geschrieben:Wenn es in die eine Richtung mit kleinem Jitter-Puffer geht, müßte es umgekehrt doch auch möglich sein? Es sind LAN-Idealbedingungen mit maximal 4-5 ms Paketlaufzeiten, d.h. der adaptive Puffer sollte auf sein Minimum zurückgehen können.
Ok, das spricht ja schon mal dafür, dass es sich hier tatsächlich um ein Problem im LANCOM handelt.hjm82 hat geschrieben:Interessanterweise gibt es auch noch einen Nebeneffekt: wenn der 1723 neugestartet wird, ist in der ersten Zeit danach die Latenz deutlich niedriger, etabliert sich nach mehreren Gesprächen aber wieder auf dem sehr auffälligen, hohen Wert.
Von welcher Firmware-Version reden wir hier überhaupt?
Also G.711 sollte man nicht abschaltenhjm82 hat geschrieben:Mit verschiedenen Codecs und dem Ein- und Ausschalten der Echokompensation habe ich schon experimentiert, diese haben aber offenbar keinen Einfluß auf diese Verzögerung.
G.726 würde ich (im LANCOM) aus anderen Gründen (Inkompatibilität, entspricht nicht aktueller RFC) abschalten (unter VoIP-Call-Manager -> Codecs)
G.729 würde ich ebenfalls nicht abschalten (kommt eigentlich in der Praxis selten zur Anwendung, nur für extrem geringen Bandbreiten, hat übrigens eine zusätzliche algorithmische Verzögerung von ca. 10 ms pro Audio-Frame mit 5 ms look-ahead)
Was meinst Du damit genau?hjm82 hat geschrieben:Ein weiteres Problem, wie aber offenbar bei den meisten Geräten dieser Art, ist die Annahme, daß sie sich direkt am Amt befinden - eine Vermittlungssteuerung an übergeordneten Anlagen scheint nicht möglich
Wenn Du das Forum diesbezüglich gründlich liest, kommst Du zu dem Ergebnis, dass Du Dir da keine Hoffnungen machen solltest...hjm82 hat geschrieben:alternativ auch über eine Info, ob in einer kommenden Version der Firmware hier evtl. Verbesserungen möglich bzw. zu erwarten sind.
Viele Grüße,
Jirka
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hi,
Man sollte hier erst mal den Zwischenschritt ohne WLAN gehen, um die Fehlerquellen einzugrenzen...
Viele Grüße,
Jirka
wenn Du das wirklich von Anfang bis Ende (=WLAN) durchkonfiguriert hast (und nicht über alle Details des QoS Bescheid weißt), dann ist das Ergebnis vermutlich, dass Du SIP-Pakete im WLAN mit Background-Priorität verarbeitest. Siehe dazu http://www.lancom-forum.de/lancom-wirel ... t9123.html irgendwo in der Mitte des Threads (http://www.lancom-forum.de/lancom-wirel ... tml#p50627).hjm82 hat geschrieben:QoS vollständig aktiviert
Man sollte hier erst mal den Zwischenschritt ohne WLAN gehen, um die Fehlerquellen einzugrenzen...
Viele Grüße,
Jirka
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hallo Jirka,
erstmal ganz herzlichen Dank für die vielen und schon recht guten Antworten! Und danke auch für den Mut, mein Einsatzszenario als nicht so abwegig zu bezeichnen... manche Hersteller sehen das anders. Aber wie gesagt, bis auf das Vermitteln bin ich mit dem Verhalten des Lancom am internen ISDN sehr zufrieden, er macht kaum "Schweinereien" wie B-Kanäle zu lange belegen oder ähnliches...
Latenzverhalten: Hier habe ich nicht gemessen, sondern tatsächlich mich auf die hörbaren Zeiten mit nem zweiten Hörer verlassen Da ich aber auch viel mit Audiotechnik zu tun habe, in der Verzögerungen wichtig sind (z.B. bei Beschallungsanwendungen), kann ich Laufzeiten recht gut schätzen und höre auch Unterschiede ab 3 ms raus.
Habe gestern gleich nochmals einen Neustart des 1723 durchgeführt und, da bisher wenige Gespräche waren, jetzt immer noch recht kurze Latenzen:
vom SIP-Tln zum ISDN-Tln: ca. 30 ms, von ISDN-Tln zum SIP-Tln: bei Gesprächsbeginn ca. 90 ms, statisch (nach jetzt 9 min. Testgespräch) dann ca. 50 ms (eine gewisse Auto-Adaption des Puffers ist, insbesondere frisch nach einem Neustart, immer erkennbar, aber sie ist sehr langsam - in der zweiten Minute des Testgesprächs war die Latenz noch bei ca. 70 ms).
Telefontechnisch habe ich leider derzeit keine kabelgebundene Alternative eines IP-Geräts, da das WLAN bei mir der primäre Anwendungsfall war und das "Herumschlagen" mit IP-Telefonie ausgelöst hat Aber vielleicht läuft mir ja noch ein Gerät zu...
Unabhängig davon kann ich sagen, z.B. mit der sonst recht schlechten Horstbox schon sehr kurze Latenzen erlebt habe - und zwar symmetrisch in beide Richtungen. Mit den aktuell im Test erreichbaren "Traumwerten" wäre ich auch langfristig zufrieden (hier könnte nur noch die Adaption schneller sein) - wenn nicht dieser selbsttätige und bis zum Reboot bleibende "Rückfall" in die extralange Latenz immer wieder auftreten würde.
In den kommenden Tagen werde ich mal beobachten, wie lange jetzt der "kurze" Zustand bleibt. Hier sieht es schon nach einem Firmware-Bug aus - ich erinnere mich auch an Beiträge in einem Forum (hier oder IPPF), wo genau das beschrieben wurde - mehr Echo mit längerem Betrieb. Allerdings war das vor 2010, daher hätte und habe ich das erstmal als nicht maßgeblich für die aktuellen Versionen gehalten.
Achso, die Firmware: hier habe ich die aktuelle 8.80 drauf (und die 8.82 mit gleichem Ergebnis schon getestet).
Zu den Codecs: das war wohl ein Mißverständnis mit G.711, aber nicht auf meiner Seite: ich hatte extra geschrieben, die Echokompenstation und nicht einen bestimmten Codec ein- und ausgeschaltet zu haben
Ansonsten habe ich alles auf G.711 eingeschränkt, da ich im LAN keine Bandbreite sparen muß. Leider scheint man aber die Reihenfolge der Codecs nicht priorisieren zu können, so daß ich G.711 µ-Law deaktiviert habe, weil der scheinbar (zumindest in der Liste) vor A-Law kommt...
Direkt am Amt: Hiermit meine ich, daß ein interner S0 Besonderheiten hat, die bei einigen Geräten (aber NICHT Lancom und auch NICHT Funkwerk) zu Störungen führen. Da am internen S0 die "MSNs" direkt interne Tln-Nummern sind, werden bei typischer Anwendung mehrere davon gleichzeitig gerufen (im GEgensatz zu Amt-MSN, wo es praktisch nur eine zeitgleich ist). Das läßt manche Geräte das Handtuch werfen.
Vermittlungsproblematik: Was aber nun eben auch Lancom betrifft: es scheint so zu sein, daß man ein Gespräch nicht "hochvermitteln" kann an eine übergeordnete Anlage. Auch hier kommt möglicherweise zum Tragen, daß eine "MSN" am internen S0 eine Tln-Nummer ist, womit pro MSN auch nur 1 B-Kanal belegt werden kann. Daher kann beim Vermitteln kein 2. B-Kanal belegt werden, sondern das Gespräch müßte in der ÜBERGEORDNETEN Anlage gehalten werden. Da jede Box aber denkt, selbst am Amt zu hängen, will sie das Gespräch intern halten und für die Rückfrage einen 2. B-Kanal mit derselben MSN belegen. Das geht aber nicht, daher endet der Vermittlungsversuch leider hier
Oder es gibt hier im Forum gute Tips, wie man das Verhalten so programmieren kann
zu erwartende Firmware-Verbesserungen: Ja, leider bekomme ich das schon mit, daß der Telefonieteil das Stiefkind zu sein scheint. Allerdings wundert es mich - gerade jetzt, wo das Thema (leider!) auch zwanghaft von manchen Providern forciert wird, und nicht jeder eine Consumerkiste aus Berlin haben will (ich übrigens auch nicht...) - ganz abgesehen vom Business-Bereich, in dem meines Erachtens die Consumerkisten eh nix verloren haben und ich froh bin, daß es auch noch reine xDSL-Modems ohne Schnickschnack gibt, wenn man z.B. einen Rechner als Gateway hat. Aber das geht jetzt vom Thema ab...
QoS: Doch, hier kann ich nach harter Einarbeitung sagen, das sauber Ende-zu-Ende umgesetzt zu haben - ich beschäftige mich (ernsthaft, nicht ironisch) gerne sehr detailliert mit Netzwerktechnik. Ich finde es nur abstrus, wie oft die Begriffe verwechselt werden oder Halbwissen - auch bei Geräteherstellern - vorhanden ist.
Auf Layer 3 priorisiere ich RTP mit dem ToS-kompatiblen DSCP-Wert "Class Selector 6" und SIP mit dem ToS-kompatiblen DSCP-Wert "Class Selector 5". Dies machen alle Geräte sendend, Lancom und SIP-Telefon - beide erlauben zum Glück die Einstellung
Dies mache ich deswegen so, da die APs immer noch an ToS und nicht an DSCP angelehnt sind und mit "Expedited Forwarding", was oft in SIP-Geräten vorgewählt ist, eine Luftschnittstellen-Priorisierung von AC_VI(deo) statt AC_VO(ice) gemäß WMM vornehmen würden.
Um auf 802.1q-getaggten Strecken noch die Information parallel passend zu haben (und switch-intern die passende Queue zu bekommen), habe ich auf den Managed-Switchen noch ein Rewrite der Priorisierung von Layer 3 nach Layer 2 (802.1p) auf alle eingehenden Pakete eingerichtet.
Hier zur Bestätigung ein kleiner Auszug aus dem Telefon-Syslog von meinem Testanruf:
Besten Dank und schöne Grüße,
Hans-Jürgen
Nachtrag: bezüglich der FLASH-Zeit am Analog-Tln. hatte sich tatsächlich was am Telefon verstellt, oder das Handbuch hat einen Fehler. Ich habe auf die andere (im Handbuch als "lang" bezeichnete) Flash-Zeit gestellt, und nun habe ich am Analog-Telefon dasselbe logische Verhalten wie am SIP-Gerät: Halten und wieder zurückholen geht, Vermitteln läuft ins Leere.
erstmal ganz herzlichen Dank für die vielen und schon recht guten Antworten! Und danke auch für den Mut, mein Einsatzszenario als nicht so abwegig zu bezeichnen... manche Hersteller sehen das anders. Aber wie gesagt, bis auf das Vermitteln bin ich mit dem Verhalten des Lancom am internen ISDN sehr zufrieden, er macht kaum "Schweinereien" wie B-Kanäle zu lange belegen oder ähnliches...
Latenzverhalten: Hier habe ich nicht gemessen, sondern tatsächlich mich auf die hörbaren Zeiten mit nem zweiten Hörer verlassen
Da ich aber auch viel mit Audiotechnik zu tun habe, in der Verzögerungen wichtig sind (z.B. bei Beschallungsanwendungen), kann ich Laufzeiten recht gut schätzen und höre auch Unterschiede ab 3 ms raus.Habe gestern gleich nochmals einen Neustart des 1723 durchgeführt und, da bisher wenige Gespräche waren, jetzt immer noch recht kurze Latenzen:
vom SIP-Tln zum ISDN-Tln: ca. 30 ms, von ISDN-Tln zum SIP-Tln: bei Gesprächsbeginn ca. 90 ms, statisch (nach jetzt 9 min. Testgespräch) dann ca. 50 ms (eine gewisse Auto-Adaption des Puffers ist, insbesondere frisch nach einem Neustart, immer erkennbar, aber sie ist sehr langsam - in der zweiten Minute des Testgesprächs war die Latenz noch bei ca. 70 ms).
Telefontechnisch habe ich leider derzeit keine kabelgebundene Alternative eines IP-Geräts, da das WLAN bei mir der primäre Anwendungsfall war und das "Herumschlagen" mit IP-Telefonie ausgelöst hat
Aber vielleicht läuft mir ja noch ein Gerät zu...Unabhängig davon kann ich sagen, z.B. mit der sonst recht schlechten Horstbox schon sehr kurze Latenzen erlebt habe - und zwar symmetrisch in beide Richtungen. Mit den aktuell im Test erreichbaren "Traumwerten" wäre ich auch langfristig zufrieden (hier könnte nur noch die Adaption schneller sein) - wenn nicht dieser selbsttätige und bis zum Reboot bleibende "Rückfall" in die extralange Latenz immer wieder auftreten würde.
In den kommenden Tagen werde ich mal beobachten, wie lange jetzt der "kurze" Zustand bleibt. Hier sieht es schon nach einem Firmware-Bug aus - ich erinnere mich auch an Beiträge in einem Forum (hier oder IPPF), wo genau das beschrieben wurde - mehr Echo mit längerem Betrieb. Allerdings war das vor 2010, daher hätte und habe ich das erstmal als nicht maßgeblich für die aktuellen Versionen gehalten.
Achso, die Firmware: hier habe ich die aktuelle 8.80 drauf (und die 8.82 mit gleichem Ergebnis schon getestet).
Zu den Codecs: das war wohl ein Mißverständnis mit G.711, aber nicht auf meiner Seite: ich hatte extra geschrieben, die Echokompenstation und nicht einen bestimmten Codec ein- und ausgeschaltet zu haben
Ansonsten habe ich alles auf G.711 eingeschränkt, da ich im LAN keine Bandbreite sparen muß. Leider scheint man aber die Reihenfolge der Codecs nicht priorisieren zu können, so daß ich G.711 µ-Law deaktiviert habe, weil der scheinbar (zumindest in der Liste) vor A-Law kommt...
Direkt am Amt: Hiermit meine ich, daß ein interner S0 Besonderheiten hat, die bei einigen Geräten (aber NICHT Lancom und auch NICHT Funkwerk) zu Störungen führen. Da am internen S0 die "MSNs" direkt interne Tln-Nummern sind, werden bei typischer Anwendung mehrere davon gleichzeitig gerufen (im GEgensatz zu Amt-MSN, wo es praktisch nur eine zeitgleich ist). Das läßt manche Geräte das Handtuch werfen.
Vermittlungsproblematik: Was aber nun eben auch Lancom betrifft: es scheint so zu sein, daß man ein Gespräch nicht "hochvermitteln" kann an eine übergeordnete Anlage. Auch hier kommt möglicherweise zum Tragen, daß eine "MSN" am internen S0 eine Tln-Nummer ist, womit pro MSN auch nur 1 B-Kanal belegt werden kann. Daher kann beim Vermitteln kein 2. B-Kanal belegt werden, sondern das Gespräch müßte in der ÜBERGEORDNETEN Anlage gehalten werden. Da jede Box aber denkt, selbst am Amt zu hängen, will sie das Gespräch intern halten und für die Rückfrage einen 2. B-Kanal mit derselben MSN belegen. Das geht aber nicht, daher endet der Vermittlungsversuch leider hier
Oder es gibt hier im Forum gute Tips, wie man das Verhalten so programmieren kann
zu erwartende Firmware-Verbesserungen: Ja, leider bekomme ich das schon mit, daß der Telefonieteil das Stiefkind zu sein scheint. Allerdings wundert es mich - gerade jetzt, wo das Thema (leider!) auch zwanghaft von manchen Providern forciert wird, und nicht jeder eine Consumerkiste aus Berlin haben will (ich übrigens auch nicht...) - ganz abgesehen vom Business-Bereich, in dem meines Erachtens die Consumerkisten eh nix verloren haben und ich froh bin, daß es auch noch reine xDSL-Modems ohne Schnickschnack gibt, wenn man z.B. einen Rechner als Gateway hat. Aber das geht jetzt vom Thema ab...
QoS: Doch, hier kann ich nach harter Einarbeitung sagen, das sauber Ende-zu-Ende umgesetzt zu haben - ich beschäftige mich (ernsthaft, nicht ironisch) gerne sehr detailliert mit Netzwerktechnik. Ich finde es nur abstrus, wie oft die Begriffe verwechselt werden oder Halbwissen - auch bei Geräteherstellern - vorhanden ist.
Auf Layer 3 priorisiere ich RTP mit dem ToS-kompatiblen DSCP-Wert "Class Selector 6" und SIP mit dem ToS-kompatiblen DSCP-Wert "Class Selector 5". Dies machen alle Geräte sendend, Lancom und SIP-Telefon - beide erlauben zum Glück die Einstellung
Dies mache ich deswegen so, da die APs immer noch an ToS und nicht an DSCP angelehnt sind und mit "Expedited Forwarding", was oft in SIP-Geräten vorgewählt ist, eine Luftschnittstellen-Priorisierung von AC_VI(deo) statt AC_VO(ice) gemäß WMM vornehmen würden.
Um auf 802.1q-getaggten Strecken noch die Information parallel passend zu haben (und switch-intern die passende Queue zu bekommen), habe ich auf den Managed-Switchen noch ein Rewrite der Priorisierung von Layer 3 nach Layer 2 (802.1p) auf alle eingehenden Pakete eingerichtet.
Hier zur Bestätigung ein kleiner Auszug aus dem Telefon-Syslog von meinem Testanruf:
Code: Alles auswählen
2013-07-06 23:09:46.364,500 - Outgoing call
2013-07-06 23:09:46.514,500 - Setting WLAN power mode: active
2013-07-06 23:09:53.984,125 - Voice Rx IP DSCP: 0x30 UP: 6
2013-07-06 23:09:53.984,875 - Voice Tx IP DSCP: 0x30 UP: 6
2013-07-06 23:09:53.987,125 - Setting WLAN power mode: long doze
2013-07-06 23:09:53.993,875 - Call start - AP: 14:d6:4d:d0:13:d3 - RSSI: -53 - Codec: G711ABesten Dank und schöne Grüße,
Hans-Jürgen
Nachtrag: bezüglich der FLASH-Zeit am Analog-Tln. hatte sich tatsächlich was am Telefon verstellt, oder das Handbuch hat einen Fehler. Ich habe auf die andere (im Handbuch als "lang" bezeichnete) Flash-Zeit gestellt, und nun habe ich am Analog-Telefon dasselbe logische Verhalten wie am SIP-Gerät: Halten und wieder zurückholen geht, Vermitteln läuft ins Leere.
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hallo Hans-Jürgen,
Viele Grüße,
Jirka
Wie ich bereits schrieb, gibt es in diese Richtung eigentlich gar keinen Puffer. Was ich mir vorstellen könnte ist, dass die RTP-Sprachpakete das LANCOM nicht zuverlässig gleichmäßig verlassen (Jitter; oder/und mit Delay) und so zu einer eher hohen Puffer-Einstellung im SIP-Endgerät (IP-Telefon) führen. Das kann man aber nur mit einem Wireshark-Trace hinter dem LANCOM analysieren (einen Switch-Port im LANCOM auf Monitoring, oder an entsprechender Switch dahinter; ISDN- und IP-Telefon nebeneinander auf dem Tisch und dann eine Signalquelle, die alle ca. 5 Sekunden einen kurzen Piepton abgibt; Gespräch von Anfang (=Aufbau) bis Ende (=Abbau) in Wireshark aufzeichnen, dann ist die Identifizierung des RTP-Streams leichter; am Ende sieht man am Bildschirm schön die Kurven (Piepton von SIP->ISDN und ISDN->SIP) und kann das Delay dazwischen bestimmen; ebenso kann man den Jitter-Buffer manuell "einstellen" und dann schön sehen, wie sich die Paketverluste erhöhen würden; an der Stelle sieht man dann auch schön zusammen mit sonstigen statistischen Auswertungen, ob da Pakete unregelmäßig das LANCOM verlassen).hjm82 hat geschrieben:von ISDN-Tln zum SIP-Tln: bei Gesprächsbeginn ca. 90 ms, statisch (nach jetzt 9 min. Testgespräch) dann ca. 50 ms (eine gewisse Auto-Adaption des Puffers ist, insbesondere frisch nach einem Neustart, immer erkennbar, aber sie ist sehr langsam - in der zweiten Minute des Testgesprächs war die Latenz noch bei ca. 70 ms).
Das ist schlecht. Vielleicht tut es ja auch ein SIP-Client auf einem PC (der natürlich schnurgebunden mit dem LAN verbunden sein sollte).hjm82 hat geschrieben:Telefontechnisch habe ich leider derzeit keine kabelgebundene Alternative eines IP-Geräts, da das WLAN bei mir der primäre Anwendungsfall war und das "Herumschlagen" mit IP-Telefonie ausgelöst hat
Keine Ahnung, was das sein könnte. Ich würde da einfach mal die CPU-Last und den freien RAM beobachten und schauen, ob es da irgendwelche negativen Entwicklungen gibt (Speicherfresser o. ä.).hjm82 hat geschrieben:wenn nicht dieser selbsttätige und bis zum Reboot bleibende "Rückfall" in die extralange Latenz immer wieder auftreten würde.
Obwohl seit 2010 im VoIP-Bereich praktisch kaum was passiert ist, bin ich auch erst mal der Meinung. Ich kann mich an einen derart konkreten Fall im IPPF allerdings jetzt nicht auf Anhieb erinnern und habe auch auf die Schnelle nichts gefunden.hjm82 hat geschrieben:ich erinnere mich auch an Beiträge in einem Forum (hier oder IPPF), wo genau das beschrieben wurde - mehr Echo mit längerem Betrieb. Allerdings war das vor 2010, daher hätte und habe ich das erstmal als nicht maßgeblich für die aktuellen Versionen gehalten.
In dem Fall würde ich es einfach noch mal mit der 8.62 versuchen. Auf meinen VoIP-Geräten läuft auch noch selbige.hjm82 hat geschrieben:Achso, die Firmware: hier habe ich die aktuelle 8.80 drauf (und die 8.82 mit gleichem Ergebnis schon getestet).
Na ja, Du hattest geschrieben, dass Du mit verschiedenen Codecs getestet hattest. Das kann man ja nur, wenn man auf irgendeiner Seite mal den G.711 raus nimmt oder in der Priorität nach unten sortiert... Zur Eingrenzung oder Ursachenfindung ist da ja auch nichts gegen zu sagen, nur wäre das Abschalten von G.711 natürlich keine Lösunghjm82 hat geschrieben:Zu den Codecs: das war wohl ein Mißverständnis mit G.711, aber nicht auf meiner Seite: ich hatte extra geschrieben, die Echokompenstation und nicht einen bestimmten Codec ein- und ausgeschaltet zu haben
Ich glaube zwar, dass es umgekehrt war, also der a-law vor dem µ-law, aber das ist auch schon etwas her.hjm82 hat geschrieben:Ansonsten habe ich alles auf G.711 eingeschränkt, da ich im LAN keine Bandbreite sparen muß. Leider scheint man aber die Reihenfolge der Codecs nicht priorisieren zu können, so daß ich G.711 µ-Law deaktiviert habe, weil der scheinbar (zumindest in der Liste) vor A-Law kommt...
Also da können selbstverständlich mehrere B-Kanäle auch mit derselben MSN belegt werden. Das ist überhaupt kein Problem und kann hier nicht die Ursache sein. (Es sei denn, Du hast z. B. max. abgehende Rufe begrenzt oder ähnliches.)hjm82 hat geschrieben:Vermittlungsproblematik: Was aber nun eben auch Lancom betrifft: es scheint so zu sein, daß man ein Gespräch nicht "hochvermitteln" kann an eine übergeordnete Anlage. Auch hier kommt möglicherweise zum Tragen, daß eine "MSN" am internen S0 eine Tln-Nummer ist, womit pro MSN auch nur 1 B-Kanal belegt werden kann.
Ich vermute, es hängt bei Dir irgendwo dran, die Stelle muss man "nur" findenhjm82 hat geschrieben:Oder es gibt hier im Forum gute Tips, wie man das Verhalten so programmieren kann
Davon findet man nicht viele Leute, erst recht nicht welche, die wirklich konsequent und sauber arbeiten.hjm82 hat geschrieben:QoS: Doch, hier kann ich nach harter Einarbeitung sagen, das sauber Ende-zu-Ende umgesetzt zu haben - ich beschäftige mich (ernsthaft, nicht ironisch) gerne sehr detailliert mit Netzwerktechnik.
Was beim LANCOM passieren würde, hast Du ja sicherlich dem angegebenen Thread entnommen. So wie ich das dann hier interpretiere, hast Du also keine LANCOM-APs (Nachtrag: gerade im Telefon-Syslog gesehen, D-Link). Aber andere, bei denen Du das QoS tatsächlich entsprechend Deinen Anforderungen bis ins WLAN konfigurieren konntest. Wollen wir mal hoffen, dass die APs dann auch so arbeiten, wie sie es Dir suggerieren. Deswegen muss man bei einem Troubleshooting, wie schon geschrieben, diese potentielle Fehlerquelle auch mal ausschalten (und mit einem schnurgebundenen IP-Telefon arbeiten).hjm82 hat geschrieben:Dies mache ich deswegen so, da die APs immer noch an ToS und nicht an DSCP angelehnt sind und mit "Expedited Forwarding", was oft in SIP-Geräten vorgewählt ist, eine Luftschnittstellen-Priorisierung von AC_VI(deo) statt AC_VO(ice) gemäß WMM vornehmen würden.
Ich sehe, Du hast Dir wirklich Gedanken gemacht.hjm82 hat geschrieben:Um auf 802.1q-getaggten Strecken noch die Information parallel passend zu haben (und switch-intern die passende Queue zu bekommen), habe ich auf den Managed-Switchen noch ein Rewrite der Priorisierung von Layer 3 nach Layer 2 (802.1p) auf alle eingehenden Pakete eingerichtet.
Schön.hjm82 hat geschrieben:Nachtrag: bezüglich der FLASH-Zeit am Analog-Tln. hatte sich tatsächlich was am Telefon verstellt, oder das Handbuch hat einen Fehler. Ich habe auf die andere (im Handbuch als "lang" bezeichnete) Flash-Zeit gestellt, und nun habe ich am Analog-Telefon dasselbe logische Verhalten wie am SIP-Gerät: Halten und wieder zurückholen geht, Vermitteln läuft ins Leere.
Viele Grüße,
Jirka
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hallo Jirka,
besten Dank wieder mal für Deine Antwort!
Unregelmäßigkeit der Pakete von Lancom zu Telefon: diese Idee könnte gar nicht so falsch sein - in einer ruhigen Minute (muß mehr als eine sein) werde ich mal die Verzögerung mit dem "Kabelhai" messen. Was ich in der Statistik des Telefons schon ablesen kann, spricht ein wenig dafür:
Voice Statistics
Rx Voice Packet Loss = 0%
Rx Voice Packets = 5044
Tx Voice Packets = 5090
Rx Min Pkt Interarrival time = 0 (ms)
Rx Max Pkt Interarrival time = 100 (ms)
Rx RTP Avg Jitter = 25 (samples)
Bezüglich eines kabelgebundenen Telefons bzw. Software-Clients per Kabel schaue ich mal, ob ich ne Möglichkeit dazu finde, abhängig von den anderen Erkenntnissen.
CPU-Last
Aktuell: 14.16%
Speicher
Gesamt: 25.4 MBytes
Frei: 7.7 MBytes
Andere Berichte über Echos: Habe mir nochmal die Mühe gemacht, die Themen rauszusuchen - die relevanten waren sogar in diesem Forum hier:
http://www.lancom-forum.de/alles-zu-lan ... t2963.html (auf Seite 3 gibt es von "tesme33" etwa in der Mitte einen Kommentar bzgl. Echo und Betriebszeit des Geräts)
http://www.lancom-forum.de/alles-zu-lan ... t6680.html
http://www.lancom-forum.de/alles-zu-lan ... t5078.html
Interessanterweise gehts immer um den Medienübergang SIP <--> ISDN.
Firmwareversionen: Version 8.62 habe ich zwischenzeitlich ausprobiert, identisches Verhalten wie mit 8.8x.
Codecs: Du scheinst auch noch den Gedanken zu haben, daß man die Reihenfolge einstellen kann? Das habe ich in einem Handbuch zu Firmware-Version 8.50 auch noch irgendwo gefunden. Allerdings scheint es weder in 8.62 noch 8.x diese Option (noch) zu geben, oder sie hatte sich nicht auf den VCM, sondern das auf anderen Routern genutzte ALG bezogen. Auch über die Kommandozeile kann ich keine Einstellmöglichkeit für die Codec-Prioritäten finden. Ist zwar für meine Anwendung auch nicht so wichtig, aber es fällt auf.
Vermittlungsproblematik / übergeordnete Anlage: Doch, die Hauptanlage sieht interne MSN fix als Teilnehmernummern und erlaubt nur einen Sprachkanal pro MSN. Bei Kanalbündelung mit einer ISDN-Karte etwa werden zwei MSNs belegt, die in der Dokumentation spezifiziert sind und "quasidynamisch" gewählt werden, wenn keine abgehenden MSNs gesetzt sind. Grundsätzlich ist das logisch, da die Anlage ja wissen muß, ob ein Tln belegt ist.
Internes Vermitteln an andere "Lancom-Teilnehmer" funktioniert übrigens fehlerfrei, sowohl von einem SIP- wie auch einem Analogapparat (Anwahl der direkten Tln. per Stern vorweg).
Was ich mir mittlerweile vorstellen könnte: die Anlage hat noch mindestens einen weiteren Amtport frei. Ich könnte aus dem freien ISDN2-Port des Lancom im NT-Modus in das freie Amt der Anlage und alle internen Rufnummern / Sammelrufe als MSN passend in das Routing einbeziehen. Wäre dann zwar eine interessante Schleife, aber könnte zumindest theoretisch einen Versuch wert sein.
QoS: Hier habe ich sowohl per Wireshark geprüft, daß am AP in beide Richtungen die Priorisierungen stimmen, und zudem habe ich mir die Mappingtabelle von DSCP/ToS zu den WMM-Kategorien vom Hersteller bestätigen lassen. Man hält sich an den WIFI-Alliance-Vorschlag, nach den ToS-Werten (Class / UP 0 bis 7) zu mappen und die Layer 3-Info zu bevorzugen. Als Brachialmethode kann man sogar noch SSID-bezogen in beide Richtungen einen Class Selector erzwingen, der dann aber global und unabhängig von den Daten gilt.
Besten Dank und schöne Grüße,
Hans-Jürgen
besten Dank wieder mal für Deine Antwort!
Unregelmäßigkeit der Pakete von Lancom zu Telefon: diese Idee könnte gar nicht so falsch sein - in einer ruhigen Minute (muß mehr als eine sein) werde ich mal die Verzögerung mit dem "Kabelhai" messen. Was ich in der Statistik des Telefons schon ablesen kann, spricht ein wenig dafür:
Voice Statistics
Rx Voice Packet Loss = 0%
Rx Voice Packets = 5044
Tx Voice Packets = 5090
Rx Min Pkt Interarrival time = 0 (ms)
Rx Max Pkt Interarrival time = 100 (ms)
Rx RTP Avg Jitter = 25 (samples)
Bezüglich eines kabelgebundenen Telefons bzw. Software-Clients per Kabel schaue ich mal, ob ich ne Möglichkeit dazu finde, abhängig von den anderen Erkenntnissen.
Hier war bisher nichts auffällig, aber ich werde es prüfen und mal eine Weile nicht neustarte. Typische Werte während eines Gespräches sind (innerhalb des ersten Tages nach Neustart) :Jirka hat geschrieben:Keine Ahnung, was das sein könnte. Ich würde da einfach mal die CPU-Last und den freien RAM beobachten und schauen, ob es da irgendwelche negativen Entwicklungen gibt (Speicherfresser o. ä.).
CPU-Last
Aktuell: 14.16%
Speicher
Gesamt: 25.4 MBytes
Frei: 7.7 MBytes
Andere Berichte über Echos: Habe mir nochmal die Mühe gemacht, die Themen rauszusuchen - die relevanten waren sogar in diesem Forum hier:
http://www.lancom-forum.de/alles-zu-lan ... t2963.html (auf Seite 3 gibt es von "tesme33" etwa in der Mitte einen Kommentar bzgl. Echo und Betriebszeit des Geräts)
http://www.lancom-forum.de/alles-zu-lan ... t6680.html
http://www.lancom-forum.de/alles-zu-lan ... t5078.html
Interessanterweise gehts immer um den Medienübergang SIP <--> ISDN.
Firmwareversionen: Version 8.62 habe ich zwischenzeitlich ausprobiert, identisches Verhalten wie mit 8.8x.
Codecs: Du scheinst auch noch den Gedanken zu haben, daß man die Reihenfolge einstellen kann? Das habe ich in einem Handbuch zu Firmware-Version 8.50 auch noch irgendwo gefunden. Allerdings scheint es weder in 8.62 noch 8.x diese Option (noch) zu geben, oder sie hatte sich nicht auf den VCM, sondern das auf anderen Routern genutzte ALG bezogen. Auch über die Kommandozeile kann ich keine Einstellmöglichkeit für die Codec-Prioritäten finden. Ist zwar für meine Anwendung auch nicht so wichtig, aber es fällt auf.
Vermittlungsproblematik / übergeordnete Anlage: Doch, die Hauptanlage sieht interne MSN fix als Teilnehmernummern und erlaubt nur einen Sprachkanal pro MSN. Bei Kanalbündelung mit einer ISDN-Karte etwa werden zwei MSNs belegt, die in der Dokumentation spezifiziert sind und "quasidynamisch" gewählt werden, wenn keine abgehenden MSNs gesetzt sind. Grundsätzlich ist das logisch, da die Anlage ja wissen muß, ob ein Tln belegt ist.
Internes Vermitteln an andere "Lancom-Teilnehmer" funktioniert übrigens fehlerfrei, sowohl von einem SIP- wie auch einem Analogapparat (Anwahl der direkten Tln. per Stern vorweg).
Was ich mir mittlerweile vorstellen könnte: die Anlage hat noch mindestens einen weiteren Amtport frei. Ich könnte aus dem freien ISDN2-Port des Lancom im NT-Modus in das freie Amt der Anlage und alle internen Rufnummern / Sammelrufe als MSN passend in das Routing einbeziehen. Wäre dann zwar eine interessante Schleife, aber könnte zumindest theoretisch einen Versuch wert sein.
QoS: Hier habe ich sowohl per Wireshark geprüft, daß am AP in beide Richtungen die Priorisierungen stimmen, und zudem habe ich mir die Mappingtabelle von DSCP/ToS zu den WMM-Kategorien vom Hersteller bestätigen lassen. Man hält sich an den WIFI-Alliance-Vorschlag, nach den ToS-Werten (Class / UP 0 bis 7) zu mappen und die Layer 3-Info zu bevorzugen. Als Brachialmethode kann man sogar noch SSID-bezogen in beide Richtungen einen Class Selector erzwingen, der dann aber global und unabhängig von den Daten gilt.
Besten Dank und schöne Grüße,
Hans-Jürgen
Re: 1723 als ISDN - SIP-Gateway - Latenzverhalten, Vermittel
Hatte ich doch recht gehabthjm82 hat geschrieben:Nachtrag: bezüglich der FLASH-Zeit am Analog-Tln. hatte sich tatsächlich was am Telefon verstellt, oder das Handbuch hat einen Fehler. Ich habe auf die andere (im Handbuch als "lang" bezeichnete) Flash-Zeit gestellt, und nun habe ich am Analog-Telefon dasselbe logische Verhalten wie am SIP-Gerät: Halten und wieder zurückholen geht, Vermitteln läuft ins Leere.
schön, dass es nun klappt.Grüße
Cpuprofi