• Der Fragesteller hat diesen Beitrag als gelöst markiert.
  • Geschlossen

local Sip vs „externe“ Sip

RAL9004
Level 5
21 von 31

@Bergler

Guten Morgen Berger

Wir leben auf dem Planeten Erde im Jahre 2017 des Herrn   🙂

 

Du hast mit Deinem Dienstleister Swisscom einen Vertrag abgeschlossen. Die Details des Vertrages sind in den AGB geregelt. Wenn Dein "Use Case" in den AGB abgedeckt ist, dann wird Swisscom Deine Installationsvariante supporten. D.h. Du solltest bei einer allfälligen Neuevalation Deines ISP Deinen "Use Case" vertragstechnisch abdecken lassen.

 

Jeder der ein eigenes Gschäft hat bzw. Budgetverantwortung hat, kennt das. Man muss die Aufwände / Kosten einschätzen, danach den Preis festlegen.

 

Einige Nutzer haben sich in diesem Thread wiederholt Zeit genommen, Dir zu helfen. Du bist nicht willens gemeinsam mit den Helfern den Weg zu einer Lösung zu gehen. Stattdessen stellst Du Behauptungen auf, erhebst Ansprüche und reagierst emotional. IMO: nicht zielführend - rational betrachtet...

 

Schöne Woche

RAL9004

 

* Dunning-Kruger Effekt * wurde mit der digitalen Kommunikation zur Pest der Neuzeit...*
############################################################################
* Dunning-Kruger Effekt * wurde mit der digitalen Kommunikation zur Pest der Neuzeit...*
############################################################################
Bergler
Level 5
22 von 31

@RAL9004

 

Offenbar ist Dir entgangen, dass ich bereits eine funktionierende Lösung gefunden habe.

Unsere Telefonanlage läuft seit Mitte August 2017 und somit ist das Thema für mich erledigt.

NotNormal
Level 4
23 von 31

Hi

 

Bevor das hier zum Religionskrieg ausartet: Es gibt schon einen Unterschied im Protokoll bezüglich interner/externer Credentials.

 

Bei Internen Credentials gibt es 2 SIP-Verbindungen: 1. vom Telefon zu Box und 2. von der Box zum Swiscsom-Netz.

 

Bei den externen Credentials fällt Punkt 1 weg und es gibt nur eine Verbindung vom Telefon direkt ins Netz.

 

Möglicherweise (warsscheinlich) sind dabei auf Swisscom-Seite auch verschiedene Gegenstellen und interne Netzwerke im Einsatz. Einflüsse, auch auf die Sprachqualität, sind also durchaus möglich...

 

N.B. ein RFC ist kein physikalisches Gesetz. Es kommt darum auch in der Praxis vor, das zwei Geräte überhaupt nicht miteinander funktionieren, auch wenn beide SIP nach RFC xy implementiert haben.

Theorie und Praxis halt 🙂

 

Grüsse

 

NotNormal

RAL9004
Level 5
24 von 31

Hallo NotNormal

 

Niemand hat geschrieben, dass RFC ein physikalisch Gesetz seien  😉

Der Benutzer Hed hat die Basis RFC auch bereits benannt und auf die ergänzenden Gesetzwerke hingewiesen  8-)

 

HED ist definitv tiefer als ich in der VOIP Materie. IMO: machst Du exakt den gleichen Denkfehler, wie der Threadanstosser. Die Sprachqualität definiert sich über Codec, Protokolle, Leitungsqualität, etc. und mit keinem einzigen Aspekt mit der Anmeldung. Vergleichbar mit einem Webservice: ob Du Dich mit Deinem Facebook Account oder mit eigenen Anmeldedaten anmeldest, hat an der Qualität der Applikation keinen Einfluss. Oder wenn Du auf einem Betriebssystem eine MKV abspielst, dann ist die Anmeldung am Client kein Faktor. Sondern die im MKV Container liegen Formate, die Unterstützung durch die zum abspielen gewählte Applikation.

 

Die Authentifizierung des Clients kann in der Konfiguration mit Parametern wie Codec Definition verbunden sein. Wie HED auch sehr ausführlich beschrieben hat, gleichen sie die zwei Komponenten (Server / Client) ab, was die Gegenseite versteht. Das sind indirekte Faktoren. D.h. der Engineer / Entwickler der das Gerät (Firmware) designed hat, hat diese Abhängigkeit geschaffen.

 

Ich habe in diesem Thread einiges neues über VOIP gelesen und kann leider nicht im mindesten nachvollziehen, warum das für Dritte so schwer zu verstehen ist.

 

Schönen Abend

RAL9004

* Dunning-Kruger Effekt * wurde mit der digitalen Kommunikation zur Pest der Neuzeit...*
############################################################################
* Dunning-Kruger Effekt * wurde mit der digitalen Kommunikation zur Pest der Neuzeit...*
############################################################################
NotNormal
Level 4
25 von 31
Hi @RAL9004

Ich bin durchaus mit SIP-Protokollen vertraut, auch wenn ich versuche, mich hier allgemeinverständlich auszudrücken 🙂 Ich vermute eher, du unterschätzt die Komplexität etwas.

Das der unterschiedliche SIP-Server einen Einfluss auf die Sprachqualität haben kann, ist sicher kein Denkfehler.
Du kannst es dir wie zwei völlig Getrennte Systeme vorstellen. Also andere Hardware, andere Software anderes Netzwerk. Das eine läuft halt zufällig gerade besser als das andere. Nach deiner Theorie dürfte es auch keinen Unterschied zwischen verschiedenen Providern geben, es sind ja immer die gleichen RFC's...

Gegenfrage: An was liegt den in diesem Fall die unterschiedliche Qualität, deiner Meinung nach?

Verglichen mit Webservices: Auf meinen Smartphone mit immer den gleichen Einstellungen läuft Youtube mal und mal auch nicht. Login. Protokolle, usw. alles Identisch. Das dürfte nach deiner Definition nicht möglich sein...
Nach meiner könnte es einfach am Netz liegen 😉

Grüsse

NotNormal
RAL9004
Level 5
26 von 31

@NotNormal

Analog der Frage von Bergler wähle ich den empirischen Ansatz.

Als Beispiel wie man epirisch vorgeht, habe ich bereits in einer Antwort vorhergend beantwortet

 

Zum 1001 mal: Meinungen / Eindrücke / etc. sind für Techniker / Wissenschaftler nicht relevant

Bequemt Euch dazu, dass Ihr Faken vorweisen könnt. Ich bin es langsam leid, über Meinungen und Ansprüche zu diskutieren. Analog den meisten Teilnehmer im Forum, will ich ohne Bezahlung andern Benutzern weiter helfen.

 

Diese Diskussion - wie Du selbst bereits geschrieben hast - geht in eine reliöse Grundsatz Debatte. Dafür bin ich nicht zu haben. Ich habe mir Zeit genommen er beschreiben, wie man zu solchen empirischen Aussgen gelant. Wenn Du bzw. weitere Teilnehmer politisch / religös argumentiert, anstatt akribische Tests und deren Resulate zu diskutieren, ist mir dafür die Zeit zu schade...

 

Grüsse

RAL 9004

* Dunning-Kruger Effekt * wurde mit der digitalen Kommunikation zur Pest der Neuzeit...*
############################################################################
* Dunning-Kruger Effekt * wurde mit der digitalen Kommunikation zur Pest der Neuzeit...*
############################################################################
hed
Level 7
Level 7
27 von 31

@Bergler schrieb:

@RAL9004@hed

 

HALLO?? Auf welchem Planeten lebt ihr denn eigentlich? Seit wann muss der Kunde beweisen, dass die gelieferte Hardware nicht zuverlässig läuft?

 

Zuerst wird man von der Swisscom gedrängt, von der stabilen ISDN-Telefonie auf "Swisscom-VoiP" zu wechseln. Dann stellt man fest, dass die Anlage mit der von der Swisscom-Hotline vorgeschlagenen Konfiguration (interne Credentials verwenden!) nicht zuverlässig läuft. Und nun soll man gefälligst noch beweisen, dass es nicht zuverlässig läuft...sonst gehts aber noch ???

 

Ach übrigens...warum melde ich denn die DECT-Handgeräte nicht gefälligst, wie von der Swisscom-Hotline vorgeschlagen, direkt am Centro Business 2.0 an? Ganz einfach, der Router befindet sich im Keller und die DECT-Abdeckung aus dem Keller reicht nicht aus, um das ganze Haus abzudecken. Gibt's denn von Swisscom einen DECT-Repeater für den Centro Business 2.0, um die Abdeckung zu erweitern? Fehlanzeige.

Aus diesem Grund habe ich ein Netzwerkkabel in den 2. Stock verlegt, wo nun die Gigaset-Basis GO BOX 100 läuft und das ganze Haus gut abdeckt. 

 

Ich habe somit eine Lösung gefunden. Mit den externen Credentials und einem neuen Router läuft die Anlage und damit ist für mich das Thema erledigt.

 

Meine Absicht war, meine Erfahrung hier im Forum mitzuteilen, damit anderen Leuten, welche vielleicht auch Probleme mit der "Swisscom-VoiP-Telefonie" bekunden, eine mögliche Lösung aufgezeigt wird.


@Bergler

 

Es geht nicht darum, dass du beweisen musst, dass die gelieferte Hardware nicht zuverlässig läuft.

 

Es geht lediglich um die hier im Forum geführte Fachdiskussion. Du hast Aussagen gemacht und @RAL9004 und ich haben anderst lautende Aussagen gemacht.

 

Falls es nun nicht bei den theoretischen Aussagen bleiben soll und du daran interesiert bist was wirklich richtig ist und wie die Technik in der Praxis funktioniert, so kommst du nicht darum herum, mir Traces zur Auswertung zu liefern. 

 

Wenn es dich nicht weiter interessiert auch gut, dann kannst du diesen Thread als erledigt schliessen.   

Editiert
hed
Level 7
Level 7
28 von 31

@NotNormal schrieb:

Hi

 

Bevor das hier zum Religionskrieg ausartet: Es gibt schon einen Unterschied im Protokoll bezüglich interner/externer Credentials.

 

Bei Internen Credentials gibt es 2 SIP-Verbindungen: 1. vom Telefon zu Box und 2. von der Box zum Swiscsom-Netz.

 

Bei den externen Credentials fällt Punkt 1 weg und es gibt nur eine Verbindung vom Telefon direkt ins Netz.

 

Möglicherweise (warsscheinlich) sind dabei auf Swisscom-Seite auch verschiedene Gegenstellen und interne Netzwerke im Einsatz. Einflüsse, auch auf die Sprachqualität, sind also durchaus möglich...

 

N.B. ein RFC ist kein physikalisches Gesetz. Es kommt darum auch in der Praxis vor, das zwei Geräte überhaupt nicht miteinander funktionieren, auch wenn beide SIP nach RFC xy implementiert haben.

Theorie und Praxis halt 🙂

 

Grüsse

 

NotNormal


@NotNormal

 

Die Anzahl der SIP-Verbindungen hat auf die Sprachqualität keinen Einfluss.

 

Dass Unterschiedliche GW (=Endstellen) beim Provider einen Einfluss haben können habe ich ja erwähnt. Und um das zu sehen, braucht es aber Wireshark-Aufzeichnungen zur Analyse, sonst ist es nur stochern im Nebel.

 

Nein RFC ist kein physikalisches Gesetz sondern ein Regelwerk über technische Protokolle und Methoden. Dabei sind es keine Gesetze, nur Empfehlungen. In diesen RFC gibt es sehr viele Freiheitsgrade d.h. es ist sehr wohl möglich, dass sich zwei Geräte nicht verbinden können, obwohl beide nach der selben RFC gebaut sind. Aber selbst das kann man dann wieder an Hand der RFC erklären. 

 

Dazu nur ein Beispiel:

- Gerät A unterstützt Codec 1, 2 und 3 (aus einer langen Liste möglicher Codec)
- Gerät B unterstützt Codec 4, 5 und 6 (aus der selben langen Liste möglicher Codec)

Diese beiden Geräte werden nicht miteinander kommunizieren können. Und genau dafür braucht es auch wieder das in den RFC beschriebene SIP um die Diskrepanz zwischen beiden Geräten zu detektieren und zu regeln, was in einem solchen Fall passieren soll, z.B. eine entsprechende Fehlermeldung im SIP zu senden.

 

Dank den RFC lassen sich auch die in der Praxis nicht funktionierenden Fälle erklären. Aber dazu braucht man auch die Traces. Diese Traces mit Daten aus der Praxis vergleicht man dann mit der Theorie (RFC) um dem Problem auf die Spur zu kommen.

 

Editiert
hed
Level 7
Level 7
29 von 31

...

Gegenfrage: An was liegt den in diesem Fall die unterschiedliche Qualität, deiner Meinung nach?
....

@NotNormal

 

Wenn du mir die Traces von beiden Fällen lieferst, so kann ich versuchen, deine Frage zu beantworten. Ohne solche Traces bleibt alles nur Spekulation.

hed
Level 7
Level 7
30 von 31

@Bergler schrieb:

@RAL9004

 

Offenbar ist Dir entgangen, dass ich bereits eine funktionierende Lösung gefunden habe.

Unsere Telefonanlage läuft seit Mitte August 2017 und somit ist das Thema für mich erledigt.


@Bergler

 

Die Diskussion ging ja nicht darum ob es nun funktioniert oder nicht sondern um hinter die Kulissen von VoIP zu schauen und die bisher gemachten theoretischen Ausssagen und Behauptungen mit praktischen Messungen zu belegen.

 

mat1
Level 1
31 von 31

and Bergler, you are right.

Have found exactly the same frustrating behavior. And no usable help.

 

Works well with external SIP credentials and crappy unstable behavior with local SIP (no ring, sudenly impossible to pass/receive calls, usw).

 

I noticed further than when logging into the router, an internal check seems to run and detect the problem. Then it works again (of course nobody wants to log into the router every 5minutes).

 

Using e.g. W52P or T48S from Yealink. That is pretty unbelievable actually. Good luck with going soon all IP.

 

Nach oben