Für die erfolgreiche Nutzung einer verschlüsselten VoIP-Verbindung sind neben einer TLS Verbindung für die SIP-Signalisierung und SRTP für die Verschlüsselung der Sprache noch weitere zusätzliche SIP Header und SDP Attribute notwendig.
Bei der Registrierung (SIP REGISTER) wird durch die zusätzlichen SIP Header der Plattform die Nutzung der Verschlüsselungsart mitgeteilt. Beim Gesprächsaufbau (SIP INVITE) und bei der Annahme von Gesprächen (SIP Response) muss die Verschlüsselungsart und die Reichweite der Verschlüsselung (Edge zu Access-Edge, Verschlüsselung zwischen TK-Anlage und Registrierungsserver) enthalten sein.
Die SIP Header orientieren sich an einem IETF Draft (https://tools.ietf.org/html/draft-dawes-sipcore-mediasec-parameter-11), sind aber als statische Ergänzung der SIP Signalisierung zu sehen.
SIP REGISTER
1) Beim initialen REGISTER ohne Authentication Challenge sind die SIP Header
- Security-Client: sdes-srtp;mediasec
- Proxy-Require: mediasec
- Require: mediasec
erforderlich.
2) Die Plattform antwortet mit 401 UNAUTHORIZED. In dieser SIP Response sind die SIP Header
- Security-Server: msrp-tls;mediasec
- Security-Server: sdes-srtp;mediasec
- Security-Server: dtls-srtp;mediasec
enthalten, welche die möglichen Verschlüsselungsarten wiedergeben.
3) Beim anschließenden REGISTER mit Authentication Challenge müssen neben den ursprünglich im initialen REGISTER geschickten SIP Headern
- Security-Client: sdes-srtp;mediasec
- Proxy-Require: mediasec
- Require: mediasec
zusätzlich die SIP Header
- Security-Verify: msrp-tls;mediasec
- Security-Verify: sdes-srtp;mediasec
- Security-Verify: dtls-srtp;mediasec
ergänzt werden.
Nach RFC 3261 können die Security-Verify Header auch zusammengefasst werden und als
- Security-Verify: msrp-tls;mediasec,sdes-srtp;mediasec,dtls-srtp;mediasec
im REGISTER mit Authentication Challenge geschickt werden.
Beispiel:
Download als Textdatei