So, guten Abend zusammen. Weiter geht's im Network Track. Noch mal Nico, oder im echten Leben Nicola von Tannen. Immer noch Netzwerker, Mädchen für alles, bei Manet bzw. der Pfalzcom,

einem ISP im Raum der Pfalz bzw. Region Mannheim, Ludwigshafen. Auch in der Internetmanufaktur aktiv. Deswegen auch gerade auf einem Campingplatz in Niederland unterwegs. Interessiert sich für Funken und man kann ihn auch mieten, um Telefone zu debuggen

oder Netzwerke zu bauen oder ähnliche Dinge zu tun. Und genau um Ersteres geht es jetzt, nämlich um das Debugging von SIP, beziehungsweise ein bisschen mehr zu SIP und was tue ich, wenn es kaputt ist. Damit. Viel Spaß.

Genau. So, ich hab mich mal kurz umgesetzt. Willkommen zurück. Da ist jetzt ein bisschen mehr Licht von vorne und weniger von hinten kommt. Dann müsste man mich noch besser sehen. Ich bin, wie der Max eben auch gesagt hat, immer noch bei der Pfalzcom. Und ja, gerade in Holland. Hoffentlich findet ja nächstes Jahr in Holland

das Hackercamp statt. Das wird nächstes Jahr MCH heißen für May-Contain-Hackers. Und da ist dieses Wochenende ein Orga-Event auf dem Campingplatz, um sich die Location nochmal anzuschauen. Ja, daher auf einem Event für ein anderes Event vortragen.

Was haben wir eben gemacht? Alice hat Bob angerufen. Sie haben festgestellt, dass ein Proxy dafür ganz praktisch wäre, damit sie nicht von jedem wissen muss, welche IP-Adresse der hat, sondern sich nur die normale Telefonnummer oder den Namen merken muss. Sie hat sich da authentifiziert. Sie haben sich auf dem Codec geeinigt und haben vermutlich sogar miteinander telefoniert.

Die Rahmenbedingungen haben gestimmt. Was wir nicht hatten, war ein Problem. Wir hatten zwar eine Firewall und NAT, aber irgendwie hat alles direkt funktioniert und es war eine politische Spielchen involviert. Und wie realistisch ist das? NAT in der Richtung hat funktioniert.

Die Firewall hatten wir auch gesehen, hat funktioniert. Wir hatten Stun verwendet, damit das dadurch geht. Es gibt aber auch noch Alternativen zum Stun. Die sind heutzutage nicht mehr so verbreitet. Vor 15 Jahren sah das noch ein bisschen anders aus. Da gab es Hersteller, die der Meinung waren, dass Stun nicht sinnvoll wäre zu implementieren

oder dass sie andere Empfindlichkeiten hatten und es deswegen nicht getan haben. Deswegen haben die sich zum Beispiel darauf verlassen, dass sie den Audiodatenstrom zu der IP-Adresse und dem Port schicken, wo er auch herkommt. Was man ja argumentieren kann, wenn man Provider ist,

dass man, wenn man Audio von einem Kunden empfängt, das dann so passt. In der Konstellation mag das auch funktionieren. Wenn aber der Kunde auf die Idee kommt, das Gleiche zu tun, ist das Ganze blöd. Die Telefonanlagen da draußen, die kann man so konfigurieren, dass sie eben Nut-Erkennung darüber machen,

wo der Ton herkommt und das dann da hinschicken. Das macht, ich sag mal, auf einer Kundenfirewall eigentlich keinen Sinn, weil das sehr selten ist, dass der Provider seine Firewall hinterher nochmal in den Nut steckt. Sondern in der Regel ist das maximal der Kunde hinten dran. Deswegen braucht man das in meinen Augen an der Stelle nicht.

Wenn man das aber aktiviert und der Provider das genauso bei sich aktiv hat oder die Provider-Telefonanlage schon ein bisschen in die Jahre gekommen ist und nichts anderes unterstützt, hat man das Problem, dass der Anruf zwar aufgebaut ist, die SIP-Signalisierung sagt, das ist alles gut, man hört aber nichts.

Weder der eine den anderen, noch umgekehrt, es ist absolute Stille, bis irgendetwas passiert. Das Ganze hatte ich vor einer Weile gehabt bei einem Troubleshooting. Da war die Kundentelefonanlage zwar auf Stun konfiguriert, hat allerdings, wenn Stun nicht funktioniert,

darauf gewartet, wo der Ton herkommt. Hat Stun aber weiterhin versucht zu tun und zufälligerweise ging es dann da durch. Der Provider unterstützt zwar keinen Stun, für die Provider-Telefonanlage hat es aber ausgereicht, das Paket zu sehen und das dann dem richtigen Kunden zuordnen

und den Ton dann da hinzuschicken. Das Problem hat sich daran ursprünglich geäußert, dass die Anrufe am Anfang einige Sekunden Stille hatten und je länger es geklingelt hat, desto länger war die Stille.

Weil Stun erhöht den Timer mit jedem Paket, das es abschickt. Also es schickt ein Paket, dann eine Sekunde später, dann wartet es nochmal eine Sekunde länger, also nach zwei Sekunden und dann quasi nochmal verdoppelt oder für eineinhalbfacht. Konnte man in dem Fall, dass halt die Kundentelefonanlage

das Ganze deaktiviert hat und halt Audio dann sofort geschickt hat. So eine Methode. Andere Sache, die sogenannte Paytime. Ich hatte ja eben erwähnt, dass man eigentlich heutzutage immer 20 Millisekunden in einem Paket drin hat,

das aber auch 30 möglich wäre. Das war damals in Kombination Fritzbox mit Freeswitch so ein Thema. Das war über zehn Jahre her, mittlerweile auch lang gefixt, aber die hatten sich nicht richtig verstanden.

Hat der eine versucht, 30 zu machen und das war dann alles abgehackt. Ich glaube, da habe ich aber später nochmal ein Slide dazu. Genau, es steht im STP drin, das hatte ich auch kurz gezeigt, wie das dann aussieht, ob das jetzt 20 oder 30 Millisekunden sind. Wenn man natürlich was anderes in den STP reinschreibt,

als dann wirklich zu tun, dann ist es kaputt. Dual-Stack bei IPv6 und IPv4. Großes Thema, wird immer mehr ausgerollt. Die meisten SIP-Provider unterstützen aktuell nur IPv4,

machen keinen Dual-Stack. 1&1 hat das soweit ich weiß, oder was ich gesehen habe, bei sich mittlerweile aktiviert. Ich weiß nicht, ob sie es aktiv auf dem Fritzboxen ausrollen auch, aber eigentlich, sobald es im DNS drin ist, wird es auch genutzt. Dadurch, dass allerdings die Audiowahlen,

haben wir mal gesagt, das geht über den STP, was ein eigenes Protokoll ist, zwar in SIP-enkapsuliert, aber erstmal unabhängig. Dass die Audio-, die Codec-Auswahl darin funktioniert, ist der Audio-Datenstrom unabhängig von der Signalisierung.

Wenn der SIP-Server IPv6 und IPv4 unterstützt und der Client ebenso, dann kann das vorkommen, dass der Client bei sich in einen STP reinschreibt, dass er sowohl eine öffentliche v4- als auch v6-Adresse hat. Eventuell, wenn er es dann aktiv hat, schreibt er drei Adressen rein,

seine private v4, seine öffentliche v4 und die öffentliche v6-Adresse. Der Server ging ebenfalls. Das kann allerdings dazu führen, dass die eine Richtung versucht, IPv4 zu schicken, die andere Richtung IPv6 versucht.

Das verwirrt Firewalls und das verwirrt auch manchmal die Server. Ich hatte es letztens bei 1&1 gehabt. Softphone auf einem Nuc-System hinter einer PF-Sense-Firewall.

Der 1&1-Server hat die Audiopakete an die öffentliche IPv4-Adresse geschickt. Der Client hat die Audiopakete an die IPv6-Adresse vom 1&1-Server geschickt. Und eine Richtung hat er Audio gehabt, die andere Richtung nicht. Der angerufene mit seinem Softphone hatte quasi nie die andere Person gehört.

Das kann sich dann darin äußern oder den witzigen Effekt haben. Das war weg, sobald er den Anruf kurz gehalten hatte.

Weil beim Halten von einem Anruf wird in manchen Fällen die Audioverbindung getrennt. Je nachdem, ob man eine Wartemusik erzeugt oder nicht. Wenn die der Client nicht vorgibt, dann wird die im Netz beim Provider zum Beispiel erzeugt. Oder sogar erst auf der entfernten Telefonanlage. In dem Fall war es, dass ich als derjenige, der den Anruf gar nicht gehalten hat,

trotzdem die Wartemusik von meinem eigenen Zip-Server gehört habe. Nachdem der Anruf wieder aufgenommen wurde, lief dann Audio aber. Weil die Codecauswahl noch mal komplett von neuem loslief.

Und das in dem Fall dann zufällig in den meisten Fällen funktioniert hat. Weitere Codecauswahl allgemein. Ich hatte ja eben den SDP gehabt. Und hier erwähnt, dass der Opus-Audio-Codec drin steht. Der ist im Telefonienetz noch kaum verwendet.

Es gibt aber mittlerweile keine technischen Gründe mehr, die nicht zu nutzen. Opus hat eine gute Klangqualität für das, was er kann. Es ist ein freier Codec, für den man keine Lizenzen kaufen muss. Bisher hat sich soweit ich weiß auch noch keiner gemeldet, der der Meinung ist, da irgendwann schon Patente drauf zu haben und das durchgesetzt hat.

Daher machen das manche Provider mittlerweile, das ist zu tun oder nicht. Da sind wir aber auch schon wieder bei der politischen Sache. Dass die Provider meistens möchten, dass Audio immer durch ihre eigene Proxiesaber durchgeht.

Und da hat er es gerade, ja. Einmalseits wegen Lawful Interception. Andererseits aber auch teilweise zum Troubleshooting. Es gab früher mal Regularien, dass die Provider tun mussten, dass es immer durch ihre Proxies durchgeht. Da gibt es unterschiedliche Meinungen dazu.

Bei 1&1 zum Beispiel ist es so, dass es mittlerweile nicht mehr durch die 1&1 Proxiesaber geht, sondern Audio teilweise direkt zwischen den Kunden stattfinden kann beziehungsweise zwischen dem Gateway zum anderen Provider. Bei Subgate ist es genau umgekehrt. Bei denen war es früher so, dass die Kunden untereinander direkt Audio machen konnten.

Und im Moment geht es, soweit ich weiß, beim Subgate Basic immer durch den Proxiesaber durch. Das heißt natürlich, dass der Server mit dem Codec klarkommen muss. Und dass die Provider deswegen die Codex oft auf G711 und G722 limitieren.

Die schon ein bisschen in die Jahre bekommen sind. G722 wurde sogar schon zu ISDN-Zeiten zertifiziert. Es gibt ganz wenige ISDN-Telefone, die es auch unterstützen. Die Provider im Netz machen es kaum. Und daher ist der Codec erst mit SIP richtig in Fahrt gekommen.

Aber eben mit Opus und anderen Codecs gibt es mittlerweile bessere. Die Deutsche Telekom war früher sehr restriktiv, was die Codecauswahl angeht und hat gesagt, dass Provider, die sich mit dem Netz der Telekom zusammenschalten wollen, nur den G711 und den G722-Codec und noch einen weiteren Fax-Codec,

der kommt später noch zur Telekom signalisieren dürfen. Und deswegen haben die meisten Provider das in ihrem internen Netz dann auch schon so gehandhabt, dass die Codex da nicht verwendet werden können. Viele Provider machen das immer noch so heutzutage und lassen die anderen Codex nicht zu.

Da gibt es aber auf der Sicht keinen Grund mehr dafür. Die neuen Anschlüsse der Telekom unterstützen auch andere Codex, was das angeht. Von daher fragt euer Provider, dass er auch bessere Codex als G722 unterstützt.

Großes angeht SIP-Gate, die eventuell sogar noch nicht mal das G722 unterstützen. Das weiß ich aktuell nicht. Und halt eins und eins, die zwar den Codec unterstützen, aber Opus und andere qualitativ bessere eben nicht durchlassen, weil die entweder noch eine alte Kopplung zur Telekom haben

oder die die Konfiguration bei sich nicht geändert haben. Thema Kopplung der Provider untereinander. Ich hatte eben gesagt, die Migration von ISDN auf SIP, das was auf der Kundenleitung passiert, passiert genauso auch zwischen den Providern untereinander.

Viele Kopplungen der Provider basieren immer noch auf TDM, sozusagen SDH-Technik und ISDN und werden erst auf SIP umgestellt. Die weiteren Codex werden dann erst bei SIP akzeptiert.

G722 wird auf TDM funktionieren, wird aber nicht gemacht. Die Migration läuft. Nach und nach ist auch die Telekom dabei, die alten Providerleitungen teilweise von sich aus zu kündigen, ähnlich wie es bei normalen ISDN-Anschlüssen machen oder halt die Provider dazu zu bringen, zu migrieren.

Das führt dann auch zu lustigen Effekten, dass wenn man von einer Vorder von Holland einen deutschen Telekom-Kunden anruft, im SIP, dass es dann noch über eine TDM-Kopplung läuft und kein HD- oder Wideband-Audio-Codec wie G722 unterstützt wird.

Wenn man zum Beispiel von einer 3-UK-SIM-Karte bei einem Telekom-Kunden anruft, läuft das über eine NGN-Kopplung auch von der Vorderphone, unterstützt dadurch allerdings Wideband-Codecs. Und da mittlerweile Mobilfunk auch über die gleichen Kopplungen unterstützt, sorgt das dann dafür,

dass ein Telekom Deutschland Mobilfunk-Kunde im LTE-Netz mit einem 3-UK-Kunden, der auch im LTE-Netz ist, mit entsprechenden LTE-HD-Codecs telefonieren kann und mit einem Vorderphone-Holland-Kunden noch nicht. Das kann natürlich zuwitzig noch anders sein, wenn sich die Anrufrichtung ändert,

weil die Kopplung, über die das läuft, ist eine reine Wahl des abgehenden Providers. Also wenn ich in dem Fall die 3-UK-SIM-Karte verwende, dann entscheidet sich 3 über den besten Weg zum Telekom Deutschland-Kunden oder zum günstigsten Weg.

Da kommt dann die Politik wieder ins Spiel. Genauso kann es sein, wenn jetzt zum Beispiel ein O2-Kunde einen Telekom-Kunde anruft und zurück, dass es über den einen Weg über eine neue Kopplung läuft und beim alten Weg noch über eine andere. Oder viele Provider haben teilweise Links zur Telekom und zur Versatel.

Wenn jetzt dann der Telekom-Kunde den Drittprovider anruft, läuft es über eine direkte Kopplung und auf dem Rückweg kann es vorkommen, dass es über die andere Kopplung läuft und damit einen schlechteren Codec. Das macht aktuell noch keinen großen Unterschied, da die wenigsten Telefonanlagen G7 22 unterstützen.

Das wird aber in den nächsten Jahren definitiv kommen, dass auch innerhalb von Firmen und Firmen-Telefonanlagen bessere Codecs verwendet werden und damit dann auch nach draußen. Weil die Codecauswahl kann durch den Provider limitiert werden. Und wenn es über eine Provider-Kopplung läuft, die in der Konfiguration noch ein paar Jahre zurückhängt,

dann hat man automatisch weniger Auswahl an der Stelle. Early Media. Jeder kennt es ja, wenn man irgendwo anruft, dann kommt ein Freizeichen. Manchmal kommt Musik als eine Nachricht, dass der Angerufene nicht verfügbar ist, also jetzt nicht Mailbox,

aber eine andere Sache, ohne dass der Anruf wirklich schon aufgebaut ist. Gerade im Mobilbereich war es ja jahrelang öfters mal zu hören, dass wenn mal jemand angerufen hat,

dass dann halt Musik kam, während es schon geklingelt hat, hat die schöne Sache, die Rechnung beginnt erst zu laufen, sobald der Anruf wirklich aufgebaut ist und nicht während die Musik läuft, obwohl schon Audiodaten ausgetauscht werden. Das ist nicht zwingend nur eine Einbahnstraße.

Wenn mein Handy Musik empfängt und das schon wiedergibt, hat es oft auch schon das Mikrofon an und rein technisch hält die andere Seite nichts davon ab, das auch schon aufzuzeichnen, was da kommt. Das ist in Deutschland unzulässig, Anrufe zu schneiden, aber rein technisch geht das.

Manche Provider limitieren das Media in eine Richtung, zum Beispiel 1&1 hatte es vor ein paar Jahren so, dass Privatkunden so Early Media empfangen konnten, allerdings selbst nicht initiieren und senden. Aber grundsätzlich kann man über Early Media schon komplette Anrufe führen,

wenn es der Provider nicht explizit unterbindet und deswegen limitieren sie die Phase meistens auf irgendwas zwischen 60 und 120 Sekunden, also von wann der Anruf oft vom Klingeln quasi zum Besetzt übergeht, eben weil man sonst ja kostenlos telefonieren könnte und das will man nicht.

Aber was man sich auf jeden Fall merken kann, bald irgendeine Audioverbindung zustande kommt, kann man davon ausgehen, dass die bidirektional ist. Ein paar Problemfälle, was passiert, wenn der, wir haben ja vorhin gesehen, es gibt den 200 OK,

wenn der Anruf angenommen wurde, da hatte ich letztens das Problem gehabt in der Testinstallation, dass die Rückmeldung verloren ging, aber dadurch, dass der Anruf dann über Early Media geführt wurde, hat es erst mal trotzdem funktioniert und wurde dann allerdings nach einer gewissen Zeit beendet,

in der einen Installation nach 55 Sekunden, in der anderen nach 90 Sekunden. Bei sowas ist dann auch immer wieder Wireshark sehr hilfreich bzw. alternativ gibt es einen Kommandozeileninterface für Linux namens sngrep, was quasi entweder einen Pickup von TCP-Dump lesen kann

oder selbst direkt einen Dump machen und einem das Ganze nach Flow, also nach SIP-Anruf dargestellt schon ein bisschen auswerten kann. Screenshot habe ich leider vergessen davon reinzumachen, das wäre noch ganz gut gewesen.

Es gibt in einer SIP-Session einen Expiration Timer, der kann verwendet werden, wenn man den Anruf auf eine gewisse Zeit limitieren will, zum Beispiel auf maximal zwei Stunden, war ja früher immer so ein Limit, zwei oder drei Stunden, je nachdem bei welchem Provider oder Anschluss, dass der Anruf dann automatisch getrennt wird, damit man nicht einfach einen Hörer

nebendran legen kann und dadurch unnötige Kosten erzeugen. Der Header kann natürlich schiefgehen bei einer Sache und dann kann zwischendrin der Anruf abbrechen. Ich hatte es jetzt kürzlich gehabt, dass eine Telefonanlage nach 10 Minuten eine Update-Nachricht geschickt hat mit einer invaliden Header, eben gerade mit dem

Expiration Timer, dass der falsch war und dadurch dann der Anruf nach 10 Minuten quasi getrennt wurde bzw. das Audio war weg. Der Anruf selbst lief aber teilweise noch weiter. Je nachdem, welche Fehler da erzeugen, reagieren die Telefonanlagen auch anders, wobei die

Anruf komplett zu verwerfen. Das Dual-Stack hatten wir ja eben gerade schon gehabt, dass wenn IPv4 und IPv6 in einer schlechten Kombination zusammentreffen und die Clients sich da

entweder nicht richtig an Standard halten, wobei ich sogar vermute, dass es nach Standard so okay ist und in dem Fall blöd gelaufen ist, dass man dann nur One-By-Audio hat, eben weil die V4 und die V6-Firewall in der Regel keine gemeinsame Stay-Table haben

und dann der jeweils andere Part gar nicht weiß, um was es sich da handelt, was da reinkommt und denkt, das sind halt einfach irgendwelche unbekannten UDP-Pakete und die dann verwirft. Genau, die Packet-Time, das hatte ich vorhin auch schon kurz erwähnt, die standardmäßig 20 Millisekunden ist. Da hatte eine Fritzbox zusammen mit

dem FreeSwitch vor auch schon über 10 Jahren eben das Problem gehabt, dass sie das falsch erwartet haben, dass da der Default anders war und einer der beiden ist von 30 Millisekunden ausgegangen, dass sie ankommen. Es kam aber 20 Millisekunden

an und dadurch hat man dann so eine komplett abgehackte Stimme gehabt bzw. es halt immer wieder 10 Millisekunden, wo nichts drin war. Das sieht man dann auch ganz gut in einem Wireshark-Trace. Bei den meisten Fehlern, die im SIP auftreten, ist eigentlich Wireshark oder SN-Crep direkt das erste Tool, was man

dafür sinnvoll verwenden kann, um zu schauen, ob die Signalisierung überhaupt in Ordnung ist, weil meistens erkennt man da schon den Fehler drin. Das Packet-Time-Problem ist aber mittlerweile gelöst. Das ist jetzt nur eine historische Sache von was schiefgehen kann. Ringback-Eschul, ich habe eben

gesagt, dass man die Musik einspielen kann statt einem Freizeichen. Die Gegenstelle kann auch signalisieren, dass sie das tut oder dass sie es eben nicht tut und wenn das nicht getan wird, kann auch mein Telefon selbst aufgrund der SIP-Daten das Klingeln erzeugen. Wenn jetzt die Gegenstelle

allerdings signalisiert, dass sie dann das Freizeichen generiert und dann wenn man nichts schickt oder die Audiodaten irgendwo verloren gehen, hat man das Problem, dass man erstmal gar nichts hört. Davon ausgeht, dass es bei dem anderen noch nicht klingelt, sondern dass der Anruf noch in der

Aufbauphase ist und dann ist die Leitung plötzlich da und man hat die andere Person schon am Telefon. Das ist dann auch so eine Sache, das hatte ich letztens bei einem Freund, dass wenn er von O2-Handys aus angerufen wurde, funktioniert alles. Wenn er selbst bei jemandem zurückruft, dann hört er

nie einen Klingeln, aber nur bei dem einen Netzbetreiber. Ich weiß nicht, ob das Problem aktuell noch besteht, ich glaube nicht, aber da wird zwischendrin irgendwo ein Proxy bei einem der Provider, die innoviert sind, sein, der der Meinung ist, dass der Ton von einer anderen Stelle auskommt und da deswegen nicht generiert werden muss und in

der Möglichkeit kommt gar nichts an. Was hatten wir noch nicht gehabt? Krypto hat uns eben kurz angesprochen, das SIP ja TLS unterstützt,

das aber nur die Signalisierung verschlüsselt und das Audio mit entweder SRDP oder ZRDP verschlüsselt werden kann. ZRDP ist so ein Versuch, die Verschlüsselung zu machen, wenn es die Provider nicht wirklich unterstützen. Es gibt aber kaum Tischtelefone, die das machen.

Die Fritbox kann glaube ich gar keine Krypto. Ich glaube, sie konnte es mal und wurde aber dann irgendwann vor ein paar Jahren rausgepatcht, was zu viele Probleme damit gab, wenn ich das richtig in Erinnerung habe. Daher ist in der reellen Welt Krypto leider gar kein Thema und wenn irgendwo Krypto gemacht wird, dann erst RTP. Das wird entsprechend

mit signalisiert. Es hängt stark von dem Endgerät ab, was man dafür verwendet, ob es funktioniert und wie gut, weil die Implementierungen eben öfters mal fehlerhaft sind oder sich nicht an ein Standard halten. Und SRTP wird auch erstmal nicht gegen laufvolle Interception,

also gegen Abhörmaßnahmen, staatliche Akteure helfen, was in der Regel nur zwischen Endgerät und ZRDP ist und keine direkte Ende-zu-Ende-Verschlüsselung. Außer Audio wird direkt übertragen und der Provider filtert die Nachrichten nicht in der

Signalisierung raus, was aktuell die meisten tun. Wir hatten vorhin den RTP AVP gesehen, der darf laut Standard ausschließlich Parameter für unverschlüsselte Audiodaten enthalten. Es gibt dann extra den SAVP, also den Secure AVP, der dann hinzugefügt wird,

wo die Krypto-Parameter drinstehen. Das kann auch beides gleichzeitig im selben Inweit stehen, wenn man möchte. Damit ist dann Krypto als optional anzusehen und es hängt von dem anderen Endpunkt ab.

Sobald man eine Konfiguration trifft, dass der eine Endpoint nur das SAVP sendet und der andere aber nur AVP unterstützt, kann kein Anruf zustande kommen und es kommt in der Regel der Fehler Not Acceptable zurück. Manche PBXen verwerfen die Anrufe

je nach Konfiguration, eben wenn jetzt der Provider nur unverschlüsselte Anrufe erlaubt und er kein AVP, sondern nur ein SAVP hat, dann wird er den Anruf eben als Not Acceptable ablehnen. Manche Clients bieten es auch an, dass die Krypto-Optionen im AVP drinstehen,

was laut Standard nicht zulässig ist, trotzdem aber vorkommt. Und Yate als PBX unterstützt nur diese Option. Das Einzige, was man zu dem Bug aktuell bei Google findet, das ist im Endeffekt mein Mailinglistbeitrag auf der Yate Mailingliste von vor vielen Jahren.

Seitdem es aber nichts passiert, die Entwickler sehen das wohl nicht als Probleme an und sehen es auch nicht als notwendig an sich an den RFC an der Stelle zu halten. Die meisten Telefone haben die Konfigurationsoptionen, dass man Krypto deaktivieren kann, dass man es aktivieren und entforsieren kann. Das heißt, es gibt nur den

SAVP mit Krypto und keinen normalen AVP oder eben Enabled but not Forced ist. Dann gibt es in der Regel einen AVP und einen SAVP. Und die meisten Telefone haben noch eine vierte Option, die heißt Optional, die unterschiedliche Sachen tut.

Bei den meisten ist es so, dass entweder Enabled but not Forced oder Optional Krypto im AVP liefert und sich damit nicht an den Standard hält und mehr als Workaround für schlecht programmierte Telefonanlagen anzusehen ist. Drei Optionen würden eigentlich reichen, wenn da jetzt mal die Entwickler an den Stellen das

alle richtig implementieren würden, bräuchte man die vierte nicht. Ich habe keine Ahnung, wie es bei Krypto mit nicht Open Source Telefonanlagen aussieht. Also da kenne ich aktuell nur Asterisk Yate und FreeSwitch. Ich vermute mal, dass es bei den anderen, die nicht auf den dreien basiert, noch schlechter aussieht mit Unterstützung dafür. Die Negotiation sieht dann

so aus. Wir haben hier wieder unseren SDP wie vorhin. Man sieht jetzt hier das RTP SAVP statt RTP AVP steht und zusätzlich zu den Sachen unten sind die Krypto-Header mit reingekommen.

Welche Verschlüsselung, also in dem Fall AES, mit welchen Optionen und Keys unterstützt wird. In dem Fall ist es jetzt ein Anruf, der nur den SAVP enthält, das heißt das Endgerät akzeptiert ausschließlich verschlüsselte Anrufe. Wenn das auch unverschlüsselte beinhalten würde, dann wäre der gleiche Block

noch mal drin, nur hier mit einem RTP AVP, aber auch wieder welche Codex. Theoretisch ist es über den Weg auch möglich verschlüsselte Anrufe mit einem besseren oder schlechteren Codec durchzuführen als unverschlüsselte. Praktisch macht es wenig Sinn. Die meisten Telefone und die meisten Endgeräte zeigen es dem Kleindorfen, ob ein Anruf verschlüsselt ist oder

nicht. Meistens sieht man dann einen Schloss. Fax wurde vorhin auch noch oder wurde allgemein noch gefragt. SAVP ist 2020, aber wir sind immer noch in Deutschland und von daher ist Fax immer noch ein großes Thema. Eine Möglichkeit Faxe zu

übertragen ist die Töne, die das Faxgerät sendet, einfach genauso zu encodieren wie auch die Sprache, die man ins Telefon reinspricht, also in G711-Codec. Das geht aber kaputt, wenn der Jitter zu hoch ist, weil sich dann die Faxgeräte nicht mehr darauf einigen können. Die Alternative dazu ist T38. Das ist ein Codec, der extra für Fax über

VoIP entwickelt wurde, basiert auf UDP und in dem Fall ist das lokale T38-Gateway, re-encodiert die Sachen und

sendet sie als T38 übers Internet und genauso auf der anderen Seite, wenn es wieder beim anderen Gesprächspartner ankommt, empfängt er die T38-Daten und macht wieder

T38. Das muss der Provider unterstützen, weil es ein spezielles Protokoll ist, was darüber genutzt wird und völlig überraschend macht das nicht jeder. Was ich aktuell weiß, die Telekom unterstützt das. Generell ist die Telekom bei Unterstützung von Protokollen und Codecs sehr offen und sehr bemüht. Von dem, was sie im Internet

gefunden hat, unterstützt Unity Media zum Beispiel nicht. In dem Fall ist halt die Übertragung rein wie Sprache die einzige Möglichkeit ist zu tun. Ja, damit wäre ich an der Stelle durch, mit dem was ich hier geplant hatte und wäre offen für Fragen. Okay, same drill as before. Wir

schalten euch der Reihe nach frei, falls ihr was sagen wollt, ansonsten schreibt die Fragen einfach in den Chat. Das hat gerade sogar schon jemand getan. Kennst du ein

Reihe? Nee, an der Stelle nicht, sondern rein je nachdem auf was du raus willst. Am ehesten Wireshark und Einstellungen, ein Telefon, ein SIP-Server, entweder

eine Softphone und ein Free-Switch oder was auch immer du da rumstehen hast oder eine Fritzbox, kann man ja auch einen eigenen SIP-Server hängen und dann damit rum experimentieren und ändern vor und zurück

und dann dir das dann damit anschauen. Die Alternative zu Wireshark ist SN-Grep. Ich schreibe es jetzt mal hier in den Chat. Also SN und dann Grep, wie normalerweise Grep unter Linux funktioniert. Ja, es ist ein

Kommando-Zeilen-Tool, was einem ähnlich wie TCP-Dump quasi das N-Curses-Interface, die die Pakete dann anzeigt, einen auswählen lässt, den Flow und damit

das Troubleshooting verbessern kann. Manche SIP-Anlagen haben das sogar schon direkt drauf, wenn man da ein paar SSH draufkommt. Bei Debian und Ubuntu ist es soweit ich weiß, ein Repository ist drin, da kann man es einfach nachinstallieren. SN-Grep Port 5060, also Filter wie bei TCP-Dump machen und dann sieht man

die SIP-Nachrichten, wie sie rein und rauskommen, kann sich dann auch direkt nach Analysen von den beiden Endpunkten machen, muss es nicht manuell aus einem TCP-Dump rausfiltern. Wireshark selbst hat auch entsprechende Filter, um SIP-Anrufe zu erkennen und den richtigen Flows zuzuordnen. Gibt es

bei Lidia-Use-Cases bidirektionelles Early-Media? Grundsätzlich kann man damit die üblichen

Sprachansagen, wenn Sie mit dem Ansprechpartner sowieso reden wollen, sagen Sie Support, wenn Sie eine Handfrage an den Vertrieb haben, sagen Sie Vertrieb, auch schon bei dem Early-Media umsetzen. Da aber das Early-Media meistens zeitlich beschränkt ist, kommt man da relativ schnell an

die Grenze. Aber im freien Feld habe ich bisher noch nicht beobachtet, dass an der Stelle irgendwas mit Early-Media aktiv durchgeführt wird. Das hieße doch dann auch, wenn ich das richtig verstanden habe, dass ich als Anrufer auch Early-Media als Antwort schicken müsste, genau. Das ist so. Grundsätzlich schon. Man muss

immer davon ausgehen, sobald Early-Media in irgendeine Richtung geht, dass es in die andere auch geht. Plus kann es natürlich auch sein, dass das Early-Media keine Musik oder keine Ansage ist, sondern einfach das ganz normale

Freizeichen, was man da auch erwarten würde. Also wenn man davon ausgeht, dass das Mikrofon aktiv ist, sobald man einen Anruf startet, ist man an der Stelle auf der sicheren Seite. Ins Telefon reinfluchen, während man irgendwo in einer Warteschleife hängt. Ja, kann passieren,

dass das irgendjemand mitbekommt. Also nicht nur der Nachbar, wenn man zu laut redet. Gibt es da Vorgaben? Das ist beim nächsten Support-Anruf. Genau. Ob es Vorgaben zur Codec-Vielfalt und den Carrier-Interconnects gibt? Nein, soweit ich weiß nicht. Also Standard G711 sollte natürlich überall oder muss wahrscheinlich überall unterstützt werden.

Die Telekom ist aktuell dabei, die ganzen Nicht-Zip-Interconnects abzubauen. Ich vermute mal, dass sie bei kleinen Carriern anfangen und dann sich die großen Carrier bis zum LF heben und das nach und nach machen. Wahrscheinlich auch regional ein bisschen abhängig. Die

Telekom hat natürlich Vorgaben, was sie für Codex minimal voraussetzen, was da unterstützt ist. Auch wie die Signalisierung auszusehen hat, genauso unterdrückte Rufnummern. Das ist auch immer ein Szenario, weil eine unterdrückte Rufnummer zwischen Providern immer durchsignalisiert wird bis zum letzten

Provider und der erst dann die Information vom Anrufer rausnimmt und das seinem Kunden dann nur noch als unterdrückten Anruf zustellt. Außer der Kunde hat aufgrund von rechtlichen Vorgaben entsprechend die Freigabe, dass er auch unterdrückte Anrufe sieht. Ich

weiß nicht, wie das im Moment so ist. Früher war es bei Rettungsleitstellen so, dass sie die Nummer immer gesehen haben. Dann kam der Datenschutz um die Ecke und war der Meinung, dass es so nicht zulässig ist, dass sie die immer sehen, sondern dann nur in Ausnahmefällen. Da weiß ich nicht, wie das im Moment genau umgesetzt ist. Worin unterscheiden sich ZRTP

und SRTP und kann ECC verwendet werden. ECC habe ich da noch gar nicht gesehen. Bei SRTP wird es mich wundern, wenn es in nächster Zeit kommt. ZRTP die Signalisierung eher inbent im Codec zu machen, also versteckt quasi in den Audiodaten

Hinweise darauf, dass Verschlüsselung möglich wäre, um es Providern zwischendrin schwieriger zu machen, das rauszufinden und zu unterdrücken. Wobei bei SRTP wird quasi beim Anruf Aufbau mitgeteilt, dass man SRTP unterstützt und ZRTP wird erst mitgeteilt, sobald der

Anruf zustande gekommen ist und auch schon Audio läuft, also quasi im G711 oder im G722 werden dann Nachrichten in die Header gepackt. Damit habe ich mich noch nicht so intensiv beschäftigt, weil es in der Praxis ein Providernetz aktuell keine Relevanz hat. Keine Relevanz

liegt daran, dass es einfach noch nicht verbreitet ist? Ja, genau. Also ich glaube sogar, die Telefonanlagen bei Firmen hängen ja eh immer lange hinten dran. Die verbreitesten Router bei Privatkunden

sind halt einfach Fritzboxen, die unterstützen das nicht. Und daher sage ich mal, fallen schon die meisten Endgeräte raus. Mobiltelefone unterstützen es auch nicht, also im Mobilfunknetz gibt es eigene Krypto, aber das ist nochmal ein großes Thema. Aber es hat ja noch

kein Kunden-Ticket bei uns aufgemacht, dass ZRTP nicht funktionieren würde oder da Probleme hat. 3CX bin ich

öfters mal drüber gestolpert. Nie die Zeit gehabt, das mal anzuschauen, bisher nicht groß den Bedarf gehabt. Hatte ich mal vor gehabt, bisher einfach nicht dazugekommen.

Habe ich jetzt aber auch nichts negatives zugehört. Im Gegenteil, es hat mir vor einer Weile, als ich mal so ein bisschen im Freundeskreis rumgehört habe, was die denn so als Anlagen bei sich bzw. bei ihren Kunden verwenden, war das auch eine der Antworten, die man gehört hat, was da gerne mal verwendet wird. Vor allem, weil es auch als Appliance

geht, man damit wohl relativ wenig Wartungsaufwand haben soll. Selbst getestet, aber noch nicht. Die Frage drehte sich um Telefonanlagen vom Hersteller 3CX, richtig? Ja, genau. Ich glaube sogar, dass ich bei einem der Telefone hier auf dem Campground,

wo ich gerade bin, das 3CX-Logo gestern gesehen habe, also die setzen das wohl hier auf dem Campingplatz ein. Würde ich dir jetzt aber auf jeden Fall nicht davon abraten, das mal auszuprobieren.

Okay, wenn sonst keine Fragen mehr da sind, gerade nicht so aus,

dann würde ich sagen, danke Nico. Danke fürs Zuhören. Und vielleicht sehen wir uns ja nachher im Social-Raum wieder. Wenn ich das richtig im Kopf habe, wird es dann nachher einen Link auf der Hauptseite geben, wo ihr euch in den Raum reinklicken könnt.

Es gibt auf jeden Fall ein bisschen Musik. Da kam noch gerade eine Frage von Susa, heißt das 1&1 hängt an alten Telekom-Kopplungen. Ja, wobei jetzt 1&1 hat ja Versatel vor einer Weile gekauft und Versatel ist teilweise auch schon allerdings selbst auf SIP-Kopplungen akzeptiert, Versatel nichts

außer G711 und G722. Also selbst auf eine SIP-Kopplung zur Telekom wurde bis vor einer Weile nur die beiden Codecs zugelassen. Dass die Telekom SIP auf ihren Kopplungen, die Codecausfall auf ihren Kopplern komplett unbeschränkt gemacht hat, ist glaube ich erst

seit ein, zwei Jahren oder so der Fall und die wenigsten Provider haben sich da jetzt darum gekümmert, das zu ändern, weil der Bedarf noch nicht so groß war und vermutlich Verträge geändert werden müssen. Von Versatel habe ich die Aussage bekommen, dass es da aktuell keine Pläne gibt, das zu ändern. Gut, das war es dann jetzt aber.