So, ich habe das Ganze nun noch mit
H264 getestet. Gar nicht so einfach, Linphone in openSUSE Leap 15.1 (und wahrscheinlich sämtliche openSUSE-Versionen derzeit) H264 beizubiegen (H261 wird nicht unterstützt von Linphone). Daher erstmal die Details zur Installation (die automatisch dazugebündelten RPM-Pakete habe ich nicht gelistet):
- linphone 4.1.1 (aus Standardrepository)
- mediastreamer2 (aus Standardrepository)
- libopenh264-5 (aus Packman)
- msopenh264-mediastreamer (nur als Source aus der openSUSE Community - muss man dann mit rpmbuild --rebuild selbst übersetzen (was noch diverse weitere (devel) Pakete) benötigt)
Was bringt das Ganze? H264 ist sicher mit der Standard. Daher habe ich die obigen Tests mit H264 nochmal wiederholt. Die Erkenntnis ist kurz zusammengefasst: Telekom AllIP verhindert aus meiner Sicht aktiv Videocalls. Easybell unterstützt es zwar nicht offiziell, aber verhindert es auch nicht (nach dem Motto: wenn es funktioniert ist gut, wenn nicht -> Pech gehabt - Support gibt es keinen - es wird ja nicht unterstützt). Selbst die Übergabe zu anderen Providern findet statt - was dann damit passiert - darauf hat Easybell aber keinen Einfluss mehr - siehe hier am Bsp. Telekom AllIP.
Test Easybell -> Easybell: funktioniert
Test Easybell -> Telekom: funktioniert nach wie vor nicht (auch nicht unverschlüsselt)
Hier fällt allerdings auf, dass Easybell nun tatsächlich im SDP H264 übergibt. Welcher von der Telekom AllIP-Plattform aber verworfen wird.
An Easybell übergeben:
Code:
m=video 10082 RTP/SAVP 99 100
a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:kK/gRbnZs9CNvxnk4BZJMzYf08jgqSJ/iV4aLaNN5zncmVxapOpnYOe2MX2BmQ==
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:xly8owiLgkYAW4NzInw3Z3rqdylehWf+Gd5Pqnbz
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42801F
a=rtpmap:100 VP8/90000
a=sendrecv
wird zu (hier der unverschlüsselte Telekom-AllIP-Test)
Code:
m=video 0 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42801F
=> Der Codec wird von Telekom AllIP gezielt deaktiviert.
Test Telekom AllIP -> AllIP: funktioniert nicht. Wobei ich mir da nicht sicher bin, woran das liegt. Zunächst kann der Videocodec überraschenderweise erfolgreich ausgehandelt werden und die Verbindung steht - für eine halbe Sekunde.
Dann schickt hier aber komischerweise Linphone als Callee das folgende Info-Paket an Asterisk (bei easybel passiert das nicht komischerweise - ist auch absolut reproduzierbar) - in einer Zeile wie hier dargestellt:
Code:
<?xml version="1.0" encoding="utf-8" ?><media_control> <vc_primitive> <to_encoder> <picture_fast_update></picture_fast_update> </to_encoder> </vc_primitive></media_control>
Asterisk schiebt es so via Inbound-Telekomserver zurück an den Caller (und bekommt nie ein 200 OK darauf zurück):
Code:
<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<vc_primitive>
<to_encoder>
<picture_fast_update/>
</to_encoder>
</vc_primitive>
</media_control>
Dieses Paket kommt schlussendlich via Telekom Outbound und asterisk auch beim Caller an (asterisk quittiert zur Telekom mit 200 OK und auch der Caller quittiert zu asterisk mit 200 OK).
Ohne weitere Pakete dazwischen beendet dann aber sofort der Outbound-Server der Telekom die ganze Nummer mit
Code:
CSeq: 16788 BYE
Reason: SIP;cause=480;text="Sip internal error"
=> irgendwas passt dem nicht ... .
Grundsätzlich:
Ich verstehe nicht, warum die (bzw. v.a. manche große) VoIP-Provider die Videotelefonie ignorieren / behindern und so das Feld irgendwelchen zweifelhaften Anbietern überlassen, wo man überhaupt nicht weiß, woran man ist. Aus meiner Sicht nicht nachvollziehbar. Der Standard würde es hergeben.
