VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Hier können sich alle gegenseitig bei Fragen mit eigenen Endgeräten helfen. Eine Unterstützung durch das Supportteam gibt es hier nicht.

Moderatoren: Yusuf, Florian S., Sven

PeterP
Junior - Member
Junior - Member
Beiträge: 26
Registriert: 22.05.2011, 20:19

VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon PeterP » 01.11.2017, 15:36

Wie in VoIP: Gründe für SIP 403 (forbidden) Fehler? beschrieben werden Registrierungsversuche meines VoIP-Phones mit SIP 403 abgelehnt.

Nach einigen Experimenten mit Ncat ist auch klar warum:

URLs mit [2001:a60:1:7::10] werden abgelehnt, obwohl

Code: Alles auswählen

# host phone.mnet-voip.de
phone.mnet-voip.de has address 80.81.4.116
phone.mnet-voip.de has IPv6 address 2001:a60:1:7::10

gilt und dasselbe Format für 'Via' und 'Contact' Felder akzeptiert wird.

Ursache für mein Problem könnte eine nicht ganz RFC3261 konforme SIP Implementierung von Mnet sein (lt. Kapitel 25.1 kann ein 'host' überall auch eine 'IPv6reference' sein).

Eine andere Möglichkeit sehe ich noch hier:

Code: Alles auswählen

# host 2001:a60:1:7::10
Host 0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.0.0.0.1.0.0.0.0.6.a.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)


[Edit] 2017-11-04: Titel schärfer formuliert, Verweis auf Kap. 25.1 in RFC3261

Benutzeravatar
Florian S.
Admin
Admin
Beiträge: 2546
Registriert: 18.06.2014, 21:12

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon Florian S. » 06.11.2017, 11:39

Hallo PeterP,

ich habe den Post in den korrekten bereich verschoben. Bei Messung Deines Anschlusses stellte ich fest, dass die VoIP Verbindung hier einmal mit IPv6 durch die FritzBox aufgebaut wird was auch korrekt ist. Allerdings wird auch ein weiterer Versuch via IPv4 durchgeführt was nicht funktionieren kann. Bitte hab Verständnis, dass wir darauf keinen Support geben können.
Viele Grüße

Florian Schmeilzl
M-net Support

PeterP
Junior - Member
Junior - Member
Beiträge: 26
Registriert: 22.05.2011, 20:19

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon PeterP » 06.11.2017, 20:51

Hallo Herr Schmeilzl,

Florian S. hat geschrieben:ich habe den Post in den korrekten bereich verschoben.


Damit bin ich überhaupt nicht einverstanden. Wie schon der geänderte Titel sagt liegt hier eindeutig ein Mnet Problem vor, das unabhängig von meinem Endgerät ist.

Bei Messung Deines Anschlusses stellte ich fest, dass die VoIP Verbindung hier einmal mit IPv6 durch die FritzBox aufgebaut wird was auch korrekt ist. Allerdings wird auch ein weiterer Versuch via IPv4 durchgeführt was nicht funktionieren kann. Bitte hab Verständnis, dass wir darauf keinen Support geben können.


Wann haben Sie denn gemessen? Falls das zwischen Samstag und heute war, dann war es nicht mein Endgerät, in der Zeit hing nur die Mnet-Fritzbox + mein Analogtelefon am Netz.

Ich habe mir die Mühe gemacht alles nochmal zu wiederholen und sauber mitzuprotokollieren:

2017-11-06 19:11: Abstecken der Mnet-FB, Anstecken meines Modems+Routers
19:17 SIP-Phone mit Strom versorgt. ==> Wireshark zeigt 2 REGISTER-Versuche über IPv6, die mit Forbidden abgelehnt werden
19:19 SIP-Phone abgesteckt
19:38 Befehl 'ncat -6 phone.mnet-voip.de 5060 < literal.txt' abgesetzt, keine Antwort, da nicht über UDP gesendet.
19:41 Befehl 'ncat -6 -u phone.mnet-voip.de 5060 < literal.txt' abgesetzt, Antwort 403 Forbidden
19:43 Befehl 'ncat -6 -u phone.mnet-voip.de 5060 < fqdn.txt' abgesetzt, Antwort 401 Unautorized

Die einzigen IPv4 SIP Anfragen kommen aus dem Internet an meinen Router. Offensichtlich ist hier ein Scanner auf ungeschützte SIP-Ports am Werke.

Auf Anfrage kann ich Ihnen eine Wireshark-Capture-Datei für den Zeitraum des Versuchs zukommen lassen.

ncat ist ein Programm, mit dem man den Inhalt einer Datei an einen Internetserver schicken kann.
'ncat -6 -u' bedeutet 'Sende über IPv6, Protokoll UDP'
Hier die Dateien als Text (Dateianhänge geht nicht, ich kriege immer 'Ungültige Dateierweiterung):
literal.txt (Telefonnummer wurde ersetzt):

Code: Alles auswählen

REGISTER sip:[2001:a60:1:7::10]:5060 SIP/2.0
Via: SIP/2.0/UDP [2001:a61:1109:6a00:d083:9dc7:9f8f:1269]:5060;branch=z9hG4bK2881830151
From: <sip:+498947110815@[2001:a60:1:7::10]:5060>;tag=1379401210
To: <sip:+498947110815@[2001:a60:1:7::10]:5060>
Call-ID: 0_4290761892@2001:a61:1109:6a00:d083:9dc7:9f8f:1269
CSeq: 3 REGISTER
Contact: <sip:+498947110815@[2001:a61:1109:6a00:d083:9dc7:9f8f:1269]:5060>
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink W52P 25.81.0.10
Expires: 3600
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 0



fqdn.txt:

Code: Alles auswählen

REGISTER sip:phone.mnet-voip.de:5060 SIP/2.0
Via: SIP/2.0/UDP [2001:a61:1109:6a00:d083:9dc7:9f8f:1269]:5060;branch=z9hG4bK2881830151
From: <sip:+498947110815@phone.mnet-voip.de:5060>;tag=1379401210
To: <sip:+498947110815@phone.mnet-voip.de:5060>
Call-ID: 0_4290761892@2001:a61:1109:6a00:d083:9dc7:9f8f:1269
CSeq: 3 REGISTER
Contact: <sip:+498947110815@[2001:a61:1109:6a00:d083:9dc7:9f8f:1269]:5060>
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink W52P 25.81.0.10
Expires: 3600
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 0



Der einzige Unterschied zwischen den Dateien besteht darin, dass in fqdh.txt der Text '[2001:a60:1:7::10]' durch 'phone.mnet-voip.de' ersetzt wurde.

Anhand der Reaktionen des Servers (403 vs. 401) erkennt man, dass der Server literale IPv6 Adressen nur im Via-Feld akzeptiert, nicht aber in einem der REGISTER-, To- oder From-Felder. Dies ist ein klarer Verstoß gegen Rfc3261.

Damit ist eine in der Leistungsbeschreibung/Schnittstellenbeschreibung versprochene Eigenschaft nur unvollständig erbracht. Außerdem wird mein standardkonformes Endgerät diskriminiert, was nach dem Gesetz zur Auswahl und zum Anschluss von Telekommunikationsgeräten verboten ist.


Mit freundlichen Grüßen,

Peter Pöschl

DarkSider
Senior - Member
Senior - Member
Beiträge: 510
Registriert: 25.06.2008, 09:28
Wohnort: München

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon DarkSider » 07.11.2017, 00:15

Hallo Peter,

PeterP hat geschrieben:Der einzige Unterschied zwischen den Dateien besteht darin, dass in fqdh.txt der Text '[2001:a60:1:7::10]' durch 'phone.mnet-voip.de' ersetzt wurde.

Anhand der Reaktionen des Servers (403 vs. 401) erkennt man, dass der Server literale IPv6 Adressen nur im Via-Feld akzeptiert, nicht aber in einem der REGISTER-, To- oder From-Felder. Dies ist ein klarer Verstoß gegen Rfc3261.

Damit ist eine in der Leistungsbeschreibung/Schnittstellenbeschreibung versprochene Eigenschaft nur unvollständig erbracht. Außerdem wird mein standardkonformes Endgerät diskriminiert, was nach dem Gesetz zur Auswahl und zum Anschluss von Telekommunikationsgeräten verboten ist.


Ich habe mir grad mal die von Dir zitierte RFC3261 angesehen (https://www.ietf.org/rfc/rfc3261.txt) und entsprechend unten abgedruckt. Ich kann die von Dir aufgestellte Behauptung nicht nachvollziehen, dass das Feld Header-URI auch eine IP-Adresse enthalten kann. Tatsächlich widerspricht das ja schon dem Namen des Feldes: Request-URI. Tatsächlich muss der Server laut RFC in schritt 5 der Registrierung sogar die Adresse aus dem TO-Feld gegen die Register URI Prüfen und bei einem Mismatch ablehnen. Gerne kannst Du mir aber die RFC-Stellen zitieren die eine IP als URI zulassen.


Code: Alles auswählen

10.2 Constructing the REGISTER Request

   REGISTER requests add, remove, and query bindings.  A REGISTER
   request can add a new binding between an address-of-record and one or
   more contact addresses.  Registration on behalf of a particular
   address-of-record can be performed by a suitably authorized third
   party.  A client can also remove previous bindings or query to
   determine which bindings are currently in place for an address-of-
   record.

   Except as noted, the construction of the REGISTER request and the
   behavior of clients sending a REGISTER request is identical to the
   general UAC behavior described in Section 8.1 and Section 17.1.

   A REGISTER request does not establish a dialog.  A UAC MAY include a
   Route header field in a REGISTER request based on a pre-existing
   route set as described in Section 8.1.  The Record-Route header field
   has no meaning in REGISTER requests or responses, and MUST be ignored
   if present.  In particular, the UAC MUST NOT create a new route set
   based on the presence or absence of a Record-Route header field in
   any response to a REGISTER request.

   The following header fields, except Contact, MUST be included in a
   REGISTER request.  A Contact header field MAY be included:

      Request-URI: The Request-URI names the domain of the location
           service for which the registration is meant (for example,
           "sip:chicago.com").  The "userinfo" and "@" components of the
           SIP URI MUST NOT be present.


und

Code: Alles auswählen

 When receiving a REGISTER request, a registrar follows these steps:

      1. The registrar inspects the Request-URI to determine whether it
         has access to bindings for the domain identified in the
         Request-URI.  If not, and if the server also acts as a proxy
         server, the server SHOULD forward the request to the addressed
         domain, following the general behavior for proxying messages
         described in Section 16.

      2. To guarantee that the registrar supports any necessary
         extensions, the registrar MUST process the Require header field
         values as described for UASs in Section 8.2.2.

      3. A registrar SHOULD authenticate the UAC.  Mechanisms for the
         authentication of SIP user agents are described in Section 22.
         Registration behavior in no way overrides the generic
         authentication framework for SIP.  If no authentication
         mechanism is available, the registrar MAY take the From address
         as the asserted identity of the originator of the request.

      4. The registrar SHOULD determine if the authenticated user is
         authorized to modify registrations for this address-of-record.
         For example, a registrar might consult an authorization
         database that maps user names to a list of addresses-of-record
         for which that user has authorization to modify bindings.  If
         the authenticated user is not authorized to modify bindings,
         the registrar MUST return a 403 (Forbidden) and skip the
         remaining steps.

         In architectures that support third-party registration, one
         entity may be responsible for updating the registrations
         associated with multiple addresses-of-record.

      5. The registrar extracts the address-of-record from the To header
         field of the request.  If the address-of-record is not valid
         for the domain in the Request-URI, the registrar MUST send a
         404 (Not Found) response and skip the remaining steps.  The URI
         MUST then be converted to a canonical form.  To do that, all
         URI parameters MUST be removed (including the user-param), and
         any escaped characters MUST be converted to their unescaped
         form.  The result serves as an index into the list of bindings.


viele Grüße,

Fabian
M-Net Surf&Fon-Flat 1.000 - Cluster 600
Hardware:
ONT: Huawei | Router/Firewall: opnSense

PeterP
Junior - Member
Junior - Member
Beiträge: 26
Registriert: 22.05.2011, 20:19

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon PeterP » 07.11.2017, 21:00

Hallo Fabian,

Ich habe mir grad mal die von Dir zitierte RFC3261 angesehen (https://www.ietf.org/rfc/rfc3261.txt) und entsprechend unten abgedruckt. Ich kann die von Dir aufgestellte Behauptung nicht nachvollziehen, dass das Feld Header-URI auch eine IP-Adresse enthalten kann. Tatsächlich widerspricht das ja schon dem Namen des Feldes: Request-URI. Tatsächlich muss der Server laut RFC in schritt 5 der Registrierung sogar die Adresse aus dem TO-Feld gegen die Register URI Prüfen und bei einem Mismatch ablehnen.

Irrelevant, das hat alles nichts damit zu tun wie eine syntaktisch korrekte Botschaft auszusehen hat.

Gerne kannst Du mir aber die RFC-Stellen zitieren die eine IP als URI zulassen.

Mit Vergnügen, der im ersten Posting verwendete Begriff IPv6reference führt schnurstracks und exklusiv zu Kapitel 25, wo authoritativ die Syntax einer gültigen SIP-Message definiert ist.

Code: Alles auswählen

SIP-message = Request / Response
 |
 +- Request = Request-Line
            *( message-header ) CRLF
            [ message-body ]


Beschränken wir uns mal auf die erste Zeile

Code: Alles auswählen

REGISTER sip:[2001:a60:1:7::10]:5060 SIP/2.0
von literal.txt und parsen sie als Request-Line (nicht zutreffende Produktionen habe ich nicht weiter verfolgt, '>>> empty' bezeichnet Produktionen, die leer sein dürfen und es auch sind):

Code: Alles auswählen

Request-Line = Method SP Request-URI SP SIP-Version CRLF
 |
 +- Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm
 |   |     / extension-method
 |   |
 |   +- REGISTERm = "REGISTER"
 |
 +- Request-URI = SIP-URI / SIPS-URI / absoluteURI
 |   |
 |   +- SIP-URI = "sip:" [ userinfo ] hostport uri-parameters
 |       |        [ headers ]
 |       |
 |       +- userinfo >>> empty
 |       |
 |       +- hostport = host [ ":" port ]
 |       |   |
 |       |   +- host = hostname / IPv4address / IPv6reference
 |       |   |   |
 |       |   |   +- IPv6reference = "[" IPv6address "]"
 |       |   |       |
 |       |   |       +- IPv6address = hexpart [ ":" IPv4address ]
 |       |   |           |
 |       |   |           +- hexpart =  hexseq / hexseq "::" [ hexseq ]
 |       |   |               |      / "::" [ hexseq ]
 |       |   |               |
 |       |   |               +- hexseq = hex4 *( ":" hex4)
 |       |   |                   |
 |       |   |                   +- hex4 = 1*4HEXDIG
 |       |   |
 |       |   +- port = 1*DIGIT
 |       |
 |       +- uri-parameters >>> empty
 |       |
 |       +- headers >>> empty
 |
 +- SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT
 


2001:a60:1:7::10 ist also eine IPv6address und damit legal. Bei den From- und To-Zeilen führt die Syntax ebenfalls zu SIP-URI oder SIPS-URI , womit IPv6address auch dort legal ist, Q.E.D.


Viele Grüße,

Peter

DarkSider
Senior - Member
Senior - Member
Beiträge: 510
Registriert: 25.06.2008, 09:28
Wohnort: München

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon DarkSider » 07.11.2017, 23:04

Hallo Peter,

Du hast insofern Recht, als dass die SIP-URI tatsächlich weiter unten auch als IPv6 definiert wird. Diverse Aussagen weiter oben in der RFC wo klar von einem Domain Name die Rede ist, sind dann allerdings sinnfrei bzw. unlogisch - my bad.

Ob sich daraus nun aber ableiten lässt, dass sich M-Net nicht RFC-konform verhält sehe ich leider immer noch nicht.

Du legst die RFC so aus, dass dir clientseitig das RECHT auf ein Register-Kommando mit IPv6-Adresse anstelle FQDN zusteht. Gleichermaßen müsste man dann aber auch schlussfolgern, dass einem ebenfalls das RECHT auf IPv4 Konnektivität zum SIP-Server zusteht da das ja auch in der RFC abgedeckt ist.

Ich lese es so, dass Protokoll theoretisch alle aufgezählten Varianten abdeckt. Wenn M-Net allerdings einen Hostname fordert (dafür gibt es ja auch viele gute Gründe) dann ist dies auch RFC konform. Das Beispiel mag ein wenig hinken, wenn aber ein paar SIP Proxies dazwischen hängen vielleicht auch nicht mehr: 20 domains werden von einem httpd auf einer ip gehostet - hier ist der domain name zwingend erforderlich obwohl die RFC für http auch IP-Adressen abdeckt...

Im Umkehrschluss muss ich sogar ableiten, dass sich dein Telefon insofern nicht RFC-Konform verhält, weil es nicht alle im Protokoll vorgesehenen Möglichkeiten implementiert, denn offenbar kannst Du ja nur einen IP-basierten SIP-Server eintragen oder das Telefon löst die URL in eine Adresse auf und ersetzt es dann im Register-Paket. Sofern das Telefon letzteres täte würde es sich meiner Meinung nach sogar Regelwidrig verhalten.

Ich sehe hier immer noch keinen RFC-Verstoß. FQDN ist in der RFC abgedeckt und wird wohl von M-Net in den voip-settings auch so angegeben. Wenn Dein Telefon hier nicht mitmacht - wird es wohl Pech für Dich sein - ich würde mich an Yealink wenden warum die einen nicht RFC-Konformen SIP-Stack implementieren ;-)

Alternativ kannst Du Dich aber auch über die Bundesnetzagentur an M-Net wenden, da bekommst Du dann auch tatsächlich eine technisch fundierte Antwort eines M-Net Technikers.

Die Technik wird sich hier wohl leider nicht melden, und ich weiß nicht ob die Forenmods so tief in den Protokollen drinstecken.

Viele Grüße,
Fabian

Edit und P.S.
Mags Yealink eigentlich keine Hostnamen als server-Uri? Die Konfigiruationsbeispielebilder von Yealinks die mir google ausgeworfen hat, lassen eigentlich auch die Eingabe von einer URL zu. Oder löst das Telefon am Ende die URL intern in eine IP auf (was normal ist ;-) aber setzt dann auch die IP in die Register Message ein?
M-Net Surf&Fon-Flat 1.000 - Cluster 600
Hardware:
ONT: Huawei | Router/Firewall: opnSense

PeterP
Junior - Member
Junior - Member
Beiträge: 26
Registriert: 22.05.2011, 20:19

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon PeterP » 08.11.2017, 22:58

Hallo Fabian,

Diverse Aussagen weiter oben in der RFC wo klar von einem Domain Name die Rede ist, sind dann allerdings sinnfrei bzw. unlogisch.

Kann es sein, dass Dein Begriff von 'Domain' zu eng gefasst ist? Für einen Server, der am öffentlichen Internet hängt ist ein in den globalen Routingtabellen eingetragener Bereich von IP-Adressen essentiell (siehe IPv4-Adresserschöpfung). Das ist aus meiner Sicht die Domain. Die Tatsache, dass es dazu noch schicke Einträge im DNS gibt ist für uns Menschen unverzichtbar, aber dem Internet Protokoll völlig egal.

Ob sich daraus nun aber ableiten lässt, dass sich M-Net nicht RFC-konform verhält sehe ich leider immer noch nicht.

Du legst die RFC so aus, dass dir clientseitig das RECHT auf ein Register-Kommando mit IPv6-Adresse anstelle FQDN zusteht. Gleichermaßen müsste man dann aber auch schlussfolgern, dass einem ebenfalls das RECHT auf IPv4 Konnektivität zum SIP-Server zusteht da das ja auch in der RFC abgedeckt ist.

Selbstverständlich! Wenn sie die RFC nur mit Einschränkungen implementieren, dann sollen sie das gefälligst in ihre Schnittstellenbeschreibung reinschreiben. Da dort aber nichts drinsteht poche ich darauf, dass sie mir eine vertraglich zugesicherte Eigenschaft auch liefern (Bei IPv4 lasse ich mit mir reden, IPv6-only ist eine gute Zukunft ;-)

Wenn M-Net allerdings einen Hostname fordert (dafür gibt es ja auch viele gute Gründe)

Nur rein interessehalber: kannst Du ein paar dieser guten Gründe aufzählen?

Das Beispiel mag ein wenig hinken, wenn aber ein paar SIP Proxies dazwischen hängen vielleicht auch nicht mehr: 20 domains werden von einem httpd auf einer ip gehostet - hier ist der domain name zwingend erforderlich obwohl die RFC für http auch IP-Adressen abdeckt...

Irrelevant, solange Mnet keine virtuellen SIP Domänen betreibt.
Und: Wo ist das Erratum zur RFC, das den von Dir angenommenen Bug beschreibt/korrigiert? Man sollte doch annehmen können, dass dies seit 2002 noch Anderen aufgefallen ist.

Im Umkehrschluss muss ich sogar ableiten, dass sich dein Telefon insofern nicht RFC-Konform verhält, weil es nicht alle im Protokoll vorgesehenen Möglichkeiten implementiert, denn offenbar kannst Du ja nur einen IP-basierten SIP-Server eintragen oder das Telefon löst die URL in eine Adresse auf und ersetzt es dann im Register-Paket. Sofern das Telefon letzteres täte würde es sich meiner Meinung nach sogar Regelwidrig verhalten.

(Seufz) Wir waren uns doch schon einig, dass numerische IP-Adressen in der SIP-Botschaft standardkonform sind!
Yealink hat sich entschieden alle Einstellungen zu normalisieren (insbesondere: FQDNs aufzulösen) und als numerische IPs über die Leitung zu schicken.
Was ist daran verwerflich? Ein Empfänger muss alles akzeptieren, was standardkonform ist. Ein Sender, der die Wahl zwischen mehreren standardkonformen Varianten einer Botschaften hat, darf sich eine davon aussuchen.


Viele Grüße,

Peter

DarkSider
Senior - Member
Senior - Member
Beiträge: 510
Registriert: 25.06.2008, 09:28
Wohnort: München

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon DarkSider » 09.11.2017, 02:04

Hallo Peter,


PeterP hat geschrieben:
Diverse Aussagen weiter oben in der RFC wo klar von einem Domain Name die Rede ist, sind dann allerdings sinnfrei bzw. unlogisch.

Kann es sein, dass Dein Begriff von 'Domain' zu eng gefasst ist? Für einen Server, der am öffentlichen Internet hängt ist ein in den globalen Routingtabellen eingetragener Bereich von IP-Adressen essentiell (siehe IPv4-Adresserschöpfung). Das ist aus meiner Sicht die Domain. Die Tatsache, dass es dazu noch schicke Einträge im DNS gibt ist für uns Menschen unverzichtbar, aber dem Internet Protokoll völlig egal.

Domain, Domain name, hostname, FQDN, IP address literal, [...] Es gibt viele ausdrücke die manchmal das gleiche und manchmal was anderes meinen. Die SIP-RFC schweigt sich zum Thema Domain leider aus (keine Definition). In der SIP RFC finden sowohl Domain als auch Domain Name Verwendung. Aus der RFC kann man schließen, dass die RFC mit "Domain" das hinter dem @ meint und mit domain name der DNS-Name (also keine IP-Adresse) gemeint ist. Da in der von mir zitierten RFC stelle aber von Domain die Rede ist, und ich das "name" wohl fälschlicherweise dazu interpretiert habe spielt das keine große Rolle.

PeterP hat geschrieben:
Du legst die RFC so aus, dass dir clientseitig das RECHT auf ein Register-Kommando mit IPv6-Adresse anstelle FQDN zusteht. Gleichermaßen müsste man dann aber auch schlussfolgern, dass einem ebenfalls das RECHT auf IPv4 Konnektivität zum SIP-Server zusteht da das ja auch in der RFC abgedeckt ist.

Selbstverständlich! Wenn sie die RFC nur mit Einschränkungen implementieren, dann sollen sie das gefälligst in ihre Schnittstellenbeschreibung reinschreiben. Da dort aber nichts drinsteht poche ich darauf, dass sie mir eine vertraglich zugesicherte Eigenschaft auch liefern (Bei IPv4 lasse ich mit mir reden, IPv6-only ist eine gute Zukunft ;-)

An dieser Stelle bleibe ich dabei, dass die RFC lediglich verschiedene RFC-konforme SIP-URIs aufzeigt, deren Verwendung jedoch nicht äquivalent austauschbar ist (siehe unten).

PeterP hat geschrieben:
Wenn M-Net allerdings einen Hostname fordert (dafür gibt es ja auch viele gute Gründe)

Nur rein interessehalber: kannst Du ein paar dieser guten Gründe aufzählen?

- DNS Round Robin (wird von M-Net derzeit nicht eingesetzt)
- Verschiedene Domain-Namen (hostnames) können vom gleichen SIP-Registrar/Proxy bearbeitet werden. z.B. Unterscheidung von Geschäftskunden und Privatkunden
- Domain-Namen (hostnames) sind üblicherweise statischer als IP-Adressen. Das mag bei IPv6 kein allzu großes Argument mehr sein, aber ich finde es im Fall der Fälle doch deutlich angenehmer nur einen DNS Eintrag ändern zu müssen als allen Kunden einen neuen hostname mitzuteilen.
- DNS Location Based (Geographisch naher Server wird ausgewählt) - gerade bei Latenzkritischen Sprachverbindungen ist das ein vorteil. SIP unterstützt ja auch Gloabal Roaming - auch wenn von M-Net nicht angeboten.

PeterP hat geschrieben:
Das Beispiel mag ein wenig hinken, wenn aber ein paar SIP Proxies dazwischen hängen vielleicht auch nicht mehr: 20 domains werden von einem httpd auf einer ip gehostet - hier ist der domain name zwingend erforderlich obwohl die RFC für http auch IP-Adressen abdeckt...

Irrelevant, solange Mnet keine virtuellen SIP Domänen betreibt.
Und: Wo ist das Erratum zur RFC, das den von Dir angenommenen Bug beschreibt/korrigiert? Man sollte doch annehmen können, dass dies seit 2002 noch Anderen aufgefallen ist.

Ich weiß nicht ob M-Net virtuelle SIP-Domänen betreibt (weißt Du das?). Und nur weil M-Net es nicht anbietet kann es doch kein Argument sein dass M-Net deshalb solche Anfragen akzeptieren muss. Nur weil ein Webserver nur einen Domain Name hostet heißt das doch nicht dass dieser auch über eine IP-Basierte Anfrage erreichbar sein muss? Ich sehe in der RFC keinen "Bug". Du legst Dir das dort geschrieben so zurecht wie es Dir passt - hier ist das Problem (siehe unten).

PeterP hat geschrieben:
Im Umkehrschluss muss ich sogar ableiten, dass sich dein Telefon insofern nicht RFC-Konform verhält, weil es nicht alle im Protokoll vorgesehenen Möglichkeiten implementiert, denn offenbar kannst Du ja nur einen IP-basierten SIP-Server eintragen oder das Telefon löst die URL in eine Adresse auf und ersetzt es dann im Register-Paket. Sofern das Telefon letzteres täte würde es sich meiner Meinung nach sogar Regelwidrig verhalten.

(Seufz) Wir waren uns doch schon einig, dass numerische IP-Adressen in der SIP-Botschaft standardkonform sind!
Yealink hat sich entschieden alle Einstellungen zu normalisieren (insbesondere: FQDNs aufzulösen) und als numerische IPs über die Leitung zu schicken.
Was ist daran verwerflich? Ein Empfänger muss alles akzeptieren, was standardkonform ist. Ein Sender, der die Wahl zwischen mehreren standardkonformen Varianten einer Botschaften hat, darf sich eine davon aussuchen.


Ich habe mich jetzt etwas tiefer in SIP RFC eingearbeitet da mich die Thematik nun doch auch persönlich interessiert. So wie es aussieht macht Dein Telefon großen Bockmist, denn genau diese Umsetzung die Du beschreibst ist explizit nicht RFC konform. Vom gesunden Menschenverstand her ist das logisch, denn die SIP-URI denkst weder Du noch Dein Telefon dir aus, sondern wird vom Anbieter vorgegeben. Du kämst ja auch nicht auf die Idee bei einer e-Mail Adresse den Domain Name mit dem IP-Literal zu ersetzen peterp@[1.2.3.4] - obwohl das eine gültige e-Mail Adresse ist, sofern Sie Dir dein Provider so mitgeteilt hat. Die RFC überlässt es dem Provider ob die URI non IP oder hostname vewendet aber nicht dem Client. Die RFC empfiehlt aber ganz klar den FQDN zu verwenden

RFC Page 148:

Code: Alles auswählen

      host: The host providing the SIP resource.  The host part contains
         either a fully-qualified domain name or numeric IPv4 or IPv6
         address.  Using the fully-qualified domain name form is
         RECOMMENDED whenever possible.


in Kapitel 19.1.4 URI Comparison (https://tools.ietf.org/html/rfc3261#section-19.1.4) steht:

Code: Alles auswählen

Some operations in this specification require determining whether two
SIP or SIPS URIs are equivalent.  In this specification, registrars
need to compare bindings in Contact URIs in REGISTER requests (see
Section 10.3.).  SIP and SIPS URIs are compared for equality
according to the following rules:
[...]
* An IP address that is the result of a DNS lookup of a host name
  does not match that host name.


Hiermit sind insbesondere die URI vergleiche gemeint die ich bereits in meinem letzten Posting zitiert habe. Weiter unten in den Beispielen wird die oben genannte IP / host name Regel sogar explizit präziserit:

Code: Alles auswählen

The URIs within each of the following sets are not equivalent:

[...]

   sip:bob@phone21.boxesbybob.com   (even though that's what
   sip:bob@192.0.2.4                 phone21.boxesbybob.com resolves to)

[...]


M-Net verhält sich also explizit Regelkonform. Mich würde interessieren was Yealink zu dem Thema sagt.

viele Grüße,

Fabian
M-Net Surf&Fon-Flat 1.000 - Cluster 600
Hardware:
ONT: Huawei | Router/Firewall: opnSense

PeterP
Junior - Member
Junior - Member
Beiträge: 26
Registriert: 22.05.2011, 20:19

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon PeterP » 09.11.2017, 22:07

Hallo Fabian,

Ich sehe in der RFC keinen "Bug". Du legst Dir das dort geschrieben so zurecht wie es Dir passt.

Und bei Dir habe ich immer mehr den Eindruck, dass Du ein Mnet-Mitarbeiter bist, der die Aufgabe hat, jedes noch so fadenscheinige Argument zu suchen (und ggf. auch ein paar rote Heringe, falls nichts mehr weiterhilft) um zu rechtfertigen, warum Mnet auf ein berechtigtes Anliegen nicht reagieren soll.

... So wie es aussieht macht Dein Telefon großen Bockmist, ... Die RFC empfiehlt aber ganz klar den FQDN zu verwenden

Das Schlüsselwort ist empfiehlt. Von da bis Bockmist und verboten ist es noch ein weiter Weg.

in Kapitel 19.1.4 URI Comparison (https://tools.ietf.org/html/rfc3261#section-19.1.4) steht ....

Rotten Herring.

Servus,

Peter

DarkSider
Senior - Member
Senior - Member
Beiträge: 510
Registriert: 25.06.2008, 09:28
Wohnort: München

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon DarkSider » 10.11.2017, 02:40

Hallo Peter,

PeterP hat geschrieben:Und bei Dir habe ich immer mehr den Eindruck, dass Du ein Mnet-Mitarbeiter bist, der die Aufgabe hat, jedes noch so fadenscheinige Argument zu suchen (und ggf. auch ein paar rote Heringe, falls nichts mehr weiterhilft) um zu rechtfertigen, warum Mnet auf ein berechtigtes Anliegen nicht reagieren soll.

Ich bin mit Sicherheit kein M-Net Mitarbeiter ;-) Wenn Du Dir meine Beiträge zu diversen Themen hier im Forum ansiehst wirst du auch viel kritisches von mir lesen. Ein M-Net Mitarbeiter würde sich so sicherlich niemals äußern. M-Net hat bereits reagiert, indem die Foren-Moderatoren den Beitrag in Kunden helfen Kunden verschoben haben.

PeterP hat geschrieben:
... So wie es aussieht macht Dein Telefon großen Bockmist, ... Die RFC empfiehlt aber ganz klar den FQDN zu verwenden

Das Schlüsselwort ist empfiehlt. Von da bis Bockmist und verboten ist es noch ein weiter Weg.

Die RFC empfiehlt dem Dienstanbieter SIP URIs mit FQDN zu vergeben, damit diverse Probleme (z.B. bei Multi Domain SIP-Proxies) erst gar nicht auftreten. Er kann diese Empfehlung ignorieren und auch IP-basierte URIs verwenden. M-Net folgt der Empfehlung (was allerdings nichts zur Sache tut). Dein Telefon verhält sich insofern nicht Standardkonform, als dass es einen Hostname im Register Kommando in eine IP auflöst. Dass es SIP-Proxies gibt, die Multi-Domain-Fähig sind und RFC-Konform sind haben wir bereits ein paar Postings weiter oben festgestellt.

Nehmen wir hypothetisch an es gibt den SIP-Proxy welcher die SIP-Domains A.phone.com und B.phone.com verwaltet. Auf dem Server existieren folgende SIP-Uris:
123@A.phone.com
123@B.phone.com
Dein Yealink Telefon möchte sich nun mit 123@A.phone.com anmelden, ersetzt im Register Paket allerdings 123@A.phone.com mit mit 123@[1.2.3.4] - Woher weiß nun der SIP-Proxy ob Du dich für A.phone.com oder B.phone.com registrieren möchtest? Spätestens jetzt müsste Dir klar sein, dass eine solche Umwandlung eben nicht Regelkonform sein kann - es sein denn Du möchtest behaupten das Yealink Telefon kann erraten dass der Proxy für mehrere Domains zuständig ist und lässt die Ersetzerei dann bleiben ;-)

Dass M-Net hier _möglicherweise_ keinen Multi-Domain-SIP-Registrar betreibt und dass der USER-Part in der SIP-URI eine eindeutige Telefonnummer ist ließe theoretisch eine Implementierung zu, die das Verhalten von Deinem Telefon toleriert - aber das war's auch schon. RFC konform wäre das dann nicht mehr

PeterP hat geschrieben:
in Kapitel 19.1.4 URI Comparison (https://tools.ietf.org/html/rfc3261#section-19.1.4) steht ....

Rotten Herring.

Warum du das als Nebelkerze, Blödsinn oder was auch immer darstellen möchtest ist mir nicht klar. Erklären magst Du es mir wahrscheinlich nicht.

Da wir uns hier aber vermutlich auf keinen gleichen Nenner einigen werden folgender anderer Vorschlag:
Ich konnte bei Yealink im Forum und in den Changenotes zu diversen Telefonen nichts finden was auf das obige Problem hindeutet. Mich würde interessieren ob Dein Telefon ein vergleichbares Verhalten bei einer IPv4 Konfiguration zeigt. Sprich wird dann ebenfalls der Hostname im Register Paket in ein IP-Literal umgewandelt? Möglicherweise handelt es sich um einen Bug in der IPv6 Implementierung des Register Kommandos im Telefon. Ich könnte mir vorstellen dass es noch nicht so viele IPv6-Only Deployments im VoIP-Bereich gibt und das Problem vielleicht tatsächlich noch keinem aufgefallen ist...

Ich habe hier selbst mal mit wireshark ein paar SIP phones gesnifft (kein Yealink) und keines davon ersetzt den hostname durch eine IP-Adresse im Register-Paket.

viele Grüße,

Fabian
M-Net Surf&Fon-Flat 1.000 - Cluster 600
Hardware:
ONT: Huawei | Router/Firewall: opnSense

fencingline
Aufsteiger
Aufsteiger
Beiträge: 169
Registriert: 01.09.2016, 10:23

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon fencingline » 13.11.2017, 19:55

Registriere doch mal einen SIP Account bei sipgate.de und konfiguriere diesen in deiner FRITZ!Box. Ich bin mir sicher, dass das ohne Probleme funktionieren wird. Die Konsequenz daraus sollte für dich klar sein: Telefonie aus deinem Vertrag kündigen und die Rufnummer(n) zu Sipgate weg portieren. ;)
M-Net Kunde seit 25.10.2017
Produkt: Surf-Flat 25 Mbit/s

Trustpilot Bewertungen für M-Net

[...]würde Dich bitten dich mit solchen Aussagen zurückzuhalten[...]

lamena
Senior - Member
Senior - Member
Beiträge: 622
Registriert: 06.11.2014, 12:44

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon lamena » 13.11.2017, 20:28

fencingline hat geschrieben:Registriere doch mal einen SIP Account bei sipgate.de und konfiguriere diesen in deiner FRITZ!Box. Ich bin mir sicher, dass das ohne Probleme funktionieren wird. Die Konsequenz daraus sollte für dich klar sein: Telefonie aus deinem Vertrag kündigen und die Rufnummer(n) zu Sipgate weg portieren. ;)


Es ging doch um ein eigenes Gerät was sich vielleicht selbst ned 100% korrekt verhält.
Insofern dürfte AVM hier erstmal raus sein.

till1969
Aufsteiger
Aufsteiger
Beiträge: 374
Registriert: 19.02.2014, 11:06

Re: VoIP: Mnet Problem verhindert Betrieb eines standardkonformen SIP-Phones

Beitragvon till1969 » 13.11.2017, 20:30

fencingline hat geschrieben:Telefonie aus deinem Vertrag kündigen und die Rufnummer(n) zu Sipgate weg portieren. ;)

Das ist in Zeiten von Handy Allnet-Flats von 6,50€ sowieso zu empfehlen.
Aber ich würde personal-voip.de bevorzugen, 3 SIP Konten und 4 Nummern kostenlos ;)


Zurück zu „Kunden helfen Kunden (eigene Endgeräte)“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 17 Gäste