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

[koyaanisqatsi]

denn warum sollte man die Kommunikation nicht verschlüsseln

Nun, das hängt ziemlich stark vom Fragesteller ( Perspektive: Individuum vs Institution ) ab.

 

[gehtdoch]

Edit: mit SRTP gehts wieder
Edit2: Habe auch den sdp Patch mit drinnen, aber bei der 116116 höre ich dennoch nichts?!

Prima - scheinbar ist es jetzt tatsächlich so, dass SIPS ohne SRTP nicht mehr unterstützt zu werden scheint.

Was 116116 angeht: bist Du sicher, dass der Patch auch wirklich drin ist? Habe gerade mehrfach getestet hier - hat nach wie vor immer funktioniert. Braucht so ungefähr 2-4 Sekunden nach dem ersten 200 OK (vielleicht auch etwas länger?), bis die Ansage kommt - also nicht ungeduldig werden.

Andererseits ist mir jetzt aufgefallen, dass der Patch nicht ganz so zieht, wie ich eigentlich erwartet hätte, da die Session nicht grundsätzlich hochgezählt wird, obwohl der Code ausgeführt wird (das war von Anfang an so).

EDIT 10.8.2019 - 12:03 Uhr:
Neue Version für einen SDP-Session-QuickFix. Basiert auf Asterisk 16.x in Verbindung mit pjsip.

Da scheint was im Zusammenspiel asterisk <-> pjsip nicht so zu laufen, wie von mir erwartet. Es stellt sich de facto so dar (ist auch aus meinen früheren Traces zu erkennen, die ich hier gepostet habe - hier mit den Werten von früher zur besseren Nachvollziehbarkeit), dass zwar die SDP-Version des relevanten Invite (Invite + Auth) von allen folgenden SDP-Versionen abweicht, aber die OKs auf die ReInvites wieder die Version vom initialen Invite haben (obwohl die beiden OK-SDPs zum initialen Invite SDP abweichen). Ich muss da nochmal genauer schauen, warum das nicht zieht wie erwartet - eigentlich sollte die Version jeweils um 1 ansteigen - der Debug-Code zeigt hier, dass der Code ausgeführt wird:

(INVITE            o=- 1405868408 1405868409 IN IP4 46.91.12.57)
                                  ^^^^^^^^^^
INVITE + AUTH      o=- 1405868408 1405868410 IN IP4 46.91.12.57
                                  ^^^^^^^^^^
OK auf ReInivte 1  o=- 1405868408 1405868409 IN IP4 46.91.12.57
                                  ^^^^^^^^^^
OK auf ReInivte 2  o=- 1405868408 1405868409 IN IP4 46.91.12.57
                                  ^^^^^^^^^^

Ist das bei Dir so nachzuvollziehen? Wenn Du core set debug 5 und core set verbose 5 stetzt, bekommst Du dann tatsächlich den Logeintrag "increment SDP version"? Auch darauf achten, dass der Key immer gleich bleibt!

 

[qupfer2]

Danke, schaue ich an sobald ich etwas Zeit habe. Habe ausreichend gewartet, und bild mir ein "rauchen" und nach ~10 Sekunden eine Art knacken wie beim Auflegen/weiterleiten zu hören.
Den Patch habe ich 1zu1 eingebunden, wie den Mediasec Patch im spec-File. Denke daher schon, dass der mit drinnen ist. MediaSec ist ja auch drinnen.

 

[Auerswald Fan]

Moin.

Könnte es evtl. Auch sein, das alle angebotenen Zertifikate abgelaufen sind - dann wird man hoffe ich bald mal aufwachen bei der Telekom:

CA-Zertifikate

TeleSec - Trust Center der Deutschen Telekom AG

www.telesec.de

 

[Meester Proper]

Diese CA-Zertifikate werden nicht genutzt, lediglich das Telesec Root CA Zertifikat muss auf dem Client installiert sein: https://www.telesec.de/de/public-ke...kate/category/59-t-telesec-globalroot-class-2

Außerdem wäre dann kein TLS-Verbindungsaufbau möglich.

openssl s_client -connect 217.0.28.162:5061
CONNECTED(00000003)
depth=2 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
verify return:1
depth=1 C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, CN = TeleSec Business CA 1
verify return:1
depth=0 C = DE, O = Deutsche Telekom AG, OU = SIP-Trunk.telekom.de, OU = SIP-Trunk, CN = tel.t-online.de, ST = Nordrhein-Westfalen, L = Bonn
verify return:1
---
Certificate chain
 0 s:/C=DE/O=Deutsche Telekom AG/OU=SIP-Trunk.telekom.de/OU=SIP-Trunk/CN=tel.t-online.de/ST=Nordrhein-Westfalen/L=Bonn
   i:/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/CN=TeleSec Business CA 1
 1 s:/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/CN=TeleSec Business CA 1
   i:/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG9zCCBd+gAwIBAgIIUf9BRQhu9JwwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UE
BhMCREUxJTAjBgNVBAoTHFQtU3lzdGVtcyBJbnRlcm5hdGlvbmFsIEdtYkgxHzAd
BgNVBAsTFlQtU3lzdGVtcyBUcnVzdCBDZW50ZXIxHjAcBgNVBAMTFVRlbGVTZWMg
QnVzaW5lc3MgQ0EgMTAeFw0xODA0MTkxMDQ3MTlaFw0yMDA3MTkyMzU5NTlaMIGl
MQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEdMBsG
A1UECxMUU0lQLVRydW5rLnRlbGVrb20uZGUxEjAQBgNVBAsTCVNJUC1UcnVuazEY
MBYGA1UEAxMPdGVsLnQtb25saW5lLmRlMRwwGgYDVQQIExNOb3JkcmhlaW4tV2Vz
dGZhbGVuMQ0wCwYDVQQHEwRCb25uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAwl6iq3B9EBJe9z34yCikyfla+ZSKE4gQUpo3hLLz2zXKiQildQc6qB6g
MzYvwjVJI64t5S2CbqEybBtrPn0FiziseDRZKnt+bkuIqZNPOYtkE1akGgdjIieV
Wjg6oD37+BCCqyq60gq0FbsGgjlwiNb68jL7dUXzRi2lgxtwk86+g/QFg+3rQts/
3GREGNhwVbu4mUIrnnphaUA8BnUeGi++8j9d21ZF/uW2pIQqVBItYDflBee+qGfk
Td7RV8CBO+RpOQiZSj2/wpLf5jPDiPAgvrrrZK54bjrkpwa10xu5IhbRfDD4G0E/
fJxB4/pLi0MiL2dKg9zNjgnRlAfkHwIDAQABo4IDWDCCA1QwHwYDVR0jBBgwFoAU
hoiTH4vrVZZl1UcBvTeMfM2ox6MwHQYDVR0OBBYEFAO30Gar4dOvXHK7poarfDPU
YXlHMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH
AwEwWAYDVR0gBFEwTzBDBgkrBgEEAb1HDRkwNjA0BggrBgEFBQcCARYoaHR0cDov
L3NiY2EudGVsZXNlYy5kZS9kb3dubG9hZC9jcHMyLnBkZjAIBgZngQwBAgIwCQYD
VR0TBAIwADCB8AYDVR0fBIHoMIHlMD2gO6A5hjdodHRwOi8vY3JsLnNiY2EudGVs
ZXNlYy5kZS9ybC9UZWxlU2VjX0J1c2luZXNzX0NBXzEuY3JsMIGjoIGgoIGdhoGa
bGRhcDovL2xkYXAuc2JjYS50ZWxlc2VjLmRlL0NOPVRlbGVTZWMlMjBCdXNpbmVz
cyUyMENBJTIwMSxPVT1ULVN5c3RlbXMlMjBUcnVzdCUyMENlbnRlcixPPVQtU3lz
dGVtcyUyMEludGVybmF0aW9uYWwlMjBHbWJILEM9REU/Q2VydGlmaWNhdGVSZXZv
Y2F0aW9uTGlzdDCCAScGCCsGAQUFBwEBBIIBGTCCARUwLwYIKwYBBQUHMAGGI2h0
dHA6Ly9vY3NwMDMuc2JjYS50ZWxlc2VjLmRlL29jc3ByMEQGCCsGAQUFBzAChjho
dHRwOi8vY3J0LnNiY2EudGVsZXNlYy5kZS9jcnQvVGVsZVNlY19CdXNpbmVzc19D
QV8xLmNydDCBmwYIKwYBBQUHMAKGgY5sZGFwOi8vbGRhcC5zYmNhLnRlbGVzZWMu
ZGUvY249VGVsZVNlYyUyMEJ1c2luZXNzJTIwQ0ElMjAxLG91PVQtU3lzdGVtcyUy
MFRydXN0JTIwQ2VudGVyLG89VC1TeXN0ZW1zJTIwSW50ZXJuYXRpb25hbCUyMEdt
YkgsYz1kZT9jQUNlcnRpZmljYXRlMGAGA1UdEQRZMFeCD3RlbC50LW9ubGluZS5k
ZYIPdGVsLnQtb25saW5lLmRlghdocGJ4LmRldXRzY2hsYW5kLWxhbi5kZYIaaHBi
eHNlYy5kZXV0c2NobGFuZC1sYW4uZGUwDQYJKoZIhvcNAQELBQADggEBAL+IkAeG
yZKmotwcsKWtNcHoDWf0Lj/Flh6xRn2U5/TsXlNI8PyukMuPEWbRZ/Q2SPOh7UZS
zi8VDw+YYDG0IUNrBFvLcJqo79/qljjDlu6bl3GDm9hDJ4alWgAOYoV63uCREOsj
CyUuOiDtgJWLaBu0nrceYWzBcaa0MMO0aRP8U08KLW0tnVCWGjPfpMDDZq8PifsC
cCe5zbw/J+M4+YFAj3uP7wEf+VQexPZCA2qF9bCEz5gBN5tR8LOcsA589FUnIXlJ
6vMK1ycLni+VMBifWXX4iN0MDL/W6WUjWoIUc2FzMcRexnQUoPm85C+M8LPKRZVQ
DnP3CVFwZvLpMyQ=
-----END CERTIFICATE-----
subject=/C=DE/O=Deutsche Telekom AG/OU=SIP-Trunk.telekom.de/OU=SIP-Trunk/CN=tel.t-online.de/ST=Nordrhein-Westfalen/L=Bonn
issuer=/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/CN=TeleSec Business CA 1
---
No client certificate CA names sent
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3879 bytes and written 390 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: E9203EEE85A84F3A36B74C874E17C2F4E0F50A4AFA3BECD2E4B7900846C4E70A
    Session-ID-ctx:
    Master-Key: 8691019F58788262496A79B18CB6ED2048038938A539CFC4A614A2114D03AF44DF276843EC97110957EAE5D796A74ABB
    Start Time: 1565444124
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
closed

--

Ich werde mal am WE ein wenig herumspielen, mal schauen woran das liegt. Ärgerlich eigentlich, denn warum sollte man die Kommunikation nicht verschlüsseln ...

Die Kommunikation an sich ist nicht verschlüsselt, wenn RTP weiterhin verwendet wird. Nur die Metadaten sind verschlüsselt, wenn SIP over TLS genutzt wird, aber RTP für die Kommunikation.

 

[_tms]

Ich hatte diese Woche das Problem, dass über Nacht plötzlich weder ein- noch ausgehend möglich war.
Neustart hat nicht geholfen. Laut Telekom war bei denen alles ok.

Lösung war, dass SRTP bei den MSN-SIP Konten deaktiviert war.
Nach Aktivierung ging wieder alles normal.

Imho hat die Telekom diese Woche irgendwas geändert.

 

[mipo]

Genau, bei mir funktioniert es mit SIPS Verschlüsselung (@Meester Proper: hast vollkommen Recht, RTP wird leider nicht verschlüsselt nur SIP) seit vorgestern wieder. Also die Telekom muss da wohl doch ein Problem gehabt haben. Der Hinweis von verschiedenen Usern auf ein ausgelaufenes Zertifikat wäre wohl nicht ganz von der Hand zu weisen bzw. sehr wahrscheinlich. Aber beweisen kann ich das natürlich nicht

 

[Meester Proper]

Ich schätze mal eher, dass die Policy SIP over UDP/TCP und RTP (und kein SRTP), sowie SIP over TLS und SRTP (und kein RTP) noch nicht komplett über alle P-CSCF ausgerollt ist.

Das Root-Zertifikat T-TeleSec GlobalRoot Class 2 ist bis 2033 gültig und das Intermedia-Zertifikat TeleSec Business CA 1 ist bis 2024 gültig.
Diese Zertifikate wurden auch nicht kürzlich gewechselt, sondern sind meines Wissens seit der Einführung von SIP over TLS auf der IMS-Plattform im Einsatz.

 

[qupfer2]

Also ich bei mir funktioniert jetzt SIPS+RTP auch wieder. Lasse es aber lieber erst mal auf UDP+RTP. Habe aber eine ungenutzte Nummer mal mit reingenommen (SIPS+RTP) und werde das beobachten.

Zum Thema 116116. Mit "core set debug 5" werde ich auf der Konsole mit Logs erschlagen. Aber ein einfaches suchen ergab, dass die Zeile "increment SDP" enthalten ist.
"DEBUG[23148]: res_pjsip/pjsip_message_filter.c:344 filter_on_tx_message: increment SDP version"

Aber ich habe das Gefühl, dass da nicht so wirklich erhöht wird. Zumindestens wenn ich das alles richtig deute.
Hier ist mal ein Log-Mitschnitt vom pjsip log. Aber das ding ist ebenso gefühlt unendlich lang, weil da auch noch andere SIP Nachrichten mit drinnen stecken. Gitbs da noch tips, wie man "vorfiltern" kann?
Falls jemand mag, das eigentliche Telefonat erfogte von der Nebenstele 888 (IP 192.168.2.108 (WLAN, lokal) bzw. 172.16.0.4 (VPN)) und der Asterisk läuft auf 192.168.100.80 bzw. 172.16.0.80. Andere IPs aus dem 192.168.100.0/24 Netz sind irrelevant.
https://leipzig.07q.de/s/5qG7gxCTQZnT5Sc (extern, weil mehr als 5000 Zeichen :-D )

 

[Meester Proper]

Nein, die Session Version wird hier nicht erhöht, obwohl sich der SDP-Inhalt ändert:

INV
v=0
o=- 1531423055 1531423056 IN IP4 87.148.193.85
s=Asterisk
c=IN IP4 87.148.193.85
t=0 0
m=audio 29778 RTP/AVP 8 9 3 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/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

INV nach SIP407
v=0
o=- 1531423055 1531423056 IN IP4 87.148.193.85
s=Asterisk
c=IN IP4 87.148.193.85
t=0 0
m=audio 29778 RTP/AVP 8 9 3 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/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

200OK auf Re-INV
v=0
o=- 1531423055 1531423056 IN IP4 87.148.193.85
s=Asterisk
c=IN IP4 87.148.193.85
t=0 0
m=audio 29778 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

=> Deswegen fehlt auch die SDP-Answer im ACK auf das 200OK und der Ruf hat kein Audio.

 

[gehtdoch]

Zum Thema 116116. Mit "core set debug 5" werde ich auf der Konsole mit Logs erschlagen. Aber ein einfaches suchen ergab, dass die Zeile "increment SDP" enthalten ist.
"DEBUG[23148]: res_pjsip/pjsip_message_filter.c:344 filter_on_tx_message: increment SDP version"

Aber ich habe das Gefühl, dass da nicht so wirklich erhöht wird. Zumindestens wenn ich das alles richtig deute.

Wie Meester Proper schon schrieb, wurde da nicht wie gewünscht inkrementiert. Kannst Du mal bitte den neueren Patch testen? Und dann bitte alle Zeilen mit "increment SDP version, starting from .." pasten, die den Callleg zur Telekom betreffen, falls es wieder nicht funktionieren sollte.

 

[qupfer2]

Damit läufts jetzt. *freu*
Trotzdem noch interesse an Logs? Dann würde ich die morgen Nachmittag versuchen aufzuzeichnen.
Gibt ws da noch Tips, wie man die "vorfiltert" bzw. möglichst "elegant" ran kommt?

EDIT: wenn ich über mein SIP-Client aufm Telefon verbinde, dann läufts jetzt.
Wenn ich aber über IVR->DISA->116116 mich durchhangel, gehts nicht. Werde daher wohl morgen nochmal Protokoll führen :-D

Edit 2: So, heute morgen klappt es auch über DISA etc. Versteh ich zwar nicht, aber mir soll es recht sein. Mal sehen, ob/wann das auch upstream gefixt ist.
Aber vielen herzlichen Dank. Es fühlt sich besser an. Es war (mir bekannt) zwar nur die 116116, die nicht ging. Aber trotzdem irgendwie ein unschönes gefühl zu wissen, dass man aufgrund der eigenen Technik bestimmte Nummern nicht anrufen kann (und der Fehler nicht an der Gegenseite liegt)

 

[gehtdoch]

Freue mich, dass der 2. Quickfix nun auch bei Dir funktioniert.

Zum Thema "vorfiltern": mir ist da nichts bekannt. Ich mache es eben immer so, dass ich es in einer Zeit mache, wo nur der eine Call aktiv ist. Ansonsten hat man da echt verloren. Ich lasse mir alles in der Konsole ausgeben (ich verwende hierfür die KDE-Konsole). Gehen bestimmt auch andere Tools, deren Historie entsprechend groß eingestellt werden kann und wo man mit einem Klick einfach alles markieren / kopieren kann und dann in einen Editor übernehmen, um es dort abzuspeichern und dann auszuwerten. Ja, ist ziemlich aufwändig.

Es gibt aber auch die Möglichkeit, sich alles in eine Datei loggen zu lassen (über die asterisk CLI) - sollte man aber nur dann machen, wenn das System auch entsprechende Ressourcen bereitstellt (auch was die Schreibgeschwindigkeit angeht - da kann schon heftig was kommen, wenn entprechend was los ist):

aktivieren:
logger add channel debug_log_123456 notice,warning,error,debug,verbose,dtmf
pjsip set logger on
core set verbose 5
core set debug 5

deaktivieren:
pjsip set logger off
core set verbose off
core set debug off
logger remove channel debug_log_123456

 

[qupfer2]

Danke, werde ich mal testen.

Bin auch bei meinem Problem eine Information weiter.
Ich höre weiterhin nichts, wenn ich via G722 telefoniere. Mittels alaw klappt es aber jetzt.

 

[gehtdoch]

Hmm, mein Endpoint hat die folgende Codec-Präferenz (sowohl seitens Asterisk als auch seitens des Telefons selbst):

• G722
• alaw
• ulaw

Exakt gleich für den Trunk konfiguriert. Gibt hier keinerlei Probleme. Führt bei mir Outbound grundsätzlich dazu, dass zwischen Endpoint und Asterisk immer G722 verwendet wird und zwischen Asterisk und Provider entweder auch G722 oder eben alaw (ist schon sehr lange eine bekannte Einschränkung von Asterisk wo leider noch keine Zeit dafür gefunden wurde zur Implementierung).

Inbound ist es aber so, dass für beide Calllegs der gleiche Codec verwendet wird (entweder G722 oder alaw).

Da wäre ein Trace interessant (erstmal nur SIP) zwischen allen Beteiligten. Irgendwas schießt da quer.

 

[qupfer2]

toll, jetzt gehts auch mit G722. Habe aber gestern nochmal alle Codec-Einstellungen verineheitlicht auf G722/alaw/GSM. Nun gehts auch via"HD". Vorher war noch...aus anderen Testgründen...sln44 und weitere exotische teilweise aktiviert. Eventuell hat sich da eine der drei Seiten (client, asterisk, 116116) verschluckt.
Werde es aber weiterhin beobachten. Genau wie das mit TLS ohne SRTP.

 

[gehtdoch]

Ich musste heute feststellen, dass der Telekom SIP-Server irgendwann von asterisk unbemerkt den mediasec-Status von allen drei Nummern verloren hat (warum auch immer) und daher auf unverschlüsselten rtp umgestellt hat. In Folge dessen wurden von Asterisk sowohl In- als auch Outbound calls abgelehnt mit einem unfreundlichen, aber korrekten "488 Not Acceptable Here" hinsichtlich des unverschlüsselten SDPs.
Was mir aufgefallen ist, als ich die SIP-Pakete analysiert habe, nachdem ich das Problem erkannt hatte, dass die Register ganz normal durchgelaufen sind (also ohne Mediasec-Erweiterung) und der Telekom-Server auch kein "494 Security Agreement Required" angefordert hat (was ich eigentlich erwarte).
Ich habe jetzt mal exzessives Logging aktiviert und beobachte, ob das Problem wieder auftritt, um dann zu sehen, was da genau abgeht.

Wer sicher gehen möchte, einen Ausfall zu verhindern, kann bei den betroffenen Trunks folgende Option setzen:

media_encryption_optimistic=yes

Das stellt sicher, dass der Call auch dann nicht abgelehnt wird, wenn keine Verschlüsselung möglich ist.

--

Fällt mir gerade ein: Ein denkbares Szenario, wie so etwas passieren kann, ist, wenn der SIP-Server der Telekom durchgestartet wurde: in diesem Moment verliert er alle Sessions und die Registers, die danach kommen, werden so behandelt, wie sie eben sind - wenn sie kein Mediasec anfordern, wird es auch nicht gesetzt - da ich das nur initial derzeit mache bzw. wenn ein "494 Security Agreement Required" kommt (das ja aber in diesem Fall nicht mehr kommen kann - der Server weiß ja nichts mehr von vor dem Restart), kommt es zwangsweise zu dieser Situation. Muss ich auf jeden Fall entsprechend ändern!

 

[Meester Proper]

Das wäre in der Tat besser, wenn bei jeder Re-Registrierung die Mediasec-Parameter mitgeschickt werden würden, anstatt nur bei einem SIP494.

 

[gehtdoch]

Kleines Update:
ich bin gerade dabei, den angedachten Fix noch final zu testen. Da war es ganz geschickt, dass es hier in der vergangenen Woche zwei weitere "Quasi"-Ausfälle der Telefonie gegeben hat (ein Server aus der SRV-Liste hat gesponnen), so dass in diesem Zusammenhang auch noch ein weiteres Problem hochgespült wurde und ich damit auch gleich fixen konnte. Wenn der Test nun weiterhin gut läuft, kann ich so ungefähr am Montag den Fix einstellen.

 

[gehtdoch]

Wie versprochen gibt es hier die neue Mediasec-Version (getestet mit Asterisk 16.4.1). Sie geht zwei Probleme an:

1. Auch ein Restart eines Servers des Providers führt nicht mehr dazu, dass plötzlich eine "normale" Registrierung durchgeführt wird, sobald der Server wieder zurückkommt und daher die alte Session nicht mehr kennt. Zukünftig enthält jeder Register Request die nötigen Mediasec-Erweiterungen.
   
   
2. Da es nun auch im Normalbetrieb viel öfter zu 494-Requests kommt, die beantwortet werden müssen, ist mir an dieser Stelle das fehlende Memorymanagement aufgefallen, das mit diesem Patch nun auch adressiert wird, so dass der Prozess nicht ständig immer mehr Speicher benötigt, der nicht mehr abgebaut wird.

Ich hoffe, dass der Patch auch bei Euch funktioniert - wie üblich ohne Garantie. Bei Fragen / Anregungen / Problemen einfach hier melden.