tina streams: service session control of multimedia streams
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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
Participant oriented (paramters are participant IDs)
• 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)
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
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
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)