Telekom All IP Privat endlich erfolgreiche Registierung SSL/TLS möglich

[gehtdoch]

Ich muss mich leider korrigieren, es werden auch weiterhin die speziellen Header, wie in 1TR114 beschrieben, benötigt. Die beabsichtigte interne Manipulation konnte nicht vorgenommen werden, daher muss das Endgerät dies weiterhin hinzufügen.

Ich versuche gerade, eine Implementierung in Asterisk vorzunehmen. Dabei stoße ich auf folgendes Problem mit dem ich nicht recht umzugehen weiß.

Zunächst läuft der REGISTER wie erwartet durch. Ich kann dann auch eingehende Calls verschlüsselt annehmen. Soweit so gut.

Dann kurz vor Ende des EXPIRE löst Asterisk wieder ein REGISTER aus, welches die folgenden HEADER enthält:
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec

Darauf reagiert der T-Server mit
SIP/2.0 494 Security Agreement Required
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec

Das gleiche Bild ergibt sich beim OPTIONS header.

Wie soll darauf jeweils reagiert werden? Beim 494 REGISTER fehlt z.B. der WWW-Authenticate-Header, so dass nicht mit einem REGISTER mit authorization reagiert werden kann.

 

[Meester Proper]

Wird denn die selbe TCP/TLS-Session für die neue Registrierung / Re-Registrierung verwendet?

 

[gehtdoch]

Ja - durchaus! Ich mache das daran fest, dass im Wireshark-Trace keine neue TLS-Session aufgebaut wurde bzw. die TCP-Session unverändert ist.
Die TCP-Session wird gemäß Wireshark und Timestamps aus Wireshark / asterisk-Log erst einige Zeit nach der erfolglosen Re-Registrierung beendet - und zwar vom T-Server (nicht von mir) - wahrscheinlich dann, wenn der T-Server mangels Re-Register den Client für tot hält.
Zwischen dem erfolglosen Re-Register und dem Abbruch seitens des T-Servers gehen Calls noch in beide Richtungen. Asterisk baut die Verbindung nach der Trennung durch den T-Server dann zwar 5-7 Sekunden später wieder auf - aber das klappt dann trotzdem nicht mehr mit der Registrierung (zumal davon auch kein Register abgeleitet wird).
Seltsamerweise hat der Re-Register auch schon zweimal funktioniert - warum auch immer.

Die Frage ist eben: wie soll man auf 494 Security Agreement Required reagieren und / oder besser: wie verhindert man es? Was schmeckt da dem T-Server nicht?

 

[gehtdoch]

Hier mal ein typisches Beispiel:

[2019-05-27 12:19:28] VERBOSE[2277] res_pjsip_logger.c: <--- Transmitting SIP request (723 bytes) to TLS:217.0.20.195:5061 --->
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/TLS 3.3.3.3:5061;rport;branch=z9hG4bKPj39f4e99e-9bf6-4da0-b946-6de2c48389ad;alias
From: <sip:[email protected]>;tag=261e2dd1-aa16-4989-8f76-269b13306a50
To: <sip:[email protected]>
Call-ID: b394d07d-cf88-4aa9-8b6f-2affc35f43ea
CSeq: 56264 REGISTER
Contact: <sip:[email protected]:5061;transport=TLS;line=ibghcpy>
Expires: 660
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec
Route: <sip:tel.t-online.de>
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.3.0)
Content-Length:  0


[2019-05-27 12:19:28] VERBOSE[2276] res_pjsip_logger.c: <--- Received SIP response (726 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 401 Unauthorized 11030230348
Via: SIP/2.0/TLS 3.3.3.3:5061;received=3.3.3.3;rport=44073;branch=z9hG4bKPj39f4e99e-9bf6-4da0-b946-6de2c48389ad;alias
To: <sip:[email protected]>;tag=h7g4Esbg_71d753d906f1f06bf0d805364abaa2f4
From: <sip:[email protected]>;tag=261e2dd1-aa16-4989-8f76-269b13306a50
Call-ID: b394d07d-cf88-4aa9-8b6f-2affc35f43ea
CSeq: 56264 REGISTER
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec
Service-Route: <sip:217.0.20.195:5061;transport=tls;lr>
WWW-Authenticate: Digest realm="tel.t-online.de",nonce="B0802885BCB9EB5C00000000C0E8A120",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0


[2019-05-27 12:19:28] VERBOSE[2277] res_pjsip_logger.c: <--- Transmitting SIP request (1106 bytes) to TLS:217.0.20.195:5061 --->
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/TLS 3.3.3.3:5061;rport;branch=z9hG4bKPja73e8966-6554-412b-adcf-a4c90ffb5a68;alias
From: <sip:[email protected]>;tag=261e2dd1-aa16-4989-8f76-269b13306a50
To: <sip:[email protected]>
Call-ID: b394d07d-cf88-4aa9-8b6f-2affc35f43ea
CSeq: 56265 REGISTER
Contact: <sip:[email protected]:5061;transport=TLS;line=ibghcpy>
Expires: 660
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.3.0)
Authorization: Digest username="+4912345678910", realm="tel.t-online.de", nonce="B0802885BCB9EB5C00000000C0E8A120", uri="sip:tel.t-online.de", response="1bdd378add948a2bdf52aaf9f3f1a8c1", algorithm=MD5, cnonce="23cae1aa-4359-431d-b2e4-4abcd335c45e", qop=auth, nc=00000001
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec
Route: <sip:tel.t-online.de>
Content-Length:  0


[2019-05-27 12:19:28] VERBOSE[2276] res_pjsip_logger.c: <--- Received SIP response (784 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 3.3.3.3:5061;received=3.3.3.3;rport=44073;branch=z9hG4bKPja73e8966-6554-412b-adcf-a4c90ffb5a68;alias
To: <sip:[email protected]>;tag=h7g4Esbg_71d753d906f18883c0d805364b4310dd
From: <sip:[email protected]>;tag=261e2dd1-aa16-4989-8f76-269b13306a50
Call-ID: b394d07d-cf88-4aa9-8b6f-2affc35f43ea
CSeq: 56265 REGISTER
Contact: <sip:[email protected]:5061;transport=tls;line=ibghcpy>;expires=660
P-Associated-Uri: <sip:[email protected]>
P-Associated-Uri: <tel:+4912345678910>
Service-Route: <sip:217.0.20.195:5061;transport=tls;lr>
Content-Length: 0
Authentication-Info: qop=auth,rspauth="6c111700633ab308e38cb9de9eb04c94",cnonce="23cae1aa-4359-431d-b2e4-4abcd335c45e",nc=00000001

Nach Abluaf des EXPIRE:

[2019-05-27 12:26:03] VERBOSE[2277] res_pjsip_logger.c: <--- Transmitting SIP request (723 bytes) to TLS:217.0.20.195:5061 --->
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/TLS 3.3.3.3:5061;rport;branch=z9hG4bKPj0aadbd2a-68fc-4e94-ad6d-50de8eb7d688;alias
From: <sip:[email protected]>;tag=4deb31f1-b534-46e9-a7ed-8d406391ca8f
To: <sip:[email protected]>
Call-ID: b394d07d-cf88-4aa9-8b6f-2affc35f43ea
CSeq: 56266 REGISTER
Contact: <sip:[email protected]:5061;transport=TLS;line=ibghcpy>
Expires: 660
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec
Route: <sip:tel.t-online.de>
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.3.0)
Content-Length:  0


[2019-05-27 12:26:04] VERBOSE[2276] res_pjsip_logger.c: <--- Received SIP response (529 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 494 Security Agreement Required
Via: SIP/2.0/TLS 3.3.3.3:5061;received=3.3.3.3;rport=56293;branch=z9hG4bKPj0aadbd2a-68fc-4e94-ad6d-50de8eb7d688;alias
To: <sip:[email protected]>;tag=iu2mxrm2ylm6ruymhrz3drufp
From: <sip:[email protected]>;tag=4deb31f1-b534-46e9-a7ed-8d406391ca8f
Call-ID: b394d07d-cf88-4aa9-8b6f-2affc35f43ea
CSeq: 56266 REGISTER
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec
Content-Length: 0

Was aus meiner Sicht fehlt im 494 ist der WWW-Authenticate-Header. Wenn es in extremst seltenen Fällen mal funktioniert, kommt auf das Re-Register tatsächlich wie zu Beginn ein 401 / Unauthorized mit einem Auth-Header. Dann funktioniert es auch sofort (wie immer am Anfang).

Hoffe das hilft weiter, das Problem einzugrenzen.

 

[gehtdoch]

So, Problem gelöst. Der Ablauf ist wie folgt:

1. Initialer Register
Request

REGISTER
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec

Response:

401 Unauthorized
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec
WWW-Authenticate: ...

Request:

REGISTER
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec
Authorization: ...
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec

=> Wichtig ist hier die Reihenfolge der letzten 3 Header.

Response:

200 OK

2. Re-Register nach Expire
Request

REGISTER

(ganz normal)

Response (Variante a)

200 OK

Response (Variante b)

494 Security Agreement Required
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec

Request

REGISTER
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec

(diese Header müssen in dieser Reihenfolge vorhanden sein)

Response

401 Unauthorized
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec
WWW-Authenticate: ...

Request

REGISTER
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec
(die obigen 3 Header müssen in dieser Reihenfolge vorhanden sein)
Authorization: ...

Response

200 OK

OPTIONS:
Wenn unverändert ausgeführt, bekommt man diese Antwort, solange man einen gültigen Register besitzt:

SIP/2.0 494 Security Agreement Required
CSeq: 21671 OPTIONS
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec

Will man ein 200 OK wird man vermutlich im Request wieder die 3 Security-Verify-Header einsetzen müssen - habe ich aber noch nicht getestet.

Wenn kein gültiger Register vorhanden ist:

403 Forbidden
CSeq: 4392 OPTIONS

Damit das ganze dann auch genutzt werden kann (z.B. in Asterisk - Asterisk kann das aber derzeit nicht), muss SDES-Verschlüsselung für RTP aktiviert sein (in FreePBX: Media Encryption: "SRTP via in-SDP" bzw. in asterisk direkt: media_encryption=sdes). Damit können bereits eingehende Calls verschlüsselt entgegengenommen werden.

Für ausgehende Calls müssen im INVITE noch folgende Voraussetzungen erfüllt sein:

Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec

(Reihenfolge beachten)

Sowie die Ergänzung im SDP (zu dem, was für eine SDES-basierte Verschlüsselung sowieso nötig ist)

a=3ge2ae:requested

 

[Meester Proper]

Ich wüsste nicht, dass man bei den MSN-basierten Produkten eine erfolgreiche Antwort (=200OK) auf einen OPTIONS-Request bekommt.

 

[gehtdoch]

Vorausgesetzt, man geht zum korrekten Server (gleicher Server wie der, bei dem man sich registriert hat), ist das schon so, dass man ein 200 OK bekommt. Zumindest sagen das alle meine Traces bisher. Eine 100% Aussage kann ich aber nicht machen, weil ich nicht 100% trace.

Asterisk hat allerdings selbst mit der aktuellen 16er-Version ein Problem damit, sicherzustellen, dass für alle Aktionen immer nur der Server verwendet wird, bei dem er sich auch registriert hat (das sicherzustellen ist schlicht nicht programmiert). Bis zur Version 13 konnte Asterisk mit den multiplen SRV-Einträgen quasi gar nicht umgehen, seit der Version 14 wird immerhin gezielt nach Prio ausgewählt. Wenn die sich aber ändert bei einem Server (was ja durchaus Teil des Betriebskonzeptes sein dürfte), hat das für Asterisk keine weiteren Auswirkungen - das merkt er nicht mal. Das merkt nur der User, wenn der Call nicht mehr funktioniert, weil das INVITE an den falschen Server geht. Dauert dann eben bis zu knapp 11 Minuten, bis das wieder passt (weil alle ca. 11 Minuten ein ReRegister stattfindet).

 

[gehtdoch]

Wie erwartet bekomme ich ein 200 OK auf einen OPTIONS Request, nachdem auch hier im Request die magischen mediasec-Header drangehängt wurden.

 

[Meester Proper]

Ok, dann scheint sich mittlerweile das Verhalten des MMTel verändert zu haben.

 

[qupfer2]

Ich würdem ich mal hier kurz einklinken, da hier scheinbar Leute mit Ahnung zum Thema FreePBX mit Telekom sind...hoffe das ist okay.
Ich nutze die FreePBX Distro (FreePBX 14.0.11 mit Asterisk 15.7.2) an einem Telekom Deutschlan LAN Voice/Data Start Tarif.

Aktuell ist alles ganz altmodisch auf SIP/RTP via UDP eingestellt. Das Telekom und Tls-SIP als auch SRTP nicht ganz trivial sind, habe ich schon mitbekommen. Aber je nach dem wo man liest, scheint das eine oder andere generell nicht möglich zu sein, oder dann irgendwie doch :-D

Daher wolte ich Fragen, ob da jemand es zusammenfassen kann, was zur Zeit geht, was beachtet werden muss etc.?
Wenn ich das alles so lese, soll ja SIP via TLS problemlos gehen. Aber sobald ich auf TLS umstelle, bekomme ich immer ein Rejected. Weiß aber auch nicht so genau, wie ich das "besser" debuggen kann. Der TLS Handsharke scheint noch sauber zu klappen. Da ich an der Konfig sonst nichts weiter geändert habe, (außer Port und Transport), weiß ich auch nicht, was da falsch sein könnte?

Aber "wichtiger" im Sinne der Verschlüsselung wäre ja eh der SRTP Stream, der ja noch problematischer sein soll. Gibt es da schon lösungen das mit Asterisk oder gar via FreePBX Gui hinzubekommen? :-D

Edit: Das TLS Problem habe ich lösen können. Die Auto-Generierte Server-URI (sip:tel.t-online.de:5061) mag die Telekom scheinbar nicht. Setzen auf sip:tel.t-online.de brachte dann den Erfolg. Die Client-URI kann wohl weiterhin den Port enthalten.

 

[gehtdoch]

Daher wolte ich Fragen, ob da jemand es zusammenfassen kann, was zur Zeit geht, was beachtet werden muss etc.?

Für SIPS:

Asterisk 13 und FreePBX 13: hier.
Asterisk 16 und FreePBX 14:
Im Prinzip gleich, nur mit dem Unterschied, dass FreePBX 14 die line-Option jetzt per Default unterstützt, ohne dass man was tun muss (dadurch fällt das Gewurstel mit dem manuellen Anteil weg). Hier am Beispiel All-IP - für andere Verträge müssen evtl. andere Server eingesetzt werden.

pjsip-Einstellungen -> General

Username: +49Rufnummer
Authentifizierung: Outbound
Registration: Senden
SIP-Server: tel.t-online.de
SIP Server Port: 5061
Transport: 0.0.0.0-tls

pjsip-Einstellungen -> Erweitert

DTMF Mode: RFC 4733

Kontaktbenutzer: +49Rufnummer
From Domain: tel.t-online.de
From User: +49Rufnummer
Client URI: sip:[email protected]
Server URI: sip:tel.t-online.de
AOR Contact: sip:[email protected]
Outbound Proxy, AOR Contact, AOR, Media Address bleibt leer.

In der pjsip.transports_custom_post.conf noch folgenden Eintrag rein machen:

[0.0.0.0-tls](+)
method=tlsv1_2
tos=0xb8

In der pjsip.endpoint_custom_post.conf noch folgenden Eintrag machen:

[Name der Hauptleitung](+)
tos_audio=0xb8

Wer SRTP möchte, muss den MEDIASEC-Patch anwenden (der BIN-Link enthält den Patch). Das ist aber nur was für Fortgeschrittene. Achtung: anders als das Threadsubject vermuten lässt, ist der Patch für Asterisk 16 (vielleicht geht er aber auch für 13).

 

[qupfer2]

Danke!!!!
Scheint zu funktionieren. Ist abzusehen, ob der mediasec Patch irgendwann(TM) auch offiziell in Asterisk eingepflegt wird? Aktuell ist es für mich nur Spielerei.

 

[gehtdoch]

Ich gehe nicht davon aus, dass das integriert wird, weil

• architektonisch grundsätzlich zur pjsip-Library gehörend
• grundsätzlich kaum Interesse an MEDIASEC vorhanden ist - wer braucht das schon?

Du musst Dich also wahrscheinlich bis auf Weiteres mit der Spielerei zufrieden geben, wenn Du verschlüsselt mit Asterisk unterwegs sein willst. Zumindest bei mir funktioniert es bis dato klaglos.

 

[qupfer2]

• architektonisch grundsätzlich zur pjsip-Library gehörend

Naja, wenn es in die pjsip kommen würde und die dann von asterisk genutzt wird, ist mir dass eigentlich ebenso recht.

• grundsätzlich kaum Interesse an MEDIASEC vorhanden ist - wer braucht das schon?

Doch alle, die SRTP in Kombination mit Asterisk und Telekom nutzen wollen? Oder habe ich da was falsch verstanden? Und ich denke, da wird der Bedarf steigen. Anderseits werden die wenigsten wohl ein Stock-Asterisk verwenden sondern eines der hüber(en), samt Support ala 3CX und co. Da wird dann vermutlich im Zweifel der jeweilige Hersteller den Patch einpflegen oder ähnliches.

Wie dem auch sei, privat werde ich wohl auf SRTP umstellen. Im Büro vorerst alles beim alten belassen. Aber dennoch Danke für die Hilfestellung und auch für die Aufklärung. Den Patch habe ich mir aber auch erstmal gut gesichert :-D

 

[Meester Proper]

Wer SRTP möchte, muss den MEDIASEC-Patch anwenden (der BIN-Link enthält den Patch). Das ist aber nur was für Fortgeschrittene. Achtung: anders als das Threadsubject vermuten lässt, ist der Patch für Asterisk 16 (vielleicht geht er aber auch für 13).

Hast du auch geprüft, ob die Signalisierung bei leeren INVITEs (also ohne SDP Offer) korrekt funktioniert? Das lässt sich leicht prüfen in dem man die 116116 anruft. Nach dem 200 OK werden dort nämlich RE-Invites ohne Offer versendet.

Dort dürfen dann keine neuen Crypto-Keys verwendet werden (im 200 OK mit SDP Offer) und meine Wissens müssen die Security-Verify Header versendet werden (ebenfalls im 200OK).

 

[gehtdoch]

Ein super Hinweis! Danke! Das passt tatsächlich nicht! Da wird als Antwort auf das ReInvite ein neuer Key im SDP mitgeschickt. Der erwähnte Patch macht an der Stelle nichts - der verwendet das implementierte SRTP-SDES-handling.

Der SIP/2.0 200 OK auf den ReInvite mit dem neuen Key im SDP wird vom T-Server aber mit einem ACK quittiert.

Ich habe mir das Gleiche via easybell und ebenfalls Verschlüsselung angeschaut. Da funktioniert es problemlos - die schicken aber auch keinen ReInivite (leider) - somit kann das Problem hier grundsätzlich nicht auftreten.

Muss ich mal sehen, was sich da machen lässt. Irgendwie sieht mir dieses Verhalten telekomspezifisch aus - andernfalls wäre es ein Bug in asterisk / pjsip.

 

[Meester Proper]

Richtig, ein ACK kommt. Bei meinem Test mit einem anderen Endgerät war dort aber keine SDP Answer enthalten. Damit ist der SDP Offer/Answer Zyklus nicht korrekt abgeschlossen. Bei meinem Test empfing ich auch kein RTP mehr.

Bei einem Call via Easybell kann es sein, dass die Verbindung noch über eine ISDN-Interconnection geht oder, wenn es doch schon via SIP-Interconnection läuft noch einmal über einen PSTN/ISDN-Loop geschickt wird, um das Re-Invite ohne SDP Offer zu umgehen. Das mögen nämlich einige VoIP-Anbieter überhaupt nicht, obwohl es vollkommen RFC3261-konform ist..

 

[gehtdoch]

Richtig, ein ACK kommt. Bei meinem Test mit einem anderen Endgerät war dort aber keine SDP Answer enthalten. Damit ist der SDP Offer/Answer Zyklus nicht korrekt abgeschlossen. Bei meinem Test empfing ich auch kein RTP mehr.

Exakt das kann ich hier auch beobachten.
Der Witz ist nun aber: das geht ohne Medienverschlüsselung / ohne Mediasec-Patch genauso wenig mit asterisk 16 / pjsip.
Der ReInvite ohne SDP wird mit einem 200 OK / sendrecv beantwortet, der einen SDP enthält, der die Codecs entsprechend dem vorhergehenden 200 OK der Telekom enthält. Aber auch da bekomme ich nur ein ACK ohne SDP als Antwort von der Telekom. An der Medienverschlüsselung kann es ja hier nicht mehr liegen. Da ist was anderes grundsätzlich falsch.

 

[gehtdoch]

So, nun eine detaillierte Analyse (ohne Verschlüsselung und der Einfachheit halber auch mit deaktiviertem 100rel):

<-- INVITE sip:[email protected] SIP/2.0
    m=audio 10084 RTP/AVP 9 8 0 101
    a=rtpmap:9 G722/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20
    a=maxptime:150
    a=sendrecv

--> SIP/2.0 100 Trying
--> SIP/2.0 183 Session Progress
--> SIP/2.0 200 OK
    m=audio 9248 RTP/AVP 8 101
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    a=sendrecv

--> ACK sip:[email protected]:5061;transport=tls SIP/2.0

Bis hierher ist alles gut. Die Verbindung steht. RTP in beide Richtungen vorhanden! Dann kommt der ReInvite ohne SDP

--> INVITE sip:[email protected]:5061;transport=tcp SIP/2.0
<-- SIP/2.0 200 OK
    m=audio 10084 RTP/AVP 8 101
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20
    a=maxptime:150
    a=sendrecv

--> ACK sip:[email protected]:5061;transport=tcp SIP/2.0

Welchen Sinn hat das ReInivte an der Stelle überhaupt? Die Verbindung stand doch schon!
Aus SDP-Sicht wird hier ein late (oder delayed) offer gefahren, welches den SDP dann im ACK erwartet (wie von Dir beschrieben).

Könnte es sein, dass der Telekomserver sich an dem a=fmtp:101 0-16 stört? In seinem vorherigen 200 OK hat er ja lediglich a=fmtp:101 0-15 angeboten.

 

[Meester Proper]

Ich schätze mal, dass hier ein SIP-Applikationsserver zum Einsatz kommt, der diesen Call Flow anwendet, nach dem er nach dem 200 OK "eingeschleift" wird.
Der Call Flow ist genauso wie in RFC3275 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) beschrieben.

Mit Fritzbox und X-Lite funktioniert es übrigens. Hier werden im 200 OK auf das Re-Invite nicht nur die Codecs aus dem 200 OK wiederholt, sondern alle Codecs aus dem initialen Invite.

Wie sehen die o-lines in deinem Invite und dem 200 OK als Antwort auf das ankommende Invite aus? Zählt die Versionsnummer korrekt hoch?