"SIP/2.0 500 Service Unavailable" ausgehend an Snom D765 über Magenta M Hybrid (Speedport Pro) bei bestimmten Nummern

InfectedChild · 25 Jan 2020

Hallo alle zusammen!

Habe hier einen Magenta M Hybrid mit einem Speedport Pro (FW: 120133.2.0.010.3). Daran möchte ich ein Snom D765 (FW: 10.1.49.11) betreiben. Um dies zu bewerkstelligen habe ich folgendes gemacht:

Eine Ausnahme für den Adressbereich 217.0.1.0/24 bis 217.0.1.16/24 eingerichtet, sodass ausgehende Verbindungen über DSL gehen.
Eine Ausnahme für das Snom Telefon eingerichtet, sodass dieses grundsätzlich über DSL raus geht (Warum? Weil es hier so angegeben wurde: https://telekomhilft.telekom.de/t5/...n-SIP-Telefonen-an-Speedport-PRO/td-p/3962716)
Das Wurzelzertifikat T-Telesec Global Root Class 2 manuell im Snom importiert. Im DER Format von https://www.pki.dfn.de/wurzelzertifikate/globalroot2/
Im Snom eine Identity mit folgenden Einstellungen eingerichtet:
- Displayname: Telefonnummer mit Ortsvorwahl (04722....)
- Account: Telefonnummer mit Ortsvorwahl (04722....)
- Password: Das Passwort des Telekom Kundencenters
- Registrar: tel.t-online.de
- Outbound Proxy: tel.t-online.de
- Authentication Username: E-Mail Adresse des Telekom Kundencenters ([email protected])
- Country Code: 49
- Area Code: 4722
Wobei diese Einstellungen laut verschiedenen Quellen die Kompatibilität erhöhen sollen:
- Long SIP-Contact (RFC3840): off
- Support Broken Registrar: on
- STUN Server (IP-Address : Port): stun.t-online.de:3478 (ob mit oder ohne, macht kein Unterschied)
- Filter Packets from Registrar (unter Advanced): off

Das Snom registriert sich und alles scheint zu funktionieren (ausgenommen Anrufweiterleitung). Nach ein paar Tests stellt sich jedoch heraus, dass bestimmte Festnetznummern (die wie andere funktionierende Festnetzrufnummern immer im selben Schema eingegeben werden, bspw. 04721.., 040..) ausgehend nicht erreichbar sind.

Wenn gewählt wird erscheint auf dem Snom Display "500 Server Internal Error". Im Log des Snom heißt es: "[CRITIC] PHN: unsupported scheme in URL: phone://mb_exit " und "[ERROR ] MEDIA: StopCall: failed to stop 956169514".
Der SIP-Trace wird mit folgender Meldung beendet:

SIP/2.0 500 Service Unavailable
Via: SIP/2.0/TLS 192.168.X.X:43977;received=217.232.50.93;rport=43977;branch=z9hG4bK-z8k0bnryxkof
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579955174m258330c539450678s1_4209785800-1437924291
From: "04722XXXX" <sip:[email protected]-online.de>;tag=z1j7pgk1xj
Call-ID: 313537393935353137333137383534-3870m0we976u
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Retry-After: 5
Supported: timer
Content-Length: 0

Bei Mobilfunknummer trat das Problem bisher nicht auf. Nur bei Festnetzrufnummern. Und hier ist kein Muster zu erkennen. Nummern mit gleicher (fremder) Ortsvorwahl funktionieren teilweise, teilweise auch nicht. Mit Google komme ich an dieser Stelle leider nicht weiter. Hat hier vllt jemand schon einmal ein ähnliches Problem gehabt und weiß was zu tun ist? Für jeden Tipp wäre ich dankbar!

Beste Grüße,
Karsten

Meester Proper · 25 Jan 2020

Um Verschlüsselung zu nutzen sind die MediaSec-Parameter nach 1TR114 nötig. Ohne Verschlüsselung, also mit TCP oder UDP als SIP-Transport und RTP für die Medienübertragung sollte es gehen.

InfectedChild · 25 Jan 2020

Gibt es irgendwo eine Zusammenfassung wie ich einem Snom Telefon beibringen kann nach diesen Parametern zu kommunizieren? Auf Verschlüsselung würde ich doch ungern verzichten. Ist es denn bei dem Fehlerbild überhaupt wahrscheinlich, dass die aktuellen Snom Einstellungen Probleme mit der Verschlüsselung verursachen?

gehtdoch · 25 Jan 2020

Mediasec muss vom Device unterstützt werden. Ansonsten kannst Du da auch nichts einstellen. Ich konnte bei einer GoogleSuche SNOM und Mediasec nichts finden, was auf eine Unterstützung hinweist. LANCOM kann es wohl zumindest mit einem Device. Oder Asterisk mit Patch.

Was mich allerdings etwas irritiert ist, dass es zu Mobile-Devices funktioniert - aber nicht zu Festnetznummern. Ich hätte da keinen Unterschied erwartet. Wahrscheinlich gehst Du unverschlüsselt raus. Dazu müsstest Du einen kompletten Trace machen - dann kannst Du es erkennen - würde Dir auch bei dem Fehler weiterhelfen. Das von Dir gepostete letzte Paket einer kompletten Kommunikation ist für eine Fehlerabschätzung wertlos.

Versuche das Ganze doch erst mal unverschlüsselt vollständig zum Laufen zu bringen. Verschlüsselung (SIPS via TCP) und dann irgendwann SRTP sind zwei weitere Schritte.

Meester Proper · 25 Jan 2020

SIPS wird bei den Telekom-Produkten nicht unterstützt, lediglich SIP over TLS kann bei Vorliegen aller Voraussetzungen genutzt werden.

InfectedChild · 25 Jan 2020

gehtdoch schrieb:
Vollzitat entfernt by stoney

Hier ein kompletter SIP-Trace eines erfolgreichen Telefonats (ins Festnetz):

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:43977 at Jan 25 16:42:33.273 (1535 bytes):

INVITE sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;branch=z9hG4bK-gkcfo9nqem9z;rport
From: "04722XXXX" <sip:[email protected]-online.de>;tag=0uez1prgny
To: <sip:[email protected]-online.de;user=phone>
Call-ID: 3135373939363639353339323534-g0lg9wbc4qqi
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:43977;transport=Tls>;reg-id=1
X-Serialnumber: 00041394F2F1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="FEB24C4BD4612C5E00000000E2E70963",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000004,cnonce="233b9097",response="671ca15d68ab6b14e4503c5cecf5bda2",algorithm=MD5
Content-Type: application/sdp
Content-Length: 487

v=0
o=root 732050621 732050621 IN IP4 217.232.50.93
s=call
c=IN IP4 217.232.50.93
t=0 0
m=audio 56956 RTP/AVP 8 9 0 3 99 112 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:4rIL60Kbxx7vrMFSmjPA0GLZGwJ5yOIyFVaCjcQ8
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:43977 at Jan 25 16:42:33.535 (327 bytes):

SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;received=217.232.50.93;rport=43977;branch=z9hG4bK-gkcfo9nqem9z
To: <sip:[email protected]-online.de;user=phone>
From: "04722XXXX" <sip:[email protected]-online.de>;tag=0uez1prgny
Call-ID: 3135373939363639353339323534-g0lg9wbc4qqi
CSeq: 1 INVITE
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:43977 at Jan 25 16:42:35.067 (919 bytes):

SIP/2.0 183 Session Progress
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;received=217.232.50.93;rport=43977;branch=z9hG4bK-gkcfo9nqem9z
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579966953m514103c539902631s1_3104139759-580207566
From: "04722XXXX" <sip:[email protected]-online.de>;tag=0uez1prgny
Call-ID: 3135373939363639353339323534-g0lg9wbc4qqi
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
P-Early-Media: sendonly
Supported: timer
Content-Type: application/sdp
Content-Length: 243
Allow: PRACK, OPTIONS, BYE, ACK, CANCEL, INVITE, REGISTER
Accept: application/sdp

v=0
o=- 1450298497 3105804506 IN IP4 217.0.25.34
s=fs-a1
c=IN IP4 217.0.2.198
t=0 0
m=audio 31158 RTP/AVP 8 101
a=silenceSupp

ff - - - -
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=ptime:20

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:43977 at Jan 25 16:42:38.328 (1188 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;received=217.232.50.93;rport=43977;branch=z9hG4bK-gkcfo9nqem9z
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579966953m514103c539902631s1_3104139759-580207566
From: "04722XXXX" <sip:[email protected]-online.de>;tag=0uez1prgny
Call-ID: 3135373939363639353339323534-g0lg9wbc4qqi
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
Session-Expires: 1800;refresher=uas
Supported: timer
Supported: path
Supported: replaces
Content-Type: application/sdp
Content-Length: 243
X-Lnp: <null>
Session-ID: a59d7b0e724325358f2af428ab3af782
Authentication-Info: qop=auth,rspauth="f30fb4b3cb98196de9c53df1ba43f04b",cnonce="233b9097",nc=00000004
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 1450298497 3105804506 IN IP4 217.0.25.34
s=fs-a1
c=IN IP4 217.0.2.198
t=0 0
m=audio 31158 RTP/AVP 8 101
a=silenceSupp

ff - - - -
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=ptime:20

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:43977 at Jan 25 16:42:38.335 (843 bytes):

ACK sip:[email protected]:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;branch=z9hG4bK-s5ox945vbxgw;rport
Route: <sip:217.0.25.34:5061;transport=tls;lr>
From: "04722XXXX" <sip:[email protected]-online.de>;tag=0uez1prgny
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579966953m514103c539902631s1_3104139759-580207566
Call-ID: 3135373939363639353339323534-g0lg9wbc4qqi
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:43977;transport=Tls>;reg-id=1
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="FEB24C4BD4612C5E00000000E2E70963",uri="sip:[email protected]:5061;transport=tls",qop=auth,nc=00000005,cnonce="233b9097",response="20609349e7b169976391ea444bc255de",algorithm=MD5
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:43977 at Jan 25 16:42:49.382 (703 bytes):

BYE sip:[email protected]:43977;transport=tcp SIP/2.0
Max-Forwards: 65
Via: SIP/2.0/TLS 217.0.25.34:5061;branch=z9hG4bKg3Zqkv7iir15nqc4bzjp8e3gtvdbkrdzv
To: "04722XXXX" <sip:[email protected]-online.de>;tag=0uez1prgny
From: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579966953m514103c539902631s1_3104139759-580207566
Call-ID: 3135373939363639353339323534-g0lg9wbc4qqi
CSeq: 2 BYE
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Supported: timer
Supported: path
Supported: replaces
Content-Length: 0
X-Asterisk-Hangupcausecode: 16
X-Asterisk-Hangupcause: Normal Clearing
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, INVITE, ACK, OPTIONS, CANCEL, BYE

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:43977 at Jan 25 16:42:49.391 (617 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/TLS 217.0.25.34:5061;branch=z9hG4bKg3Zqkv7iir15nqc4bzjp8e3gtvdbkrdzv
From: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579966953m514103c539902631s1_3104139759-580207566
To: "04722XXXX" <sip:[email protected]-online.de>;tag=0uez1prgny
Call-ID: 3135373939363639353339323534-g0lg9wbc4qqi
CSeq: 2 BYE
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:43977;transport=Tls>;reg-id=1
RTP-RxStat: Total_Rx_Pkts=703,Rx-Pkts=703,Rx_Pkts_Lost=0,Remote_Rx_Pkts_Lost=0
RTP-TxStat: Total_Tx_Pkts=695,Tx_Pkts=695,Remote_Tx_Pkts=695
Content-Length: 0

Hier ein kompletter SIP-Trace eines erfolglosen Telefonats (ins Festnetz):

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:43977 at Jan 25 16:35:43.313 (874 bytes):

REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;branch=z9hG4bK-iaeg22n514yk;rport
From: "04722XXXX" <sip:[email protected]-online.de>;tag=6v1bvu68rx
To: "04722XXXX" <sip:[email protected]-online.de>
Call-ID: 3135373937313935383436373635-s62y83x4ls70
CSeq: 793 REGISTER
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:43977;transport=Tls>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:cb85e8b5-f3c6-4f4e-8543-00041394F2F1>"
Allow-Events: dialog, talk, hold, check-sync
X-Real-IP: 192.168.XXX.XXX
Supported: path, gruu
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="F5CD62E87E5D2C5E00000000F82F623C",uri="sip:tel.t-online.de",qop=auth,nc=00000008,cnonce="11bc39d2",response="c388a3cfe489115b7be137e302684c33",algorithm=MD5
Expires: 3600
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:43977 at Jan 25 16:35:43.598 (1028 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;received=217.232.50.93;rport=43977;branch=z9hG4bK-iaeg22n514yk
To: "04722XXXX" <sip:[email protected]-online.de>;tag=wglvwwrrgtwpck8tltsp84okg1e7jq6k
From: "04722XXXX" <sip:[email protected]-online.de>;tag=6v1bvu68rx
Call-ID: 3135373937313935383436373635-s62y83x4ls70
CSeq: 793 REGISTER
Contact: <sip:[email protected]:43977;transport=tls>;expires=660;q=1.0;reg-id=1;+sip.instance="<urn:uuid:cb85e8b5-f3c6-4f4e-8543-00041394F2F1>"
Contact: <sip:[email protected]:5060;user=phone;eribindingid=1569301269833232>;expires=1023;audio;+sip.instance="<urn:uuid:00000000-0000-0000-0000-34495b673ad0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
P-Associated-Uri: <sip:[email protected]-online.de>
P-Associated-Uri: <tel:+494722XXXX>
Path: <sip:217.0.25.34:5061;transport=tls;lr>
Supported: path
Supported: gruu
User-Agent: snomD765/10.1.49.11
Content-Length: 0
X-Real-Ip: 192.168.XXX.XXX
Allow-Events: dialog, talk, hold, check-sync

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:43977 at Jan 25 16:35:45.841 (1531 bytes):

INVITE sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;branch=z9hG4bK-fxpsk4vucyjw;rport
From: "04722XXXX" <sip:[email protected]-online.de>;tag=fqrc6r1axy
To: <sip:[email protected]-online.de;user=phone>
Call-ID: 313537393936363534353332373637-any6pmontgfp
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:43977;transport=Tls>;reg-id=1
X-Serialnumber: 00041394F2F1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="F5CD62E87E5D2C5E00000000F82F623C",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000009,cnonce="11bc39d2",response="b29cdd514dbb906c9d5641c3236ae5d2",algorithm=MD5
Content-Type: application/sdp
Content-Length: 487

v=0
o=root 730628241 730628241 IN IP4 217.232.50.93
s=call
c=IN IP4 217.232.50.93
t=0 0
m=audio 53376 RTP/AVP 8 9 0 3 99 112 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:gmXZxKDQ99EBsWWXDWsy+9JARkhwgAyiDQ4tL+xm
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:43977 at Jan 25 16:35:46.940 (498 bytes):

SIP/2.0 500 Service Unavailable
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;received=217.232.50.93;rport=43977;branch=z9hG4bK-fxpsk4vucyjw
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579966546m928450c539871330s1_2697553748-118236040
From: "04722XXXX" <sip:[email protected]-online.de>;tag=fqrc6r1axy
Call-ID: 313537393936363534353332373637-any6pmontgfp
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Retry-After: 3
Supported: timer
Content-Length: 0

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:43977 at Jan 25 16:35:46.945 (795 bytes):

ACK sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:43977;branch=z9hG4bK-fxpsk4vucyjw;rport
From: "04722XXXX" <sip:[email protected]-online.de>;tag=fqrc6r1axy
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579966546m928450c539871330s1_2697553748-118236040
Call-ID: 313537393936363534353332373637-any6pmontgfp
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:43977;transport=Tls>;reg-id=1
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="F5CD62E87E5D2C5E00000000F82F623C",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000010,cnonce="11bc39d2",response="712fb836a04ec7e8196e5edd6ded85f6",algorithm=MD5
Content-Length: 0

Für mich sieht es so aus als würde ich TLS nutzen. Demnach sind Telefonate ins Festnetz über TLS möglich. Nur nicht zu jeder Nummer. Warum auch immer.. wie ich dem Snom beibringen kann ganz ohne Verschlüsselung zu arbeiten ist mir noch nicht klar.

Meester Proper · 25 Jan 2020

Die Konfiguration ist doch völlig verdreht:
Als Mediaprofil wird RTP/AVP genutzt, es wird aber ein SDES-SRTP Crypto-Attribut mitgesendet. Was soll das sein?

Entweder wird ein SRTP-Profil wie RTP/SAVP mit Crypto-Attribut genutzt oder es wird gar nicht verschlüsselt.

InfectedChild · 25 Jan 2020

Was soll ich sagen.. ich habe lediglich die oben aufgeführten Werte gesetzt/verändert. Das sind also die default settings von Snom. Ich könnte das Telefon höchstens auf Werkseinstellungen zurücksetzen und neu konfigurieren. Kenne mich mit SIP nun auch nicht so aus, dass ich weißt wovon du redest. Deshalb hab ich mein Leid ja hier niedergeschrieben.

Ich könnte Screenshots von allen relevanten Config-Seiten hier anhängen. Vielleicht kannst du ja so erkennen wie man das gerade biegen könnte, bzw. was in den default settings falsch ist.

gehtdoch · 25 Jan 2020

Das SNOM macht optimistisches SRTP: AES-Key anbieten und gleichzeitig RTP/AVP anbieten. Jetzt kann sich der Peer überlegen, was er mit machen will - beides geht (aber SRTP wird nicht enforced). Das erste Gespräch läuft durch (man "einigt" sich auf unverschlüsseltes RTP - das zweite eben nicht, weil der Peer dieses Spielchen nicht unterstützt - das muss man z.B. bei easybell so einstellen, weil da nur in eine Richtung SRTP unterstützt wird. Asterisk kennt dafür die Option media_encryption_optimistic).

Die Lösung besteht also darin, beim SNOM die (optimistische) RTP-Verschlüsselung abzuschalten. Da gibt es sicher irgendwo einen Haken zu setzen.

Das SNOM macht auf jeden Fall kein Mediasec, das die Telekom benötigen würde, um SRTP zu fahren.

Meester Proper · 25 Jan 2020

Wird optimistisches SRTP nicht mit zwei m-lines, also RTP/AVP und RTP/SAVP realisiert?

gehtdoch · 25 Jan 2020

Meester Proper schrieb:
SIPS wird bei den Telekom-Produkten nicht unterstützt, lediglich SIP over TLS kann bei Vorliegen aller Voraussetzungen genutzt werden.

Danke Meester Proper für die Klarstellung - ich hätte da mal im Handbuch bis zum Ende lesen sollen

- da gibt es tatsächlich einen deutlichen Unterschied - wenn auch nur sehr kleinen (was die Sichtbarkeit angeht) - aber sehr großen, was die Auswirkung angeht. Ich werde das zukünftig nicht mehr vereinfacht synonym benutzen.

Meester Proper schrieb:
Wird optimistisches SRTP nicht mit zwei m-lines, also RTP/AVP und RTP/SAVP realisiert?

Hab mir gerade einen Trace angeschaut zu easybell.

Outbound call (hier wird verschlüsselt):
Nur die SDPs im Invite und in der Antwort von easybell:

Code:

Invite zu easybell
v=0
o=- 852258050 1580004000 IN IP4 xx.yyy.6.187
s=Asterisk
c=IN IP4 xx.yyy.6.187
t=0 0
m=audio 10078 RTP/AVP 9 8 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:7RzFyihT5LlGimXUd+CFviIooSYuuPNvquD9WXbX
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

Session Progress von easybell:
v=0
o=- 27074803 27074803 IN IP4 195.185.37.60
s=-
c=IN IP4 195.185.37.60
t=0 0
m=audio 31306 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=direction:both
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:p4VYF7+jLtinTasw0+8l0WuvyFaSXzdkVVXUiTaH

Inbound Call (hier wird nicht verschlüsselt):

Code:

Invite von easybell
v=0
o=- 0 0 IN IP4 195.185.37.60
s=-
c=IN IP4 195.185.37.60
t=0 0
m=audio 25842 RTP/AVP 9 8 103 104
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/8000
a=fmtp:103 0-15
a=rtpmap:104 telephone-event/16000
a=fmtp:104 0-15
a=direction:both
a=sendrecv
a=ptime:20
a=maxptime:30

200 OK zu easybell
v=0
o=- 0 1579972183 IN IP4 xx.yyy.6.187
s=Asterisk
c=IN IP4 xx.yyy.6.187
t=0 0
m=audio 10072 RTP/AVP 9 8 103
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/8000
a=fmtp:103 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

InfectedChild · 25 Jan 2020

Okay.. ich habe jetzt RTP Encryption deaktiviert (https://service.snom.com/display/wiki/user_srtp). Nun funktioniert es ausgehend mit Nummern die vorher nicht erreicht wurden. Aber wenn ich es richtig verstehe bietet das Snom der Gegenstelle nun gar keine Verschlüsselung mehr an und das Gespräch wird unverschlüsselt übertragen. Und das nur weil es Gegenstellen gibt die mit dem bloßen Angebot von SRTP schon nicht umgehen können? Ist sowas normal? Wie wird das sonst gehandled?

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:51.472 (1451 bytes):

INVITE sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;branch=z9hG4bK-cmpvgxgyiinp;rport
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
To: <sip:[email protected]-online.de;user=phone>
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:48333;transport=Tls>;reg-id=1
X-Serialnumber: 00041394F2F1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="8022DC13FC712C5E000000004407B045",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000007,cnonce="6b899885",response="fd416ad047d9132fe32f3fc8d0ca56f3",algorithm=MD5
Content-Type: application/sdp
Content-Length: 407

v=0
o=root 1640866070 1640866070 IN IP4 192.168.XXX.XXX
s=call
c=IN IP4 192.168.XXX.XXX
t=0 0
m=audio 54560 RTP/AVP 9 8 0 3 99 112 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:52.501 (539 bytes):

SIP/2.0 407 Proxy Authentication Required 02035034C
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;received=217.232.50.93;rport=48333;branch=z9hG4bK-cmpvgxgyiinp
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_792f514d0e1f830dd0dcea166e66e40c
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 1 INVITE
Content-Length: 0
Proxy-Authenticate: Digest nonce="D175B7BA2F762C5E00000000D1CB9422",realm="tel.t-online.de",algorithm=MD5,qop="auth",stale=true

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:52.506 (770 bytes):

ACK sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;branch=z9hG4bK-cmpvgxgyiinp;rport
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_792f514d0e1f830dd0dcea166e66e40c
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:48333;transport=Tls>;reg-id=1
Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="8022DC13FC712C5E000000004407B045",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000008,cnonce="6b899885",response="8edfebcd9ea3b13c3546bc1f1d4b621d",algorithm=MD5
Content-Length: 0

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:52.511 (1457 bytes):

INVITE sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;branch=z9hG4bK-juu8mpxttpzb;rport
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
To: <sip:[email protected]-online.de;user=phone>
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:48333;transport=Tls>;reg-id=1
X-Serialnumber: 00041394F2F1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="D175B7BA2F762C5E00000000D1CB9422",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000001,cnonce="126a7b7c",response="18bae5b0039f167bf294313ba20d5845",algorithm=MD5
Content-Type: application/sdp
Content-Length: 407

v=0
o=root 1640866070 1640866070 IN IP4 192.168.XXX.XXX
s=call
c=IN IP4 192.168.XXX.XXX
t=0 0
m=audio 54560 RTP/AVP 9 8 0 3 99 112 18 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:52.775 (331 bytes):

SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;received=217.232.50.93;rport=48333;branch=z9hG4bK-juu8mpxttpzb
To: <sip:[email protected]-online.de;user=phone>
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 INVITE
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:52.836 (530 bytes):

SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;received=217.232.50.93;rport=48333;branch=z9hG4bK-juu8mpxttpzb
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579972132m935030c540139065s1_3988593093-1257743353
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
Supported: timer
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:53.268 (720 bytes):

SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;received=217.232.50.93;rport=48333;branch=z9hG4bK-juu8mpxttpzb
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579972132m935030c540139065s1_3989236380-1
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
Supported: timer
Content-Length: 0
Allow-Events: message-summary
Allow-Events: refer
Allow-Events: ua-profile
Allow-Events: talk
Allow-Events: check-sync
Allow: NOTIFY, REFER, UPDATE, OPTIONS, BYE, ACK, CANCEL, INVITE, REGISTER

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:55.456 (721 bytes):

CANCEL sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;branch=z9hG4bK-juu8mpxttpzb;rport
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
To: <sip:[email protected]-online.de;user=phone>
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 CANCEL
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Reason: SIP;cause=487;text="Request terminated by user"
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="D175B7BA2F762C5E00000000D1CB9422",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000002,cnonce="126a7b7c",response="3175675386478e761663a547041712df",algorithm=MD5
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:55.761 (390 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;received=217.232.50.93;rport=48333;branch=z9hG4bK-juu8mpxttpzb
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579972132m935030c540139065s1_3989236380-1
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 CANCEL
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:55.763 (485 bytes):

SIP/2.0 487 Request Cancelled
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;received=217.232.50.93;rport=48333;branch=z9hG4bK-juu8mpxttpzb
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579972132m935030c540139065s1_3988593093-1257743353
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Supported: timer
Content-Length: 0

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:48333 at Jan 25 18:08:55.769 (802 bytes):

ACK sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;branch=z9hG4bK-juu8mpxttpzb;rport
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=p103t7cxy6
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579972132m935030c540139065s1_3988593093-1257743353
Call-ID: 313537393937323133313130363331-247vlkc30bog
CSeq: 2 ACK
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:48333;transport=Tls>;reg-id=1
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="D175B7BA2F762C5E00000000D1CB9422",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000003,cnonce="126a7b7c",response="13efaa72af2bfa0e5b3546c367e4922e",algorithm=MD5
Content-Length: 0

Meester Proper schrieb:
Um Verschlüsselung zu nutzen sind die MediaSec-Parameter nach 1TR114 nötig.

Mir ist gerade diese Option aufgefallen:

Wenn ich aber Mediasec und RTP Encryption auf on setze bekomme ich im SIP Trace sofort (bei allen Nummern):

SIP/2.0 403 Forbidden
Via: SIP/2.0/TLS 192.168.XXX.XXX:48333;received=217.232.50.93;rport=48333;branch=z9hG4bK-v0mjxym5n7pb
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_6n3kmddc2ntfoyeut79b6o1gwyvu3edd
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=6thph23a4c
Call-ID: 3135373939373335353936373532-bedrnu4ftudc
CSeq: 1 INVITE
Content-Length: 0

gehtdoch · 25 Jan 2020

InfectedChild schrieb:
Aber wenn ich es richtig verstehe bietet das Snom der Gegenstelle nun gar keine Verschlüsselung mehr an und das Gespräch wird unverschlüsselt übertragen.

Korrekt

InfectedChild schrieb:
Und das nur weil es Gegenstellen gibt die mit dem bloßen Angebot von SRTP schon nicht umgehen können? Ist sowas normal? Wie wird das sonst gehandled?

Du musst Deine Vorstellung, wie SIP über einen Provider funktioniert, korrigieren:
Dein SIP-Phone redet mit keinem Peer direkt - sondern immer über die SIP-Server der beteiligten Provider. Also bestimmen die, was Sache ist.

InfectedChild schrieb:
Wenn ich aber Mediasec und RTP Encryption auf on setze bekomme ich im SIP Trace sofort (bei allen Nummern):

SIP/2.0 403 Forbidden

-> Du musst den aktuellen Register beenden (Unregister) und dann einen neuen Register mit den Mediasec-Erweiterungen durchführen - danach sollte es gehen. Oder Telefon vom Netz nehmen und mindestens 20 Minuten (waren es glaube ich) warten (bis der Register ausgetimed ist).

Update: der Expire im Register 200 OK vom SIP-Server der Telekom ist 660 s (11 Minuten). Allerdings ist mir in der Vergangenheit aufgefallen, dass da auch noch etwas Karrenzzeit drauf gegeben wird. Mit 15-20 Minuten solltest Du auf der sicheren Seite sein.

InfectedChild · 25 Jan 2020

Das Snom zu rebooten hat schon gereicht!

Jetzt funktioniert es scheinbar mit allen Nummern - und das mit RTP Encryption ON, Mediasec ON.. und was ich noch angepasst habe:

RTP/SAVP war "off", was ich auf "optional" geändert habe. Snom gibt zu dazu folgende Erläuterung:

This setting is effective only when RTP encryption (SRTP) is also enabled and is used to specify whether the use of the RTP/SAVP profile by the phone should be off (for backward compatibility), optional or mandatory.When this setting is set to "mandatory" the phone will offer and accept only SDPs that contain m= lines with an audio profile of RTP/SAVP.When this setting is set to "optional", the phone will offer SDPs containing two m= lines, one with an audio profile of RTP/SAVP the other with an audio profile of RTP/AVP and it will accept SDPs containing m= lines with either profile. The RTP/SAVP profile, being the preferred one, is listed first.Since some SIP proxies cannot handle RTP/SAVP profiles or multiple m= lines this setting may also be turned off. In this case the phone will send SDPs containing RTP/AVP audio profiles only. Whether or not the crypto attribute is included depends on whether RTP encryption is on or off.

Note: When RTP encryption is turned off this setting has no effect.

Hört sich an als wäre das das Snom Pendant zu "optimistic SRTP", oder?

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:43.962 (2002 bytes):

INVITE sip:[email protected]-online.de;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;branch=z9hG4bK-gd2kt9s3003o;rport
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
To: <sip:[email protected]-online.de;user=phone>
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:44642;transport=Tls>;reg-id=1
X-Serialnumber: 00041394F2F1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec
Session-Expires: 3600
Min-SE: 90
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="DFDFBBBC2F822C5E00000000DBA3951F",uri="sip:[email protected]-online.de;user=phone",qop=auth,nc=00000004,cnonce="1e8ebcb3",response="7baed4c64abb6b27696afd0c1232223c",algorithm=MD5
Content-Type: application/sdp
Content-Length: 842

v=0
o=root 1514287399 1514287399 IN IP4 192.168.XXX.XXX
s=call
c=IN IP4 192.168.XXX.XXX
t=0 0
m=audio 58022 RTP/SAVP 9 0 8 3 99 112 18 101
a=3ge2ae:requested
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:xrXGhynmaqH2AYXmpKv3M24erHScVFfMxYOiTFMI
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
m=audio 58022 RTP/AVP 9 0 8 3 99 112 18 101
a=3ge2ae:requested
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:44.232 (331 bytes):

SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;received=217.232.50.93;rport=44642;branch=z9hG4bK-gd2kt9s3003o
To: <sip:[email protected]-online.de;user=phone>
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 1 INVITE
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:44.279 (529 bytes):

SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;received=217.232.50.93;rport=44642;branch=z9hG4bK-gd2kt9s3003o
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579975244m771618c540243998s1_2805462942-762575531
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
Supported: timer
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:44.747 (720 bytes):

SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;received=217.232.50.93;rport=44642;branch=z9hG4bK-gd2kt9s3003o
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579975244m771618c540243998s1_2806121786-1
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
Supported: timer
Content-Length: 0
Allow-Events: message-summary
Allow-Events: refer
Allow-Events: ua-profile
Allow-Events: talk
Allow-Events: check-sync
Allow: NOTIFY, REFER, UPDATE, OPTIONS, BYE, ACK, CANCEL, INVITE, REGISTER

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:49.484 (1240 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;received=217.232.50.93;rport=44642;branch=z9hG4bK-gd2kt9s3003o
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579975244m771618c540243998s1_2806121786-1
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
Session-Expires: 1800;refresher=uas
Supported: timer
Supported: replaces
Content-Type: application/sdp
Content-Length: 206
Session-ID: 64ae35ac7265f2031d06dd37b5334951
Authentication-Info: qop=auth,rspauth="d99359d811960f3d7110ff67d5ef8c4d",cnonce="1e8ebcb3",nc=00000004
Allow-Events: message-summary
Allow-Events: refer
Allow-Events: ua-profile
Allow-Events: talk
Allow-Events: check-sync
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 1729340099 2810828168 IN IP4 0.0.0.0
s=Mapping
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=ptime:20

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:49.492 (841 bytes):

ACK sip:[email protected]:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;branch=z9hG4bK-txyy6geragm2;rport
Route: <sip:217.0.25.34:5061;transport=tls;lr>
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579975244m771618c540243998s1_2806121786-1
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:44642;transport=Tls>;reg-id=1
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="DFDFBBBC2F822C5E00000000DBA3951F",uri="sip:[email protected]:5061;transport=tls",qop=auth,nc=00000005,cnonce="1e8ebcb3",response="b7086f83bc0e6f4f36d5b3cbbdc2eb67",algorithm=MD5
Content-Length: 0

Sent to Tls:217.0.25.34:5061 from Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:49.499 (841 bytes):

BYE sip:[email protected]:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;branch=z9hG4bK-om0a6t3ig3ij;rport
Route: <sip:217.0.25.34:5061;transport=tls;lr>
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579975244m771618c540243998s1_2806121786-1
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 2 BYE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:[email protected]:44642;transport=Tls>;reg-id=1
Proxy-Authorization: Digest username="[email protected]",realm="tel.t-online.de",nonce="DFDFBBBC2F822C5E00000000DBA3951F",uri="sip:[email protected]:5061;transport=tls",qop=auth,nc=00000006,cnonce="1e8ebcb3",response="cfbd0a8bc6df9e7239f11d9572f883f6",algorithm=MD5
Content-Length: 0

Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:49.710 (518 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;received=217.232.50.93;rport=44642;branch=z9hG4bK-om0a6t3ig3ij
To: <sip:[email protected]-online.de;user=phone>;tag=h7g4Esbg_p65551t1579975244m771618c540243998s1_2806121786-1
From: "+494722XXXX" <sip:[email protected]-online.de>;tag=ppwzxauf4x
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 2 BYE
Supported: timer
Supported: replaces
Content-Length: 0
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

Sehe ich es richtig, dass er nun SRTP nutzt wo es geht und sonst eben unverschlüsselt kommuniziert?

gehtdoch · 25 Jan 2020

InfectedChild schrieb:
Das Snom zu rebooten hat schon gereicht!

Wenn er in diesem Zusammenhang einen Unregister macht -> Ja

InfectedChild schrieb:
Jetzt funktioniert es scheinbar mit allen Nummern - und das mit RTP Encryption ON, Mediasec ON.. und was ich noch angepasst habe:

RTP/SAVP war "off", was ich auf "optional" geändert habe. Snom gibt zu dazu folgende Erläuterung:

-> muss dann mandatory sein

InfectedChild schrieb:
Hört sich an als wäre das das Snom Pendant zu "optimistic SRTP", oder?

Ja

InfectedChild schrieb:

Erfolgreicher SIP-Trace ins Festnetz mit SRTP und Mediasec ON und RTP/SAVP "optional"'

Code:

SDP vom ausgehenden Invite ist ok:
v=0
o=root 1514287399 1514287399 IN IP4 192.168.XXX.XXX
s=call
c=IN IP4 192.168.XXX.XXX
t=0 0
m=audio 58022 RTP/SAVP 9 0 8 3 99 112 18 101
a=3ge2ae:requested
^^^^^^^^^^^^^^^^^^^^
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:xrXGhynmaqH2AYXmpKv3M24erHScVFfMxYOiTFMI
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
m=audio 58022 RTP/AVP 9 0 8 3 99 112 18 101
a=3ge2ae:requested
^^^^^^^^^^^^^^^^^^^^ (hmm - wahrscheinlich wg. optimistisch)
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

[...]
Received from Tls:217.0.25.34:5061 on Tls:192.168.XXX.XXX:44642 at Jan 25 19:00:49.484 (1240 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.XXX.XXX:44642;received=217.232.50.93;rport=44642;branch=z9hG4bK-gd2kt9s3003o
To: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65551t1579975244m771618c540243998s1_2806121786-1
From: "+494722XXXX" <sip:[email protected]>;tag=ppwzxauf4x
Call-ID: 313537393937353234333535313332-6xkb09clzjq5
CSeq: 1 INVITE
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: <sip:217.0.25.34:5061;transport=tls;lr>
Session-Expires: 1800;refresher=uas
Supported: timer
Supported: replaces
Content-Type: application/sdp
Content-Length: 206
Session-ID: 64ae35ac7265f2031d06dd37b5334951
Authentication-Info: qop=auth,rspauth="d99359d811960f3d7110ff67d5ef8c4d",cnonce="1e8ebcb3",nc=00000004
Allow-Events: message-summary
Allow-Events: refer
Allow-Events: ua-profile
Allow-Events: talk
Allow-Events: check-sync
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 1729340099 2810828168 IN IP4 0.0.0.0
s=Mapping
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=ptime:20

=> Da wird nicht verschlüsselt.

=> obigen zitierten Trace angepasst und kommentiert

InfectedChild schrieb:
Sehe ich es richtig, dass er nun SRTP nutzt wo es geht und sonst eben unverschlüsselt kommuniziert?

Du brauchst jetzt keine optimistische Verschlüsselung mehr -> stell auf mandatory! Du redest immer nur mit der Telekom und nicht mit den Peers direkt (zumindest bei allem, was raus geht).

sonyKatze · 26 Jan 2020

Karsten, wow, danke für den Hinweis mit MediaSec! Ich wusste gar nicht, dass Snom bereits MediaSec kann. Das ist gerade mal eine Woche her, dass das geht. Muss meines mal wieder auspacken. Allerdings bringt Dir SDES-sRTP innerhalb von Telekom Deutschland wenig. Wie Du (auch) SIP-over-TLS ausschaltest, findest Du in diesem Thread…

Meester Proper schrieb:
Wird optimistisches SRTP nicht mit zwei m-lines, also RTP/AVP und RTP/SAVP realisiert?

Jain.
Vor knapp 15 Jahren gab es eine RFC, die nie fertig wurde. Dort war die Lösung RTP/AVP+crypto. Das haben damals dann alle so umgesetzt, Cisco, Nokia, Snom, … Mit der Zeit ist das in Vergessenheit geraten und einige validierende SIP-Parser verharten auf dem Standpunkt, dass das verboten sei. Daher kam das mit RTP/SAVP+RTP/AVP auf. Übrigens: Bitte nicht anderes herum, also RTP/AVP+RTP/SAVP. Dann kam RFC 8643 und hat das dann wieder/endlich festgeschrieben. Folglich geht beides. Jemand hat sich auch mal die Mühe gemacht, das für jeden Hersteller zu dokumentieren … genug Offtopic.

gehtdoch · 27 Jan 2020

sonyKatze schrieb:
Allerdings bringt Dir SDES-sRTP innerhalb von Telekom Deutschland wenig.

Verstehe ich jetzt nicht so ganz.
Klar, die Verschlüsselung geht aus gesetzlichen Gründen nur bis zum SIP-Server des Providers in D (da ist ja nicht nur die Telekom davon betroffen z.B.) - aber (neu verschlüsselt) auch noch bis zu einem Telekom-Peer (falls der auch Verschlüsselung aktiviert hat - wie ich z.B.).
Jeder Provider muss natürlich einen Client unverschlüsselt ansprechen, falls dieser keine Verschlüsselung unterstützt (derzeit sicher noch die Masse). Aber ich hoffe doch, dass das irgendwann mal anders wird - irgendwer muss ja anfangen.

Was mich hier viel mehr irritiert, ist die Tatsache, dass trotz aktiviertem Mediasec es bei der Telekom möglich ist, RTP unverschlüsselt zu verblasen - so wie es Karsten aktuell macht - ich hoffe, dass er das noch korrigiert oder schon korrigiert hat.

Im von Dir genannten

sonyKatze schrieb:
Link

ist die Info enthalten, dass man Easybell via secure.sip.easybell auch ohne optimistisches SRTP nutzen kann - das konnte ich hier nachvollziehen.
Traud hat übrigens auch einen Patch geliefert, mit dem Asterisk AES 256 unterstützt für SRTP. Easybell unterstützt AES 256 - die Telekom leider nicht. Für die Nutzung unter Asterisk bei Outbound Calls muss allerdings der Sourcecode mit dem folgenden Patch angepasst werden und mit einer zusätzlichen Compileoption Asterisk neu übersetzt werden:

Code:

$ cat res_srtp_aes_256.diff 
--- a/res/res_srtp.c    2020-01-26 11:09:04.981020000 +0100
+++ b/res/res_srtp.c    2020-01-26 11:10:36.342020000 +0100
@@ -1126,7 +1126,6 @@
                         * If you want to enable one of those defines, please, go for
                         * CFLAGS='-DENABLE_SRTP_AES_GCM' ./configure && sudo make install
                         */
-                               { len, 0, 30 },
 #if defined(HAVE_SRTP_GCM) && defined(ENABLE_SRTP_AES_GCM)
                                { AST_SRTP_CRYPTO_TAG_16, 0, AES_128_GCM_KEYSIZE_WSALT },
 #endif
@@ -1139,6 +1138,7 @@
 #if defined(HAVE_SRTP_192) && defined(ENABLE_SRTP_AES_192)
                                { len, AST_SRTP_CRYPTO_AES_192, 38 },
 #endif
+                               { len, 0, 30 },
                        };
                        struct ast_sdp_srtp *tmp = srtp;
                        int i;

Dann configure wie folgt ausführen:

Code:

CFLAGS='-DENABLE_SRTP_AES_256' ./configure ...

Mit dieser Option bietet Asterisk auch bei ausgehenden Calls einen AES 256 BIT-Key an (als primären Key). Ohne den Patch wird er als sekundärer Key angeboten - aber von Easybell dann nicht verwendet (die nehmen wohl nicht besten, sondern den ersten in der Liste der angebotenen Keys).

sonyKatze · 27 Jan 2020

Hui, da ist jemand tief in der Materie drin.

gehtdoch schrieb:
Verstehe ich jetzt nicht so ganz […] gesetzliche Gründe

Mit SDES-sRTP schützt Du den Weg von Dir zum SIP-Anbieter. Weil Karsten einen Telekom-Anschluss hat, ist er bereits „im“ SIP-Anbieter, weil gleich Netzanbieter. Er „schützt“ also lediglich zusätzlich die Strecke innerhalb seines Hauses bis zum DSLAM – fraglich, ob hier jemand Karsten angreift. Daher meine Einschätzung mit „wenig“. Ich befürchte Karsten will einfach nur sein Snom zum Laufen bekommen. Daher würde ich in seinem Szenario – Anschluss bei der Telekom Deutschland – auf SIP-over-TLS bzw. SDES-sRTP bzw. MediaSec verzichten. Karsten, möchtest Du auch verschlüsseln oder möchtest Du nur Dein Snom-Telefon nutzen?

Letzteres verstehe ich nicht so ganz. Die Diskussion hatte das IP-Phone-Forum schon mal … auch ich kenne kein Gesetz, dass uns Bürger verbietet zu verschlüsseln. Die Logik ist anders herum: Alles was die Netzanbieter haben, ist rauszugeben. Wenn es halt offen ist, war der Bürger schlicht „zu blöd“. Oder anders formuliert: Unsere Verfolgungsorgane arbeiteten auch im Bereich Informatik Jahrzehnte lang immer noch nach dem Prinzip „Täter machen Fehler“. Seit ein paar Jahren ist Deutschland auf den Trichter gekommen, dass das so nicht geht (und jetzt greift man direkt die Endgeräte an; ob das gut oder besser ist, wäre eine separate Betrachtung wert). Daher geht eine Verschlüsselung (mit SDES-sRTP) nicht aus gesetzlichen sondern aus technischen Gründen nur bis zum Anbieter. Aber, aber, für jemanden in einem fremden WLAN ist SDES-sRTP super.

In allen anderen Szenarien entweder auf DTLS-sRTP oder ZRTP setzen und die Fingerprints überprüfen – mit einem Innovaphone, Unify oder Router von DrayTek geht das so lala. Soweit ich weiß, leitet die Telekom Deutschland beides durch – wenn kein Session-Border-Controller auf der Wegstrecke liegt. Oder selbst SIP-Anbieter spielen (und die Telekom Deutschland nur noch für „Legacy“-Anschlüsse als Telefon-Anbieter nutzen); dann liefert SDES-sRTP nicht nur im fremden WLAN einen Nutzen.

Aber jetzt zurück zu Karsten: Willst Du Dein Snom „nur“ zum Laufen bekommen oder willst Du auch alles mitnehmen, also auch MediaSec?

gehtdoch · 27 Jan 2020

sonyKatze schrieb:
Mit SDES-sRTP schützt Du den Weg von Dir zum SIP-Anbieter.

Thema Verschlüsselung:
Allgemein: Alle Bereiche, die nicht unter eigener Kontrolle stehen, sind grundsätzlich nicht vertrauenswürdig. Ergo: Verschlüsselung ist angesagt. Verschlüsselung ist aber erst dann weitestgehend vertrauenswürdig, wenn der Schlüssel ausschließlich bei den Beteiligten liegt.

Konkret VoIP: Was man eigentlich haben will, ist End2End-Verschlüsselung zwischen den beteiligten Clients. Das kann leider über einen Provider nicht unterstützt werden. Verschlüsselt ist immer nur bis zum Server des Providers (u.a. aus technischen und rechtlichen Gründen - aus beiden Richtungen gesehen). In soweit ist Dein Einwand "Allerdings bringt Dir SDES-sRTP innerhalb von Telekom Deutschland wenig." also teilweise berechtigt.

Trotzdem halte ich selbst das immer noch für besser, weil wenigstens Teilstrecken verschlüsselt sind und damit die Möglichkeit für potentielle Angriffe reduziert ist bzw. für einen Außenstehenden deutlich erschwert ist (es gibt ja nicht nur den bösen Staat).

Die Betrachtung eines Calls über Providergrenzen hinweg ist natürlich nochmal eine ganz andere Nummer.

Deutlich "sicherere" Kommunikation würde man nur erreichen, wenn man zwischen zwei eigenen Servern / Devices direkt unter Umgehung eines VoIP-Providers durchgängig verschlüsselt kommuniziert.

sonyKatze schrieb:
Weil Karsten einen Telekom-Anschluss hat, ist er bereits „im“ SIP-Anbieter, weil gleich Netzanbieter. Er „schützt“ also lediglich zusätzlich die Strecke innerhalb seines Hauses bis zum DSLAM

Im DSLAM endet der Call aber wohl eher nicht - oder möchtest Du damit sagen, dass bereits dort wieder entschlüsselt wird?

sonyKatze schrieb:
Letzteres verstehe ich nicht so ganz. Die Diskussion hatte das IP-Phone-Forum schon mal … auch ich kenne kein Gesetz, dass uns Bürger verbietet zu verschlüsseln. Die Logik ist anders herum: Alles was die Netzanbieter haben, ist rauszugeben.

Genau so wollte ich das auch verstanden wissen. Bringt eben am Ende des Tages nicht so viel, solange es aus technischen Gründen einen man-in-the-middle gibt - wie bei VoIP via VoIP-Provider.

Bedenkt man allerdings, dass die überwiegende Anzahl der Angriffe jeweils aus dem eigenen Firmennetz heraus kommt (mal eben geschwind den Datenstrom aus einem Switch ausgeleitet z.B.) macht selbst die "man-in-the-middle"-Verschlüsselung wieder Sinn, weil sich hoffentlich die berechtigten Personen auf die klassischen Netzelemente von denen auf die SIP-Server unterscheiden.
Aber wahrscheinlich ist es Wunschdenken, dass der Datenstrom lediglich auf dem gleichen Server ent- und wieder verschlüsselt wird - so dass auch am Ausgang des Servers wieder ein verschlüsselter Datenstrom vorhanden ist (so dass nur dieser eine Server die Keys kennt und damit nur Personen die Möglichkeit zur Entschlüsselung bekommen, die Zugriff auf diesen Server haben und somit an die Keys kommen könnten - falls diese nicht noch sonst wohin ausgeleitet werden).

sonyKatze schrieb:
In allen anderen Szenarien entweder auf DTLS-sRTP oder ZRTP setzen und die Fingerprints überprüfen – mit einem Innovaphone, Unify oder Router von DrayTek geht das so lala. Soweit ich weiß, leitet die Telekom Deutschland beides durch – wenn kein Session-Border-Controller auf der Wegstrecke liegt. Oder selbst SIP-Anbieter spielen (und die Telekom Deutschland nur noch für „Legacy“-Anschlüsse als Telefon-Anbieter nutzen); dann liefert SDES-sRTP nicht nur im fremden WLAN einen Nutzen.

Asterisk soll ja auch DTLS-sRTP unterstützen.
DTLS-sRTP baut ja eine direkte Verbindung zw. den beiden Devices unter Umgehung der Voice-Komponenten der Provider auf. Dies setzt voraus, dass diese auch direkt zu erreichen sind via Internet. Dürfte bei Pseudointernetprovidern (via NAT) ziemlich schwierig werden.

"SIP/2.0 500 Service Unavailable" ausgehend an Snom D765 über Magenta M Hybrid (Speedport Pro) bei bestimmten Nummern

Neuer User

Mitglied

Neuer User

Mitglied

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Mitglied

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

IPPF-Promi

Mitglied

IPPF-Promi

Mitglied

Statistik des Forums