200 likes | 348 Views
TINA streams: Service session control of multimedia streams. From the paper at TINA’97 conference: http://www.item.ntnu.no/~lillk/docs/TINA-97-lik-00660734.pdf
E N D
TINA streams:Service session control of multimedia streams From the paper at TINA’97 conference: http://www.item.ntnu.no/~lillk/docs/TINA-97-lik-00660734.pdf L. Kristiansen , Service Session Control for multimedia services -informational and computational views, in Global Convergence of Telecommunications and Distributed Object Computing, pp288-296, Proceedings.,TINA97 1998, ISBN: 0-8186-8335-X
High level (participant oriented) • Participant oriented SBSR: This is the high level approach; stream bindings are described in terms of participating session members, type and QoS. • Thus this may be seen as the multi-party-to-multi-party concept, with focus on the parties (or participants)and less focus on the individual end points (SFEPs).
Finer level of control • Flow oriented SBSR approach to stream bindings uses stream flow connections (SFCs) to specify the stream binding. • In this case, a stream binding may be considered an aggregation of SFCs and the session members participate indirectly by exporting their SI information before any request to establish a stream binding is made.
2 feature sets (FSs) at comp- level • Partcipant oriented Stream binding FS • Pa-SBSR-FS • Flow oriented Stream Binding FS • Flow-SBSR-FS • In addition comes feature sets for multiparty, control relationships etc • This allows ’simple endusers’ not to deal with all advanced features • details to be found in TINA SA chap. 7
void addPaSBFSreq( in t_ParticipantsSecretId myId, in t_SBType reqType, in t_MediaDescList media, in t_ParticipantDescList reqMembers, in t_SFEPDescList requesterSIs; in t_SBSuccessCriteria criteria, out t_SBBindState status) void joinPaSBFSexe( in t_SessionId sessionId, in t_SBSRId sbId, in t_SBType reqType, in t_MediaDescList media, in t_ParticipantIdList others, in t_ReqParticipantDesc reqParticipation, in t_RequestId reqId, out t_SFEPDescList participantSIs) Participant oriented (paramters are participant IDs)
Flow oriented (paramterers are SI and SFEndPoints) • void addSFlowSBFSReq( • in t_ParticipantsSecretId myId, • in t_SBType reqType, • in t_SBTopology reqTop, • in t_AdministrativeState reqState; • in t_SFlowDescList flows, • in t_SBSuccessCriteria criteria, • in t_SBRecover recActions, • in t_ParticpantIdList owners, • out t_SBBindState status)
Comparision • In the high level view there are less operations needed to establish the actual stream flows • The SSM does the necesarry mapping from participant to all relevant streams • The initiator just give some high level ’media descriptor’ • Many IO will be created by one CO operation
Comparision continued • No detailed control of individual flows are possible in high level view • In low level view all SI, SFEP and SFC must be explicitly created • Each IO to be created needs one separate computational operation
Combinations • The SSM (central service logic) may offer both feature sets: • high level PA-SBSR feature set • low level Flow-SBSR feature set • Some parties have no need to see all details, e.g. a conference bridge or a transcoder may be sees by the conference controller, but not by an ordinary user • Control SBSR feature set may similarily be offered only to some parties
Example: tele-education • One deaf student has a need for a spesial resouce to do a voice-to-sign-language convertion • This spesial resource may be: • visible to the SSM (core logic), who controls it via detailed stream flow control • Visible to the deaf student, as a resource, but nwithout detailed flow control • Not visible to the other students • All students sees there own stream flows
Comp. view figure: • This may also be drawn as an instance of an information model
View from the deaf student (UAP-S): • UAP-S sees the interpreter as party -sees his own SI and SF EndPoint (only)
Go back to figure 7 • We have many normal students, each will see 1 stream binding between 2 parties • between themself and the AV-source • 1 SBSR-instance with 2 SFConnections • They see: • their own SF-Endpoint, and the source (but not the other sinks of this multicast flow) • If participant oriented: • they need not see the SCF and the SI of the AV-source
View from the ’normal’ students (UAP-N) if they see stream flows
View from AUP-Nif they see participants only(The SSM core logic still see all details)
Further issues: • for big conferences, several federated SSMs may be involved • May not be one single place knowing the total conference configuration • For ’multicast’ flows: may be relevant to know only the ID of the flow, not all the (other) endpoints of the flow
Final note: • This paper was written in 1997 • Since then VoIP, and Internet multicast has become more dominant • Today most people foresee that session initiation will be handled by SIP (session Init. protocol) by IETF/ 3GPP(IMS) • Multicast is still for further study (mostly)
View of applications and services http://www.ericsson.com/about/publications/review/2002_03/files/2002032.pdf