[Problem] Bitte rufen Sie den Teilnehmer zu einem späteren Zeitpunkt an

[thtomate12]

Ergänzung (habe ich gestern wohl vergessen): Ich konnte kein Softphone finden, welches clause 18 nach RFC beachtet. Ihr braucht also kein Speedport, einfach viele Codecs anschalten und lange Anzeigenamen verwenden.

Meine Meinung: Das Identity-Feld ist nicht doppelt.

 

[KunterBunter]

Kannst du bitte mal einen Link zu der Telekom-Doku geben?

Schnittstellenbeschreibungen für Hersteller

Falls es hilft, hier die user agent Zeile aus dem Header der langen Invite-Message:
User-Agent: Speedport W 724V/Version 01011603.00.008

Das ist die Firmware Version 01011603.00.008 des Speedport W 724V Typ B. Stand 03/2016

 

[broeselmeier]

Schnittstellenbeschreibungen für Hersteller

Danke.

Weiß jemand spontan, in welchem der vielen Dokumente etwas zu SIP-Messagegrößen und dem zu verwendenden Transportprotokoll steht?

 

[thtomate12]

In TR114 steht, dass UDP und TCP unterstützt werden muss (Seite 50), in Annex B das zur Paketlänge (Seite 39).

 

[broeselmeier]

Danke (Seitenangaben waren vertauscht)

Aus dem 1TR114_ANNEXB-Dokument

4.2A Transport mechanisms
This document makes no requirement on the transport protocol used to transfer signalling information over and above that specified in RFC 3261 [26] clause 18. However, the UE and IM CN subsystem entities shall transport SIP messages longer than 1300 bytes according to the procedures of RFC 3261 [26] subclause 18.1.1, even if a mechanism exists of discovering a maximum transmission unit size longer than 1500 bytes.

Stutzig könnte das "shall" machen, denn in RFC3261 steht MUST.

Habe mir gerade nochmal 18.1.1 von RFC3261 durchgelesen.
Dort ist UDP als Fallback beschrieben, wenn keine TCP-Verbindung aufgebaut werden kann.

Damit (TCP-Verbindung kann nicht aufgebaut werden und UDP resultiert aus dem Fallback-Verhalten des Telekom-Sip-Servers) hatte ich Nobody auch konfrontiert. Er behauptet, dass es keine TCP-Verbindungsversuche gibt, wenn ein Problem-Anrufer anruft. Jemandem, der in der Lage ist, den Netzwerktraffic am WAN-Interface seines Routers beim Anrufversuch mitzuloggen, würde ich diese Aussage auch erst einmal glauben.

Außerdem würde ein messagegrößenabhängiger d.h. dynamischer Wechsel von UDP auf TCP in der Praxis auch mehr Probleme schaffen als lösen. Ohne manuell eingerichtetes Portforwarding ist am Router nur der Port+Protokoll offen, den der SIP-Client mit dem Registrierungsvorgang aufgemacht hat. Also dürfte es in der Praxis die wenigsten Probleme bereiten, wenn die SIP-Proxies den Angerufenen ohne Beachtung der Messagegröße mit dem gleichen Transportprotokoll ansprechen, mit dem er sich registriert hat.

 

[thtomate12]

Ich habe mit Linphone über einen Telekom-VoIP-Acoount mal selbigen angerufen, es läuft kein TCP-Verbindungsversuch über das DSL-Modem. Linphone hält sich aber auch nicht an Clause 18.1.1, obwohl es eine Einstellungsmöglichkeit für die MTU gibt, eventuell gilt diese nur fürs TCP. Ob dies ein guter Testaufbau ist, weiß ich nicht, aber ich gerade nichts besseres.

 

[broeselmeier]

Selbst wenn der anrufende SIP-Client sich nicht an die Spielregeln hält, wäre es immer noch Sache des Telekom-SIP-Proxy die Message entweder abzulehnen oder die Verbindung zum Angerufenen richtig herzustellen.

Aber das ist alles nur Theorie.
Wie oben schon ausgeführt, halte ich den in rfc3261 beschriebenen messagegrößenabhängigen Wechsel des Übertragungsprotokolls nicht für praxistauglich.

Unter allen Übeln dürfte die Verwendung des bei der Registrierung verwendeten Protokolls das Kleinste sein.

Die (wenigen?) Betreiber von Routern/Appliances, die fragmentierten UDP-Traffic nicht durchlassen wollen, müssen dann eben dafür sorgen, dass sich ihre SIP-Clients per TCP registrieren.

 

[broeselmeier]

Aus dem Handbuch der Draytek Vigor130 Router Konfiguration geht hervor, dass die Firewall vor allerlei DoS-Attacken schützen will. Unter Anderem auch vor "UDP flood attack".

Optional kann man ein Flag setzen:

“Accept large incoming fragmented UDP or ICMP Packets”

Some on-line games (for example: Half Life) will use lots
of fragmented UDP packets to transfer game data.
Instinctively as a secure firewall, Vigor modem will reject
these fragmented packets to prevent attack unless you enable
“Accept large incoming fragmented UDP or ICMP Packets”.
By checking this box, you can play these kinds of on-line games.
If security concern is in higher priority, you cannot enable
“Accept large incoming fragmented UDP or ICMP Packets”.

Wie Nobody herausgefunden hat, erhöht das bei den Draytek Routern die zulässige UDP-Datagrammgröße aber auch nur auf 1628 Byte.

Wer mit DoS-Attacken rechnet, wird sich eh an die Empfehlung halten.

Keine Ahnung, ob es sich Draytek zu einfach macht mit der DoS-Abwehr.

Falls da aber etwas dran ist, wäre das nicht gerade eine Empfehlung für SIP-Accounts der Telekom oder allgemein von von SIP-Providern, die nichts gegen fragmentierten UDP-SIP-Traffic unternehmen.

 

[broeselmeier]

Keine Ahnung, ob es sich Draytek zu einfach macht mit der DoS-Abwehr.

Habe mich ein wenig zum Thema belesen und würde sagen, dass es sich draytek zu einfach macht, wenn die Router fragmentierten UDP-Traffic aus Prinzip verwerfen.

So wie sich die Draytek-Router derzeit verhalten, würde ich sie pauschal als ungeeignet für SIP einstufen (Ausnahmen unter besonderen Randbedingungen bestätigen die Regel).