Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Snom D715 und Telekom All-IP

50 views
Skip to first unread message

Christian Weisgerber

unread,
Dec 29, 2019, 2:30:07 PM12/29/19
to
Ich habe hier ein Snom D715 IP-Telefon, das über einen Router mit
Siproxd an einem All-IP-Anschluss (VDSL) der Telekom hängt. Das
Telefon kann angerufen werden, selbst aber nicht alle Gegenstellen
anrufen.

Das Telefon
* registriert sich erfolgreich bei tel.t-online.de,
* kann von einem Mobiltelefon (O₂) angerufen werden,
* kann von einem PSTN-Anschluss (Telekom; ehemals analog, jetzt
auch als All-IP realisiert) im selben Haus angerufen werden.

Das Telefon kann
* die Telekom-Sprachbox (08003302424) anrufen,
* ein Mobiltelefon (O₂) anrufen.

Das Telefon kann _nicht_
* den PSTN-Anschluss anrufen: „Service unavailable“.

Ich habe den Paketverkehr mitgeschnitten und die SIP-Signalisierung
angeschaut. Zwischen den erfolgreichen Anrufen zum Mobiltelefon und
den scheiternden zum PSTN-Anschluss gibt es anfänglich keinerlei
Unterschied. Nur dass bei ersterem von Telekomseite dann
100 Trying
183 Session Progress
180 Ringing
...
kommt, bei letzterem dagegen
100 Trying (manchmal)
500 Service Unavailable

Die Antwort „500 Service Unavailable“ gibt leider nicht den geringsten
Hinweis auf einen Grund.

Ich bin ratlos, wie ich dieses Kompatibilitätsproblem eingrenzen
könnte. Ideen?

--
Christian "naddy" Weisgerber na...@mips.inka.de

Georg Schwarz

unread,
Dec 30, 2019, 6:43:47 AM12/30/19
to
Christian Weisgerber <na...@mips.inka.de> wrote:

> Das Telefon kann
> * die Telekom-Sprachbox (08003302424) anrufen,
> * ein Mobiltelefon (O?) anrufen.
>
> Das Telefon kann _nicht_
> * den PSTN-Anschluss anrufen: "Service unavailable".

welchen ("den") PSTN-Anschluss? Nur einen speziellen?

Wird mit Vorwahl gewählt?

>
> Ich habe den Paketverkehr mitgeschnitten und die SIP-Signalisierung
> angeschaut. Zwischen den erfolgreichen Anrufen zum Mobiltelefon und
> den scheiternden zum PSTN-Anschluss gibt es anfänglich keinerlei
> Unterschied. Nur dass bei ersterem von Telekomseite dann
> 100 Trying
> 183 Session Progress
> 180 Ringing
> ...
> kommt, bei letzterem dagegen
> 100 Trying (manchmal)
> 500 Service Unavailable

und das geht in allen Fällen zum selben Sever?

>
> Die Antwort "500 Service Unavailable" gibt leider nicht den geringsten
> Hinweis auf einen Grund.
>
> Ich bin ratlos, wie ich dieses Kompatibilitätsproblem eingrenzen
> könnte. Ideen?


der einzige Unterschied liegt also in der Zielrufnummer?
Gibt es PSTN-Anschlusse, die angerufen werden können (einfach mal z.B.
mit Fax-Rufnummern von Unternehmen oder Behörden ausprobieren).

Christian Weisgerber

unread,
Dec 30, 2019, 2:30:06 PM12/30/19
to
On 2019-12-29, Christian Weisgerber <na...@mips.inka.de> wrote:

> Ich habe hier ein Snom D715 IP-Telefon, das über einen Router mit
> Siproxd an einem All-IP-Anschluss (VDSL) der Telekom hängt. Das
> Telefon kann angerufen werden, selbst aber nicht alle Gegenstellen
> anrufen.

Die Lösung ist, SRTP abzuschalten.

In der Snom-Konfiguration:
Identity -> RTP -> RTP Encryption [OFF]

Das hat wohl nichts mit der VoIP-Infrastruktur der Telekom zu tun,
sondern mit der Gegenstelle. Im konkreten Testfall ein reiner
Telefonanschluss, der aber nach der zwangsweisen Umstellung von
analog auf All-IP von einem (so steht's im INVITE, das er verschickt)
Speedport Smart/FW 050129.3.5.002.0
bedient wird.

Georg Schwarz

unread,
Dec 30, 2019, 8:06:07 PM12/30/19
to
Christian Weisgerber <na...@mips.inka.de> wrote:

> Das hat wohl nichts mit der VoIP-Infrastruktur der Telekom zu tun,
> sondern mit der Gegenstelle. Im konkreten Testfall ein reiner
> Telefonanschluss, der aber nach der zwangsweisen Umstellung von
> analog auf All-IP von einem (so steht's im INVITE, das er verschickt)
> Speedport Smart/FW 050129.3.5.002.0
> bedient wird.

das Teil sollte man ein Firmware-Update erhalten; vergl.
https://www.telekom.de/hilfe/downloads/firmwareaenderungen-speedport-smart-v050129-3-5-005-0.pdf

Andreas Hartmann

unread,
Dec 31, 2019, 5:00:17 AM12/31/19
to
On 30.12.19 at 20:21 Christian Weisgerber wrote:
> On 2019-12-29, Christian Weisgerber <na...@mips.inka.de> wrote:
>
>> Ich habe hier ein Snom D715 IP-Telefon, das über einen Router mit
>> Siproxd an einem All-IP-Anschluss (VDSL) der Telekom hängt. Das
>> Telefon kann angerufen werden, selbst aber nicht alle Gegenstellen
>> anrufen.
>
> Die Lösung ist, SRTP abzuschalten.
>
> In der Snom-Konfiguration:
> Identity -> RTP -> RTP Encryption [OFF]

SRTP im Zusammenhang mit SIP ist grundsätzlich sinnlos. AllIP der Telekom benötigt für SRTP SIPS und mediasec. Beides war nach Deinen Aussagen nicht aktiviert bzw.
letzteres kann SNOM mit hoher Wahrscheinlichkeit gar nicht.

Dass das mal funktioniert hat, mal nicht, liegt daran, dass SRTP seitens SNOM optional gefahren wurde (d.h. schlicht und ergreifend vom Peer ignoriert wurde und dann eben
unverschlüsselt lief) - solange einer die grundsätzliche Anforderung SRTP nicht ernst genommen hat. Es ist korrekt, das Gespräch zu verweigern, wenn ein angefordertes
Feature nicht umgesetzt werden kann.


Gruß
Andreas

Christian Weisgerber

unread,
Dec 31, 2019, 4:30:07 PM12/31/19
to
On 2019-12-31, Andreas Hartmann <andiha...@01019freenet.de> wrote:

> Dass das mal funktioniert hat, mal nicht, liegt daran, dass SRTP seitens SNOM optional gefahren wurde (d.h. schlicht und ergreifend vom Peer ignoriert wurde und dann eben
> unverschlüsselt lief) - solange einer die grundsätzliche Anforderung SRTP nicht ernst genommen hat.

In der Standardeinstellung schickt Snom sowas raus:

m=audio 7084 RTP/AVP 9 0 8 3 99 112 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:QODVuGfCn/No8PoddxGB4gZO7hiPuwOCflGhknYk

Also kein SRTP, sondern RTP, aber mit Crypto-Attribut. Offenkundige
Absicht ist opportunistische Verschlüsselung mit Gegenstellen, die
das unterstützen, und die Annahme, dass andere das unbekannte/falsche
Attribut einfach ignorieren.

Wie man sieht, gibt selbst das Interop-Probleme.

Parallel zu „RTP Encryption“ on/off gibt es eine Einstellung
„RTP/SAVP“:
Off [Standard]
optional
mandatory

Bei „optional“ bietet das Gerät im SDP-Text zwei m-Zeilen an, für
RTP/AVP ohne und RTP/SAVP mit Verschlüsselung. Leider gibt es
offenbar SIP-Proxies, die sich wiederum daran verschlucken.

Mit aktueller Firmware bietet das Snom auch „Enable Mediasec“ an.
Scheint neu zu sein, da das Link zum Hilfstext noch ins Leere führt.

Ich werde die Kombination SIPS/Mediasec/SRTP im Hinterkopf behalten,
aber da SIPS mit Siproxd nicht funktioniert, wird dann die NAT-Querung
zu einem Heidenproblem.

Georg Schwarz

unread,
Jan 1, 2020, 9:16:23 AM1/1/20
to
Christian Weisgerber <na...@mips.inka.de> wrote:

> Ich werde die Kombination SIPS/Mediasec/SRTP im Hinterkopf behalten,
> aber da SIPS mit Siproxd nicht funktioniert, wird dann die NAT-Querung
> zu einem Heidenproblem.

was genau macht siproxd falsch, sodass es damit nicht funktioniert?

Christian Weisgerber

unread,
Jan 1, 2020, 11:30:07 AM1/1/20
to
On 2020-01-01, Georg Schwarz <georg....@freenet.de> wrote:

>> Ich werde die Kombination SIPS/Mediasec/SRTP im Hinterkopf behalten,
>> aber da SIPS mit Siproxd nicht funktioniert, wird dann die NAT-Querung
>> zu einem Heidenproblem.
>
> was genau macht siproxd falsch, sodass es damit nicht funktioniert?

Siproxd unterstützt einfach kein TLS.

Andreas Hartmann

unread,
Jan 1, 2020, 11:50:33 AM1/1/20
to
On 01.01.20 at 17:14 Christian Weisgerber wrote:
> On 2020-01-01, Georg Schwarz <georg....@freenet.de> wrote:
>
>>> Ich werde die Kombination SIPS/Mediasec/SRTP im Hinterkopf behalten,
>>> aber da SIPS mit Siproxd nicht funktioniert, wird dann die NAT-Querung
>>> zu einem Heidenproblem.
>>
>> was genau macht siproxd falsch, sodass es damit nicht funktioniert?
>
> Siproxd unterstützt einfach kein TLS.

Korrekt.

Nebenbei: mir erschließt sich der Einsatz von SIP-Proxies im privaten Rahmen irgendwie sowieso nicht. Ok - ist einfacher und damit (je nach Anforderung) weniger aufwändig -
aber das war es dann auch schon.

Ein SBC (B2BUA) macht da doch viel mehr Sinn, weil ich zusätzlich zum Sicherheitsaspekt auch noch viele andere Telefoniefeatures einfach so dazu bekomme (mit FreePBX und
Asterisk z.B.) incl. mediasec support (und damit SRTP - mit zusätzlichem Patch).


Gruß
Andreas

Christian Weisgerber

unread,
Jan 1, 2020, 2:30:08 PM1/1/20
to
On 2020-01-01, Andreas Hartmann <andiha...@01019freenet.de> wrote:

> Nebenbei: mir erschließt sich der Einsatz von SIP-Proxies im privaten Rahmen irgendwie sowieso nicht. Ok - ist einfacher und damit (je nach Anforderung) weniger aufwändig -
> aber das war es dann auch schon.

Wenn der VoIP-Anbieter IPv6 unterstützt, braucht man das nicht und
kann IP-Telefone direkt registrieren. Wenn nur IPv4, wie bei der
Telekom¹, dann ist die NAT-Querung ein Trauerspiel. RFC 6314 „NAT
Traversal Practices for Client-Server SIP“ lesen und weinen.
Siproxd auf dem NAT-Gateway erschlägt dieses Problem mit minimaler
Konfiguration.

> Ein SBC (B2BUA) macht da doch viel mehr Sinn, weil ich zusätzlich zum Sicherheitsaspekt auch noch viele andere Telefoniefeatures einfach so dazu bekomme (mit FreePBX und
> Asterisk z.B.) incl. mediasec support (und damit SRTP - mit zusätzlichem Patch).

Gerade privat will man doch oft einfach nur den Leistungsumfang
eines POTS/ISDN-Anschlusses mit VoIP realisieren und keine eigene
Telefonanlage einrichten.


¹) Ich habe mir jetzt einen Cron-Job angelegt, der mich benachrichtigt,
wenn bei tel.t-online.de ein AAAA-Eintrag auftaucht.
(Ja, ja. NAPTR > SRV > AAAA ist mir für einen Einzeiler zu lang.)
0 new messages