Vortrag zum Thema: „Vorzeitige Medienautorisierung Unter welchen Bedingungen sollen die Medien vor 2008 fließen (INVITE)? In: Richard Ejzak.“- Präsentationstranskript:
1 Frühe Medienautorisierung Unter welchen Bedingungen sollten ausgehandelte Medien vor 200 OK (INVITE) fließen? Richard Ejzak
2 Was RFCs über frühe Medien sagen
Einige RFCs gehen davon aus, dass (frühe) Medien sofort nach der Signalisierung von SDP gemäß der signalisierten Direktionalität (RFC 3264) fließen können, wenn die Voraussetzungen erfüllt sind (RFC 3312) Keine Ausnahmen für frühe Medien beschrieben Andere RFCs beschreiben Bedingungen, unter denen frühe Medien nicht gerendert werden RFC 3261: 180 Antwort „kann verwendet werden, um einen lokalen Rückruf zu initiieren“ RFC 3960: Darf beim Forking nicht mehrere Quellen rendern „Eine Benutzerkontensteuerung sollte ihre lokale Richtlinie zur lokalen Klingelerzeugung entwickeln“
3 Was das PSTN über frühe Medien sagt
„Antwort“ ist normalerweise der Auslöser für den Beginn der Abrechnung Benutzer erwarten nicht, dass unbeantwortete Anrufe in Rechnung gestellt werden Netzwerke erlauben es Benutzern nicht, Daten auszutauschen, bevor „Antwort“ Der Abschlussschalter „schneidet“ normalerweise Medien an den Angerufenen weiter „Antwort“ Der Abschlussschalter bietet „Anruffortschritt“ frühe Medien für den Anrufenden Es gibt keinen „Abschlussschalter“ für den Angerufenen frühe Medien in einem typischen SIP-Netzwerk überwachen Woher wissen wir, ob frühe Medien mit einer autorisierten Netzwerkentität oder einem Endbenutzer ausgetauscht werden?
4 Einige Anwendungen der frühen Medien
Wiedergabe benutzerdefinierter Klingelton (CRBT) Wiedergabe von Netzwerkansagen Fehlermeldungen Weiterleitung von Warteschlangen usw. Prompt und sammeln add’l dialing info Verfügbarkeit von Medienpfad zu bestätigen
5 Lokale politische Optionen Einige Implementierungen verbieten frühe Medien:
Vor dem Empfang der SDP-Antwort (um zu überprüfen, ob das Ziel kontaktiert wurde) Vor dem Empfang von 200 OK (EINLADUNG) (um eine alternative / lokale Warnanzeige bereitzustellen) Von einer anderen RTP-Quelladresse als der Remote-RTP-Zieladresse (kann Clipping oder vollständige Medienblockierung verursachen) Um alternative Anruffortschrittsinformationen (CRBT) zu rendern Um alternative Medien / Dialoge (Forking) zu rendern, Wenn die Medienfunktionen eingeschränkt sind (z., parallele Sitzungen), Um Alert-Info-Header-Medien Vorrang einzuräumen, um Early-Session-Medien Vorrang einzuräumen, um einen potenziell betrügerischen Austausch von Benutzerdaten zu verhindern, wenn die Abrechnung mit „Antwort“ beginnt“
6 Welche Medien müssen vor der „Antwort“ gerendert werden?
Lokaler Rückruf nach Erhalt von 180 Antworten Alert-Info Header Medien Frühe Medien Frühe Sitzungsmedien Medien aus alternativen Dialogen Unklar, wie diese verschiedenen Quellen priorisiert werden sollen Flexibilität der lokalen Politik erforderlich
7 Wie schalte ich unerwünschte Quellen aus?
Stummschaltung des Medienanrufs HALTEN (a = sendonly) Black-Hole-Adresse (Null-Adresse im Angebot) Voraussetzungen Blockieren (Gating) nur von Medien Netzwerkoption bei der Bereitstellung des Endbenutzers SIP-Gerät Medienpakete akzeptieren, aber nicht für den Benutzer rendern
8 Probleme mit der Stummschaltung Woher wissen wir die Absicht des Anbieters?
Benachrichtigen wir einen Benutzer, wenn wir ein inaktives oder Sendonly-Angebot erhalten? Welche Ressourcen reservieren wir für die Sitzung? Woher weiß der Answerer, dass HOLD bei 200 OK (INVITE) sofort entfernt wird? Black Hole address better Kann die Absicht des Benutzers nicht verwirren Woher wissen wir, wen wir während des Forkings stummschalten sollen? Mehr Media Clipping als mit Media Blocking
9 Probleme beim Blockieren
Interaktionen mit RTCP Sollten keine genauen Berichte über den Datenverkehr vor 200 OK (INVITE) erwarten Interaktionen mit ICE Können Quellen während des parallelen Forkings nicht identifizieren
10 RFC 3960 Empfehlungen Frühe Medien haben Vorrang, wenn vorhanden
Andernfalls wird Ringback / Alert-Info / early-session gerendert, bis Medien angezeigt werden Andere Verfahren sind gemäß den lokalen Richtlinien zulässig Zum Beispiel verwendet SIP-I frühe Medien ausschließlich Empfohlene Prozeduren, die während des parallelen Forkings zusammenbrechen, wenn eine höhere Priorität für alternative Medien (z., CRBT), Wenn Quellen früher Medien aufgrund von Abrechnungsrichtlinien kontrolliert werden müssen
11 draft-ejzak-sipping-p-em-auth-01 konzentriert sich auf das Problem
Gilt nur für private Netzwerke mit transitivem Vertrauensmodell Netzwerk kann Medienblockierung (Gating) in der Nähe von UAs durchführen Identifiziert autorisierte Quellen früher Medien, um Blockierungen zu vermeiden Funktioniert gut mit RFC 3960, da autorisierte frühe Medien immer bestanden wurden und Vorrang haben Erhebliche Einwände erhoben, da UAS nicht weiß, wann blockierung erfolgt Netzwerk kann ohne Header blockieren Keine Garantie, dass frühe Medien gerendert werden
12 Header-Definition P-Early-Media = sendrecv – both way media allowed = sendonly – backward media allowed = recvonly – forward media allowed = inaktiv – keine Medien erlaubt Gesendet von UAS an UAC, um die Autorisierung für frühe Medien anzuzeigen Proxies können aus Sicherheits- oder Richtliniengründen ändern Hinweis darauf, dass rückwärts frühe Medien mit „sendonly“ oder „sendrecv“ autorisiert sind, zeigt auch an, dass geben Sie Anruffortschrittsmedien an, die gerendert werden sollen Hinweis darauf, dass Rückwärtsmedien nicht mit „inaktiv“ oder „recvonly“ angezeigt werden, zeigt auch an, dass das lokale Ende gerendert werden soll Eine andere Quelle Kann eine anfängliche Einladung senden, um die Unterstützung des Headers anzuzeigen
13 Abgelehnte Alternativen zum Entwurf
Verwenden Sie das Option-Tag im erforderlichen Header, um anzuzeigen, dass frühe Medienautorisierungsverfahren verwendet werden können UAS kann frühe Medien anfordern, aber möglicherweise nicht erhalten Verwenden Sie das Option-Tag im erforderlichen Header, um anzuzeigen, dass frühe Medien blockiert werden Verhindert, dass das Netzwerk implementieren von Richtlinien basierend auf Informationen in Antworten (muss im Voraus entscheiden) Transitives Vertrauensmodell (Treffen von Autorisierungsentscheidungen basierend auf der Kenntnis des Next-Hop-Servers) kann außerhalb von Netzwerkanrufen mit keinem der beiden Ansätze angewendet werden schlägt fehl, es sei denn, UAS wird aktualisiert (kein Anreiz zum Upgrade außerhalb des privaten Netzwerks) Jede Änderung verhindert effektiv, dass das private Netzwerk die Erweiterung verwendet, um den Zugriff auf frühe Medien zu steuern
14 Blockieren an der Grenze des privaten Netzwerks
Der Header wird nicht unbedingt benötigt, wenn blockiert wird die Politik wird an dem Ort umgesetzt, an dem die politische Entscheidung getroffen wird, z. B. an der Netzwerkgrenze (SBC) Warum ist sie so umstritten? Header ermöglicht die Verwendung vorhandener Medienkontrollpunkte in Netzwerken wie IMS (at P-CSCF) Header ermöglicht die Verbindung ohne SBC zwischen vertrauenswürdigen Netzwerken Implementierung verschiedener Richtlinien für die frühe Medienautorisierung
15 Zusätzliches Problem zu lösen?
Bereitstellung von Mitteln für UAS, um festzustellen, ob frühe Medien gerendert werden, damit UAS alternative Verfahren in Betracht ziehen können, wenn frühe Medien nicht verfügbar sind Würde das bestehende Problem getrennt von der frühen Medienautorisierung lösen Sollte es dem bestehenden Entwurf ermöglichen, fortzufahren Bietet Anreiz für UAs, die die Verfügbarkeit früher Medien benötigen, um eine neue Erweiterung zu implementieren
