2 Media Streams in SDP führen bei Telekom NGN zu 500 Internal Server Error

[kescholz]

Hallo liebe Community,

wir haben derzeit die Herrausforderung, dass wir mit den SIP-Trunk Optionen "SRTP -> an" und "Transport Protocol -> TLS" von der Telekom bei manchen Nummern ein 500 Internal Server Error zurückbekommen. Laut Telekom passiert das, da mit den 2 Media Streams, die via SDP angeboten werden, nicht umgegangen werden kann. Diese sehen wir im Netzwerkdump sowie ist dieses Verhalten hier unter SRTP beschieben. Gibt es eine Möglichkeit, den unverschlüsselten Media Stream zu unterbinden und lediglich den verschlüsselten, also "m=audio 9750 RTP/SAVP 9 8 101" zu senden?

Der Dump sieht in etwa so aus:

v=0
o=3cxPS 3008930775040000 3977037928726529 IN IP4 123.456.789.123
s=3cxPS Audio call
c=IN IP4 123.456.789.123
t=0 0
m=audio 9750 RTP/SAVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:XXX
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:XXX
a=sendrecv
m=audio 9750 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.89.0.2:5060;rport;received=123.456.789.123;branch=xxx---yyy
To: <sip:[email protected]:5060;transport=TCP>
From: <sip:[email protected]:5060;transport=TCP>;tag=9cd2201b
Call-ID: LdO98PjT8hGw-5NKmHv7OA..
CSeq: 1 INVITE
Content-Length: 0

In den RFCs RFC4568 und RFC3264 konnte ich nichts genaues dazu finden, ob das 3CX Verhalten akzeptable ist oder nicht.

Ich freue mich über jede Hilfe!

 

[ilias_3CX]

In den RFCs RFC4568 und RFC3264 konnte ich nichts genaues dazu finden, ob das 3CX Verhalten akzeptable ist oder nicht.

Das ist 100% akzeptable und RFC Kompatible.
Da die Telekom hiermit nicht klar kommt wird auch TLS mit einem Telekom Sip Trunk nicht unterstützt.
Von der Seite der 3CX kann dies nicht geändert werden.

 

[avraammich_3CX]

Hallo,

RFC 4566 besagt in Section 5.14

"A session description may contain a number of media descriptions."
und etwas später "
The semantics of multiple "m=" lines using the same transport address are undefined.".

Ich hatte schon mal das Verhalten gesehen mit Inlandgesprächen wo es funktioniert und mit Auslandsgesprächen wo es nicht funktioniert.(selber Provider)

Mehrere Offer im SDP sind jedoch generell erlaubt.

 

[kescholz]

Danke für die Info und die Referenz. Das heißt, hier wird ein undefinierter Zustand ausgenutzt? Auch wenn das RFC-konform erscheint, scheint mir das auf den ersten Blick nicht so gelungen, da es zu Problemen wie 500er führt, die sich schwierig für den Anlagenbetreiber debuggen lassen.

RFC3264 beschreibt allerdings auch

If multiple media streams of the same type are present in an offer, it means that the offerer wishes to send (and/or receive) multiple streams of that type at the same time.

Das trifft ja allerdings hier nicht zu, du 3CX davon ausgeht, dass die Gegenseite einen Stream nutzt und den anderen "nullt" (?) anstatt beide parallel zu nutzen, oder?

Gibt es eine Möglichkeit über Konfiguration, dass der unverschlüsselte Stream nicht angeboten wird? Wir würden gerne verschlüsseln, was so allerdings nicht möglich ist.

 

[kescholz]

Dazu kommt ebenfalls, dass man so derzeit nie weiß, ob der aktuelle Call verschlüsselt ist oder nicht. Eine Option "SRTP only" bzw. "RTP/SAVP only" würde somit meine Ansicht nach einen klaren Mehrwert bieten.

 

[avraammich_3CX]

Bitte beachte dass TLS oder SRTP in unserem Provider-Interop-Prozess weder obligatorisch noch validiert sind, da die meisten Provider dies derzeit nicht unterstützen.

SIP TLS Support

No​

Ändern können wir jedoch das Verhalten z.Z nicht.



Falls der Anruf verschlüsselt ist wird dieser im Pcap(Aufzeichnung nicht angezeigt)