-
GEBIET DER ERFINDUNG
-
Sie
Erfindung betrifft ein System und ein Verfahren zum Übertragen
von Streaming-Video-Inhalt von mobilen Endgeräten an einen Streaming-Video-Server
im Internet. Die Erfindung betrifft auch ein Gateway zur Verwendung
für die Übertragung
von Streaming-Video-Inhalt an mobile Endgeräte.
-
HINTERGRUND DER ERFINDUNG
-
Die
Verkäufe
von Digitalkameras und Handykameras nehmen rasch zu. Die Verwendung
dieser Kameras für
Fastechtzeitaufnahmen von Ereignissen während des Urlaubs, auf Geschäftsreisen
usw. bleibt auf dem Niveau des Sendens von Bildern oder kurzen Videoclips über E-Mail. Im Heimbereich
verwenden die Leute bereits so genannte WEB-Kameras, um sich zum
Beispiel im Internet darzustellen. Die Einführung des Internetbreitbandzugangs über Kabel
und ADSL macht diese Dienste noch populärer.
-
US 2002/0024945 A1 (Civanlar
et al.) offenbart ein Verfahren und eine Vorrichtung zur Herstellung
einer Kommunikationssitzung zwischen ersten und zweiten Endgeräten in Kommunikation über mehrere
Netze, die verschiedene Übertragungsstandards
einsetzen, wobei die mehreren Netze unter einem leitungsvermittelten
Netz, einem verbindungslosen paketvermittelten Netz und einem verbindungsorientierten
paketvermittelten Netz ausgewählt
werden.
-
KURZDARSTELLUNG DER ERFINDUNG
-
Die
Erfindung stellt ein Telekommunikationssystem vor, das zur Übertragung
von Streaming-Video-Signalen von mobilen Endgeräten an einen Internet-Streaming-Server
fähig ist,
wobei es von einem Gateway Gebrauch macht, das auf der einen Seite
mit dem leitungsvermittelten Netz verbunden ist und auf der anderen
Seite mit dem Internet verbunden ist, wobei das Gateway zur Konvertierung
von Streaming-Video-Bitströmen
in einem Format, das geeignet ist, von den mobilen Endgeräten über das leitungsvermittelte
Netz empfangen zu werden, in Dateien mit einem Internet-kompatiblen
Streaming-Video-Format fähig
ist. Da es heutzutage keine Standardprotokolle gibt, damit solch
ein Konvertierungs-Gateway mit mobilen Endgeräten kommuniziert, kann als
eine bevorzugte Option von einem standardisierten Protokoll für Videokonferenz
zwischen mobilen Endgeräten
Gebrauch gemacht werden. Es ist zu erwähnen, dass solche Videokonferenzprotokolle
zur Verwendung in Architekturen entwickelt wurden, in welchen zwei
oder mehr Benutzer mit videokonferenzfähigen Mobiltelefonen eine Videokonferenz
miteinander abhalten können.
-
Um
solch ein „Videokonferenzprotokoll" zum Hinauf laden
von Streaming-Video-Inhalt auf einen Internetserver oder -client
verwenden zu können, sind
die mobilen Endgeräte
und das Gateway auf der einen Seite vorzugsweise zum Austauschen
von Videobitströmen
fähig,
die einem Protokoll für
eine Telefon-zu-Telefon-Videokonferenz entsprechen. Das ITU H.324M
Videokonferenzprotokoll kann sich für den beabsichtigten Zweck
sehr gut eignen.
-
Ein
Aspekt der Erfindung ist es demnach, ein Protokoll, das für ein anderes
technisches Gebiet, nämlich
für Telefon-zu-Telefon-Videokonferenzen, standardisiert
ist, zu verwenden, um das Hinaufladen von Streaming-Video-Inhalt, der durch
mobile Endgeräte
erzeugt wird, ins Internet zu ermöglichen.
-
Ein
zweiter Aspekt der Erfindung behandelt das Management der Videoinhaltspeicherung.
Um Speicherziele der konvertierten Streaming-Dateien managen zu
können,
umfasst das System einen Registrierungsserver, welcher mit den mobilen
Endgeräten
z.B. durch das paketvermittelte Netz verbunden und fähig ist,
für jedes
relevante mobile Endgerät eine
Endgerätekennung
zu registrieren und diese Kennung mit der Adresse einer Internetspeicherstelle zu
verknüpfen,
an welcher das Internet-kompatible Streaming-Video, das durch das
relevante mobile Endgerät
erzeugt wurde, gespeichert ist oder gespeichert werden soll. Um
die Verwendung solch eines Registrierungsservers zu ermöglichen,
umfasst das System vorzugsweise Mittel zum Erfassen über das leitungsvermittelte
Netz der Kennung des relevanten Endgeräts (z.B. seine Anschlusskennung
als rufende Station CLI für
engl. calling line identifier), sowie Mittel zum Abrufen beim Registrierungsserver,
geführt durch
die erfasste Endgerätekennung,
der Adresse der Internetspeicherstelle, an welcher das Internetkompatible
Streaming-Video, das durch das relevante Endgerät erzeugt wurde, gespeichert
werden soll, und zum Weitersenden des Internet-kompatiblen Streaming-Videos
an diese Internetspeicherstellenadresse.
-
Vorzugsweise
befinden sich die Mittel zum Erfassen der relevanten Endgerätekennung
und die Mittel zum Abrufen beim Registrierungsserver der Adresse
der Internetspeicherstelle und zum Weitersenden des Internetkompatiblen
Streaming-Videos an diese Internetspeicherstellenadresse innerhalb des
Konvertierungs-Gateways. Als Alternative können sich die Erfassungsmittel,
die Abrufmittel und die Weitersendemittel im Registrierungsserver
befinden; in diesem Fall wird die Ausgabe des Gateways – welche
die Endgerätekennung
umfasst – an
den Registrierungsserver gesendet, welcher den konvertierten Inhalt
anschließend
an die relevante Speicherstelle verteilt, geführt durch die Endgerätekennung,
die auf die relevante Speicheradresse zeigt. Eine andere Option
ist, die Erfassungsmittel, die Abrufmittel und die Weitersendemittel
auf irgendeinem anderen Server angeordnet zu haben oder diese Mittel über verschiedene
Server verteilt zu haben.
-
Bei
der vorgeschlagenen Architektur in Kombination mit z.B. H.324M-Videokonferenzprotokoll-fähigen Telefonen
ist es möglich, „Live"-Sendungen von geplanten
und ungeplanten Ereignissen wie Partys, Autounfällen usw. von jedem solcher
Mobiltelefone unter Verwendung von Standardkomponenten – mit Ausnahme
des Konvertierungs-Gateways
und des bevorzugten Registrierungsservers – auf Internetserver und -clients
(z.B. PCs oder anderen Mobiltelefonen) auszuführen.
-
Das
Telekommunikationssystem kann Mittel zum Senden einer Meldung an
das Endgerät,
welches den Streaming-Video-Inhalt
erzeugt oder erzeugte, umfassen, die eine Verbindung zur Speicherstelle
dieses Inhalts umfasst.
-
Diese
Mittel können
auch zum Senden einer ähnlichen
Meldung an ein oder mehr andere Benutzerendgeräte als das erzeugende Benutzerendgerät fähig sein,
die eine Verbindung zur Speicherstelle des Inhalts und/oder wenigstens
einen Teil des Streaming-Video-Inhalts selbst umfasst. Die relevanten Meldungen
an das Erzeugerendgerät
und/oder die anderen (Nichterzeuger-) Endgeräte können z.B. als E-Mail-Meldungen, „SMS"-Meldungen oder (z.B.
-
MSN-
oder ICQ-basierte) „Sofortmeldungsübermittlungs"-Meldungen gesendet werden.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
1 stellt
die Architektur einer bevorzugten Ausführungsform der Erfindung dar.
-
2 stellt
eine beispielhafte Implementierung des H.324M-Gateways dar.
-
AUSFÜHRLICHE BESCHREIBUNG DER ZEICHNUNGEN
-
In 1 sind
Endgeräte 1 über Basisstationen
und eine „Funknetzsteuerung" (RNC für engl. Radio
Network Controller) 2 mit einem leitungsvermittelten Netz
(CSN für
engl. Circuit Switched Network) 3 und einem paketvermittelten
Netz (PSN für engl.
Packet Switched Network) 4 verbindbar. Über das PSN 4 können die
Endgeräte 1 im
Internet (IP) 5 blättern,
nämlich über ein
Internet-Gateway (IG) 6 (a). Endgerätebenutzer können über das
PSN 4 bei einem Authentifizierungs-WEB-Server 9 (AWS)
einen „Streaming-
und Mailing-Dienst für
mobile WEB-Kameras" abonnieren
(b), der autorisierte Benutzer dazu befähigt, Videoinhalt zu einen
IP-Streaming-Server (SS) 9 zu streamen (f). Ein Teil des Abonnierungsprozesses
beim Authentifizierungs-WEB-Server 8 können die Telefonnummer und die
Mail-Adresse des Benutzers sein.
-
Während des
Abonnements erhält
der Benutzer eine Speicherstellenadresse in einer (nicht explizit
dargestellten) Datenbank beim Streaming-Server 9 zugeordnet,
welche dem Benutzer durch eine E-Mail oder eine SMS mitgeteilt werden
kann. Die Speicherstelle enthält
die Datenstromdateien des Benutzers, wenn der Benutzer ein „mobile
web camming" durchführt. Die
Adresse dieser Speicherstelle wird in einer nicht explizit dargestellten)
Datenbank beim AWS 8 gespeichert; die Speicherstellenadresse wird
mit der Telefonnummer des Benutzers verknüpft.
-
Wenn
ein interessantes Ereignis eintritt, kann ein Benutzer über das
Endgerät 1 die
Nummer eines H324-Gateways 7 wählen (c),
woraufhin der Benutzer das Ereignis „live" ins Internet streamen und es z.B. auf
dem Streaming-Server 9 speichern kann (e). Bevor das Streaming über den
Streaming-Server 9 beginnt, überprüft das H.324-Gateway 7 die
Anschlusskennung des rufenden Benutzers (CLI) – die Telefonnummer des Benutzers – beim Authentifizierungsserver 8 und
ruft, geführt
von der CLI des Benutzers, die Speicherstelle des Benutzers für den hinaufgestreamten
Inhalt (d) ab. Über
das Internet 5 können
PC-Benutzer 10 den hinaufgestreamten Inhalt vom Streaming-Server 9 über einen PC-Streaming-Client
sehen (g), und zwar sowohl live als auch nachdem er eine Welle an
der relevanten Speichestelle gespeichert wurde.
-
Am
Beginn, während
und nach der Videoaufzeichnungssitzung kann der Benutzer mithilfe
eines Meldungsservers (MS) 11 eine E-Mail- oder eine SMS-Meldung
auf dem Telefon 1 des Benutzers oder eine Meldung über eine „Sofortmeldungsübermittlung" (IM für engl.
Instant Messaging) auf einem PC 10 des Benutzers – über das
IP-Gateway 6 und
das PSN 4 – und/oder
dem PC 10 des Benutzers empfangen, die eine Verbindung
mit dem Speicherstelle des gespeicherten Inhalts umfasst (h, i).
Neben dem Senden einer Meldung an das Telefon des Benutzers, um den
Benutzer über
die relevante Speicheradresse zu informieren, wird vorzugsweise
eine Option ermöglicht,
um neben dem Benutzer selbst auch andere Telefon- und PC-Benutzer
zu benachrichtigen, wenn die Aufzeichnung eines Streaming-Videos
beginnt oder wenn sie geendet hat. Zum Beispiel können Benutzer
die Aufmerksamkeit ihrer Freunde auf das neueste Video des Benutzers
lenken, das über
das mobile Endgerät
des Benutzers aufgenommen wurde. Die Benachrichtigung kann unter
Verwendung des Meldungsservers 11 am Beginn der Streaming-Video-Sitzung,
während
dieser Sitzung oder nach der Sitzung an diese Freunde gesendet werden.
Als eine Zusatzoption kann die Streaming-Video-Datei oder ein Teil
davon (wie ein einführender Video-„Trailer") in die Meldung
aufgenommen oder an sie angehängt
werden.
-
Ein
Anruf von einem mobilen Endgerät 1 zum H.324-Gateway 7 kann über einen
vermittelten 64-kbit-Kanal geleitet werden. Das H.324M-Gateway 7 kann über eine
ISDN-Standardverbindung
mit leitungsvermittelten Netz 3 verbunden sein. Aufgrund dieses
einfachen Verbindungsmodells kann eine Verbindung mit dem H.324-Gateway von anderen UMTS-Netzen
möglich
sein.
-
Schließlich wird
eine beispielhafte Software-Implementierung
des H.324M-Gateways beschrieben, die in 2 dargestellt
ist. 2 enthält die
folgenden Bezeichnungen:
-
- A
- StartThread
(Thread starten)
- B
- Initiate
(Einleiten)
- C
- Set/ClearMuxEntryIn
(Mux-Eingabe-Ein setzen/löschen)
Set/ClearMuxEntryout (Mux-Eingabe-Aus setzen/löschen)
SetMuxPriorities
(Mux-Prioritäten
setzen)
HangUpCall (Einhängen-Ruf)
- D
- CallHungUp
(Verbindung in Einhängezustand versetzt)
- E
- Set/WriteAudio
(Audio setzen/schreiben)
Set/WriteVideo (Video setzen/schreiben)
- F
- SetSDU
(SDU setzen)
InitCPBufferListener (Zuhörer von zyklischem
Paketpuffer
auslösen)
Open.../Close...(Öffnen.../Schließen...)
- G
- Open.../Close...(Öffnen.../Schließen...)
SetLogicalParamOut
(logische Parameter-Aus setzen)
IsChannelOpen (Ist Kanal offen)
EncodeAndSendLayer1SDU
(Schicht-1-SDU codieren und senden)
- H
- WriteAudio
(Audio schreiben)
WriteVideo (Video schreiben)
- I
- RxDataToAISDU
(Rx-Daten an AISDU)
RxDataToAIPDU (Rx-Daten an AIPDU)
- J
- DoSend
(Senden)
GetAIOut (AI-Aus einholen)
- K
- DistpatchASN1Message
(ASN1-Meldung abfertigen)
- L
- BufferNotEmpty
(Puffer nicht leer)
- M
- GetSDU
(SDU einholen)
GetLayerType (Schichtart einholen)
GetCurrentSDUSize
(Aktuelle SDU-Größe einholen)
IsChannelOpen/Segmentable
(Ist Kanal offen/segmentierbar)
- N
- TimerPlayerEvent
(Timer-Player-Ereignis)
- O
- SendData
(Daten Senden)
- P
- DataReceived
(Daten empfangen)
DataRequested (Daten angefordert)
HungUp
(Eingehängt)
- Q
- IntraStart/StopPlayer
(IntraStart/Stopp Player)
DetermineVideoRate (Videorate bestimmen)
SetCapabilities
(Eigenschaften festlegen)
- R
- (Control)
(Steuerung)
ResetSRP (SRP rücksetzen)
PutPDU
(PDU setzen)
- S
- (Video)
Retransmit
(Erneut senden)
PutPDU (PDU setzen)
- T
- DoRecord
(Aufzeichnen)
- U
- EncodeAndSendLayer1SDU
(Schicht-1-SDU codieren und senden)
- V
- SendLayer2SDU
(Schicht-2-SDU senden)
SendLayer3SDU (Schicht-3-SDU senden)
- W
- H245-timer
(H245-Timer)
-
Beschreibung der H.324M-Software
-
CODIERUNGSPRINZIPIEN
-
Einige
Prinzipen, die verwendet wurden (an vielen Stellen, aber nicht überall):
- – eine
Klasse ist in einer .h-Datei plus einer .cpp-Datei mit demselben Dateinamen wie die Klasse.
- – Parameter
beginnen mit einem f, globale Variable mit g, reale Konstante mit
c. Lokale Variable können
mit l beginnen. Attribute (Klassendatenelemente) beginnen mit einem
a.
- – Klassennamen
beginnen mit einem Großbuchstaben.
Funktion, Parameter und Variablenamen beginnen mit einem Kleinbuchstaben.
- – aussagenlogisch
werden BOOL, TRUE (wahr) und FALSE (falsch) verwendet und keine
anderen Schreibweisen, die dasselbe bedeuten würden (da sie etwas unterschiedliche
Implementierungen haben).
- – Codeelemente,
die zu beachten sind (aufgrund einer „dirty" (verfälschten) oder „lazy" (verzögerten)
Programmierung), sind mit zwei @-Zeichen (@@) markiert.
-
ALLGEMEINE STRUKTUR
-
Der „MMM.EXE"-Quellcode besteht
aus 3 Hauptabschnitten, welche jeweils als ein „project" in MS Visual C++ definiert sind:
- – H245
- – H245-Codec
- – MMM
-
H245
und H245codec sind Bibliotheken, die mit MMM miteinander verknüpft sind.
Dies geschieht aus praktischen Gründen: die H245-Meldungssyntax (H245codec)
und die Meldungslogik (H245) wurden getrennt entwickelt. Aus historischen
Gründen
bezieht sich mancher Quellcode auf „Arena", einen alten Namen für die MMM-Anwendung.
-
GLOBALE (HILFS) KLASSEN
-
Für allgemeine
Zwecke gibt es einige passende Klassen:
EString – eine „bessere" Version von CString
IniFile – eine Klasse
zum Lesen und Analysieren der MMM-Konfigurationsdatei
SessionLog,
Log – Klassen
zum Ermöglichen
des Einloggens mit Kontextinformationen in einem Mehrpfadprogramm
SafeFile – eine Thread-sichere
Eingabe/Ausgabe-Dateiklasse
TimerHandler,
TimerObject – Timer-Klassen
(hauptsächlich
H245-Timer)
-
THREADS
-
Um
Microsofts Art eines Mehrpfadprogramms einzukapseln, wurde eine
eigene Thread-Bibliothek erstellt.
-
Grundsätzlich ist
ein Thread ein getrenntes Codeelement, das nur durch Verwenden eines ThreadProxys
mit anderen Threads kommunizieren kann, um eine Message (Meldung)
zu senden. Jeder Thread weist seine eigene Meldungswarteschlange auf,
von welcher er Meldungen ausliest (FIFO), während er dazwischen auch Timer-Ereignisse verarbeitet.
Wenn eine Message von einem Thread an einen anderen gesendet wird,
kann diese Message Daten als Parameter enthalten. Ein ThreadProxy
kümmert sich
um das Verpacken und Entpacken der Parameter. Wenn der Anrufer-Thread
Antwortwerte vom Angerufener-Thread braucht, werden die Daten in
einem OutputParameter (Ausgabeparameter) eingekapselt. Der ThreadProxy
wartet, bis dieser OutputParameter gefüllt ist, d.h. bis die Message
durch den Angerufener-Thread verarbeitet wurde. Auf diese Weise
kann ein synchroner Ruf zwischen Threads implementiert werden. Für verschiedene
Datentypen werden verschiedene OutputParameter-Klassen benötigt. Zurzeit
sind die folgenden definiert: StringArrayOutputParameter (Zeichenkettenanordnungs-Ausgabeparameter),
IntegerOutputParameter (Ganze-Zahl-Ausgabeparameter), PointerOutputParameter
(Zeigerausgabeparameter). Das Programm „TestThread" ist ein Beispiel
dafür,
wie Threads verwendet werden.
-
H245-CODEC
-
Der
H245-Codec ist zur Gänze
in C++ programmiert, d.h. es ist kein ASN.1-Parser oder dergleichen
daran beteiligt. Die gesamte Schnittstelle der H245-Codec-Software
ist in h245asn1.h, während
die Implementierung in verschiedenen cpp-Dateien ist. In diesem
Fall wurde die Regel gebrochen, dass jede Klasse ihre eigene .cpp-Datei
und ihre eigne .h-Datei haben sollte.
-
Das
Verpacken und Entpacken von Bits auf niedriger Ebene erfolgt in
der Klasse BitBufferManager (Bitpuffermanager). Darüber wird
die H245-Syntax als ein Field (Feld) angesehen, das Fields (Felder)
enthält.
Ein Field ist etwas, das codiert und decodiert werden kann. Diese
2 Funktionalitäten
sind in einem Verfahren: „endecode" („codecodieren"). Der Grund dafür ist, dass
die meisten Implementierungen zum Codieren und Decodieren identisch
sind (bestehend aus Rufen zum „Codecodieren" der Teilfelder).
-
Einige
grundlegende H245-Bausteine sind als Klassen implementiert:
LengthDeterminant
(Längendeterminante),
Extension (Erweiterung), SequenceExtension (Sequenzerweiterung),
ChoiceExtension (Wahlerweiterung), BooleanField (Boolesches Feld),
NumberField (Nummernfeld), ConstrainedInteger (Erzwungene ganze Zahl),
NormallySmallInteger (Normal kleine ganze Zahl), OctetString (Oktett-Zeichenkette),
GeneralString (Allgemeine Zeichenkette), IA5String (IA5-Zeichenkette),
OpenField (Offenes Feld).
-
Mit
diesen Bausteinen wurden Konstruktionen durchgeführt, die häufig auftreten:
ChoiceField
(Wahlfeld), ChoiceFieldWithoutExtension (Wahlfeld ohne Erweiterung),
ChoiceFieldWithExtension (Wahlfeld mit Erweiterung, ChoiceIndexField (Wahlindexfeld),
ChoiceIndexFieldWithExtension (Wahlindexfeld mit Erweiterung), SequenceFieldWithExtension
(Sequenzfeld mit Erweiterung), ArrayField (Anordnungsfeld).
-
Alle
anderen H245-Klassen werden durch Erben von diesen zuvor erwähnten Klasen
definiert. Die H245-Hauptmeldung ist eine MultimediaSystemControlMessage
(Multimediasystemsteuermeldung). Dies ist eine ChoiceFieldWithExtension,
wobei die Wahl eine der Folgenden ist: RequestMessage (Anforderungsmeldung),
ReponseMessage (Antwortmeldung), CommandMessage (Befehlsmeldung),
IndicationMessage (Anzeigemeldung). Diese Meldungen bestehen ihrerseits
aus Teilfeldern, die den H245-Standard wörtlich befolgen (und die Mobilerweiterungen,
die gebraucht werden). Die Implementierung all dieser H245-Meldungen
war ein ziemliches Stück
Tipparbeit. Um den Quellcode so klein und so einfach als möglich zu
halten, wurden einige C-Makros
definiert.
-
Manchmal
muss es möglich
sein, ein Field in ein anderes kopieren zu können. „Nur" für
jene Klassen, wo sie gebraucht wurden, wurden Operator=()-Verfahren
definiert.
-
H245
-
Die
Logik des H245-Protokolls wird unter Verwendung von Objekten H245,
H245User und Se*** (SeBlcl, SeBlcO, SeCel, SeCeO, SeClcl, SeClcO,
SeLcl, SeLcO, SeMll, SeMIO, SeMrl, SeMrO, SeMsd, SeMtl, SeMtO, SeRmel,
SeRmeO, SeRtd) simuliert. Diese Objekte senden einander Meldungen, aber
es sind eigentlich nur synchrone Funktionsprozeduraufrufe. Die H245User-
oder H245-Benutzer-Klasse
ist eine Schnittstellenklasse: die Implementierung ihrer Funktionen
ist in der „Session"- oder „Sitzungs"-Klasse.
-
Die
Se*** Klassen erben alle von einer generischen Klasse Se. Diese
Klasse hat Hilfsfunktionen zum Verfolgen und Codieren.
-
CAPI
-
CAPI
ist eine Standardbibliothek zum Adressieren von ISDN-Karten (http://.www.capi.org).
Die ANSI-C-Bibliothek ist für
Einpfadanwendungen auf eine große
Vielfalt von Plattformen mit sehr detaillierter Kontrolle über alle
Aspekte von ISDN bestimmt. Die CAPI-Klassen im H324M-Server sind eine
Einkapselung der CAPI-Bibilothek, um die ANSI-C-Bibliothek an eine
objektorientierte CCP-Umgebung mit Mehrpfadunterstützung anzupassen,
die mit der warteschlangenbasierten Mehrpfadarchitektur des H324-Servers zusammenpasst.
Die Bibliothek wurde entwickelt, um ISDN/CAPI von anderen möglichen Transportformen
(wie TCP, Modem, benannte Pipes, Gemeinsame Speicher) zu trennen.
-
Sitzungskommunikation
-
Zwei
Basisklassen sind der Kern einer einzelnen ISDN-Sitzung: ByteStream (Bytestrom) und ByteStreamListener
(Bytestromzuhörer).
Der ByteStream ist eine Schnittstelle, die das Senden von Daten
durch die ISDN-Verbindung
implementiert. Der ByteStreamListener muss durch den Empfänger von Daten
implementiert werden und wird verwendet, um den Empfang von neuen
Daten anzuzeigen und den Status der Pufferung für die Datensendung anzuzeigen.
-
Da
ISDN ein synchrones Kommunikationsmedium ist (kann bei Verwenden
der LAPB-Schicht innerhalb der CAPI-Bibliothek asynchron sein),
muss der Sendepuffer der ISDN Session stets gefüllt sein. Wenn der Sendepuffer
ungenügend
gefüllt
ist, stopft die ISDN-Schicht beliebige Bytes im Transport voll. Wenn
der Sendepuffer überfüllt ist,
löscht
die ISDN-Schicht die Daten. Eine Sitzung sollte auf den dataRequested()-
oder Daten-Angefordert()-Verfahren-Aufruf
auf ihrer ByteStreamListener-Schnittstelle durch
Antworten unter Verwendung genau eines Aufrufs sendData (Daten senden)
auf dem ByteStream Object antworten.
-
Die
ByteStream-Klasse ist eine Basisklasse, die erweitert werden kann,
die Capi-Version ist nur eine der möglichen Implementierungen.
Zurzeit gibt es die folgenden Implementierungen:
- 1)
CapiLogicalConnectionProxy
- 2) InternalByteStreamThread
- 3) TracingConnection
- 4) ReplayConnestion
-
Zu
1. CapiLogicalConnectionProxy (Capi-Logikverbindungs-Proxy) ist die normale
Implementierung in einem System, das ISDN verwendet.
-
Zu
2. InternalByteStreamThread (Interner Bytestrom-Thread). Auf einem System ohne ISDN
ist ein einfaches Testen durch internes Kommunizierenlassen des
Servers mit sich selbst möglich.
Das Verhalten sollte mit dem Server, der sich selbst anruft, identisch
sein.
-
Zu
3. TracingConnection (Verfolgungsverbindung). Zu Fehlerbeseitigungszwecken
speichert diese Klasse alle gesendeten und empfangenen Daten in
einer Datei, während
die Daten zu und von einem anderen ByteStream weitergegeben werden.
Dies ist mit dem „tee"-Befehl von Unix
vergleichbar, der das Protokollieren von Daten ermöglicht.
-
Zu
4. ReplayConnection (Wiedergabeverbindung). Zu Fehlerbeseitigungszwecken
liest diese Klasse die Datei, die durch eine racingConnection erzeugt
wurde, und imitiert das Verhalten der gespeicherten Sitzung.
-
Erzeugen einer Sitzung
-
Die
vorherige Sitzung, vorausgesetzt dass es eine bestimmte Art von
Session-Objekt gibt, das einer Sitzung entspricht, implementiert
die ByteStreamListener-Schnittstelle
und wird zu einem ByteStream unter Verwendung des registerListener()- oder
Zuhörer-Registrieren()-Verfahrens
registriert. Diese Aufgabe wird durch den ByteStreamController (Bytestromsteuerung)
und den ByteStreamConnectionListener (Bytestromverbindungszuhörer) implementiert.
Jede Form von Streaming-Transport implementiert normalerweise einen
SessionController (Sitzungssteuerung), der ByteStreams für jede logische Verbindung
mit einer anderen Session (Eine serverseitige Sitzung kommuniziert
mit einer clientseitigen Session) erzeugt und verwaltet.
-
Es
gibt normalerweise zwei Formen, Sitzungen zu erzeugen:
- 1) Ein Teilnehmer ruft den anderen an
- 2) Ein Teilnehmer empfängt
einen Anruf von einem anderen
-
Zu
1) Diese Funktion wird durch Aufrufen des makeConnection- oder Verbindung-Herstellen-Verfahrens
auf einem ByteStreamController ausgeführt. Der Controller erzeugt
den ByteStream, verknüpft
ihn mit der (physikalischen) Verbindung und informiert einen registrierten
ByteStreamConnectionListener über
die neue Verbindung.
-
Zu
2) Wenn der ByteStreamController intern ein Ereignis empfängt, dass
eine neue Verbindung angefordert wird (das Telefon läutet), bestätigt er, dass
ein ByteStreamConnectionListener registriert wurde, erzeugt einen
neuen ByteStream, der mit der neuen (physikalischen) Verbindung
verknüpft
wird, und informiert den ByteStreamConnectionListener über die
neue Verbindung.
-
Eine
Anwendung muss ein Objekt implementieren, das den ByteStreamConnectionListener
erweitert. Im H324-Server wird dies durch den SessionController
implementiert. Sein Proxy SessionControllerProxy wird im Basis-ByteStreamController
registriert.
-
Zurzeit
gibt es zwei Arten ByteStreamController:
- 1)
CapiController (Capi-Steuerung)
- 2) InternalByteStreamController (interne Bytestromsteuerung)
-
Zu
1. Dies ist die ISDN-Standardversion des ByteStreamControllers.
Er kann Rufe erzeugen und empfangen. Basisunterstützung für LowerLayerBearerCapabilities
(Trägereigenschaften
der unteren Schicht) ist gegeben: Es kann aus 4 vordefinierten BearerCapabilities
(Sprache (C), Binärdaten, HDLC-Rahmenbildung
(H), Binärdaten
mit H324M-Eigenschaften
(D)) durch Anhängen
des entsprechenden Buchstabens an die Telefonnummer gewählt werden.
Für H324
muss allen Telefonnummern ein D vorangehen.
-
Zu
2. Zu Fehlerbeseitigungszwecken werden zwei ByteStreams erzeugt,
die so verknüpft
werden, dass einer serverseitig und der andere clientseitig ist. Ein
Beispiel der Verwendung dieser Bibliothek ist in CapiTest.cpp und
CapiTest.h zu finden.
-
SITZUNGS-ETC
-
Zunächst dachte
man, man würde
mehrere Threads für
eine Verbindung brauchen. Später
stellte sich heraus, dass es genügte,
nur die folgenden Threads zu haben:
- – CAPI
- – Multiplexer
- – 1
bis 3 RV-Recorder
-
Mehr
getrennte Threads zu haben, bedeutet mehr Zusatzaufwand. Es stellte
sich heraus, dass der AV-Player in demselben Thread laufen kann
wie der Multiplexer, da das Auslesen von Daten aus einer Datei (unserer
gegenwärtigen
AV-Player-Implementierung) kein Engpass für die andere Funktionalität im Multiplexer-Thread
ist. Die Logik der Session-Klasse und der begleitenden Klassen ist
in der Datei SESSION.GIF (@@ tobedone) abgebildet.
-
Die
Klassen können
grob folgendermaßen eingeteilt
werden:
- – Multiplexer
(niedrigste Protokollschicht)
- – Anpassungsschicht
(höhere
Protokollschicht)
- – Sitzung
(höchste
Protokollschicht zur Steuerung; H245)
- – RV-Recorder
(höchste
Protokollschicht für
eingehendes Audio/Video)
- – AV-Player
(höchste
Protokollschicht für
abgehendes Audio/Video)
-
Multiplexer
-
- \SessionManager\Multiplexer.h(44):class ReceivingPdu \SessionManager\Multiplexer.h(112):class
Multiplexer: public ByteStreamListenerThread
-
Anpassungsschicht
-
Für jede Verbindung
gibt es eine Anordnung von abgehenden AdaptationLayerOut- oder Anpassungsschicht-Aus-Objekten
und eine Anordnung von eingehenden AdaptationLayerIn- oder Anpassungsschicht-Ein-Objekten;
eine für
jeden Kanal in Verwendung (bis zu einem Maximum von 6 Kanälen). Sowohl
AdaptationLayerIn als auch AdaptationLayerOut erben von einer generischen
AdaptationLayer-Klasse.
-
Für das abgehende
Protokoll wird stets ein Kanal 0 als der Steuerkanal definiert,
2 für Audio,
und 3 für
Video. Die Verwendung der AdaptationLayerIn-Objekte ist Sache der
Endgeräteseite.
Um einen Überblick über den
Code zu bewahren, wurden einige Unterklassen in der AdaptationLayerIn-Klasse
definiert:
AdaptationLayerIn1Administrtation,
AdaptationLayerIn2Administration,
AdaptationLayerIn3Administration.
Jede AdaptationLayerOut enthält
stets 3 Unterklassen, da ein Kanal seine Eigenschaften dynamisch ändern kann
(theoretisch kann ein Videokanal während einer Verbindung ein
Audiokanal werden). Diese Administration- oder Verwaltungsklassen
weisen Attribute auf, die für die
Adaptation-Schicht spezifisch ist, die in Verwendung ist. Jede AdaptationLayer
enthält
einen CyclicPacketPuffer (zyklischen Paketpuffer). Dies ist ein Thread-sicherer
zyklischer Puffer. Die Thread-sicheren Eigenschaften werden zurzeit
nicht verwendet (alle Pufferbearbeitungen finden in demselben Thread
statt). Außerdem
wird dieser CyclicPacketBuffer nicht für eingehende Audio/Video-Kanäle verwendet
(die Daten werden ohne Puffern direkt an die RV-Recorder weitergesendet).
Ein Objekt kann sich durch Erben vom CyclicPacketBufferListener
(Zuhörer
des zyklischen Paketpuffers) und Aufrufen von InitCPBufferListener()
(Zuhörer
des zyklischen Paketpuffers auslösen)
selbst an einen CyclicPacketBuffer anschließen. In diesem Fall wird die
Rückruffunktion
bufferNotEmpty() (Puffer nicht leer) aufgerufen, wenn etwas in den
CyclicPacketPuffer geschrieben wird.
-
In
unserer MMM-Anwendung wird dies nur auf der Empfangsseite verwendet:
Eine
Session schloss sich selbst an den Puffer der eingehenden Steuer-AdaptationLayer
(Nummer 0) an. Auf der abgehenden Seite leert der Multiplexer direkt
den Puffer nach dem Aufruf AVPlayer::play() (AVPlayer::spielen()),
der ihn füllen
sollte.
-
Sitzung
-
Das
Session-Objekt wurde für
mehrere Zwecke gemacht:
- – H245-Meldungen verarbeiten
- – eine
Verbindung in den Einhängezustand
versetzen (z.B. im Falle irgendeines Fehlers)
- – Steuerung
(erzeugen/löschen,
starten/stoppen) aller anderen Objekte.
-
Auf
einer späten
Stufe bei der Herstellung der Software wurde die Session zu einem
Teil des Multiplexer-Threads gemacht. Dies bedeutet, dass etwas
von der Steuerung in den Multiplexer-Thread verlegt wurde. Insbesondere
der Code für
das Reinemachen (Löschen
von Objekten usw.) ist nun ein bisschen durcheinander gekommen.
Um seine H245-Aufgaben
zu erledigen, enthält
ein Session-Objekt Verwaltungsobjekte: MsdAdministration, MtAdministration,
CeAdministration, LcAdministration, BlcAdministration, (die beiden
Letzteren werden von der CapabilitiesAdministration oder Eigenschaftsverwaltung
abgeleitet). Die Namen dieser Objekte beziehen sich klar auf das
H245-Protokoll (MSD, MT usw.). Sie sind alle in einem Quelldateipaar
definiert:
SessionAdministratios.h/SessionAdministrations.cpp.
-
RV-Recorder und AV-Player
-
Von
den RV-Recorder- und den AV-Player-Klassen werden Klassen abgeleitet,
welche spezifische Audio- und Videoprotokolle verarbeiten können. Zurzeit
gibt es die folgenden AV-Player:
- – SimpleAVPlayer:
liest einfach die Bytes aus einer Datei aus
-
Zurzeit
gibt es die folgenden RV-Recorder:
- – DebugAVRecorder:
speichert Bytes wörtlich
in eine Datei um
- – AVRecorderforAVI:
speichert Bytes derart in eine Datei um, dass die Datei durch einen AVI-Player
verwendet werden kann;
- – NamedPipeAVRecorder:
speichert Bytes in eine benannte Pipe um, so dass ein Echtzeit-Player das Video/Audio
auf dem (Vorführungs)
Bildschirm darstellen kann. Im H245-Protokoll muss die andere Seite über unsere
Player-Eigenschaften informiert werden. Diese Daten sind in der Klasse
AVPlayerCapabilities gespeichert. Für unsere spezifischen Player
wurden abgeleitete Klassen definiert: SimpleAVPlayerCapabilities
und AmrAndMpeg4AVPlayerCapabilities.
-
Hauptprogramm
-
Das
MMM-Hauptprogramm ist in der Datei ArenaMain.cpp. Diese Datei enthält auch
einige Definitionen kleiner Klassen, um die Quelle klarer zu machen:
IncomingSession (eingehende Sitzung), OutgoingSession (abgehende
Sitzung), SessionController (Sitzungssteuerung).