tina streams service session control of multimedia streams n.
Skip this Video
Loading SlideShow in 5 Seconds..
TINA streams: Service session control of multimedia streams PowerPoint Presentation
Download Presentation
TINA streams: Service session control of multimedia streams

TINA streams: Service session control of multimedia streams

140 Vues Download Presentation
Télécharger la présentation

TINA streams: Service session control of multimedia streams

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. TINA streams:Service session control of multimedia streams From the paper at TINA’97 conference: 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

  2. The session graph concept (IM)

  3. 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).

  4. 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.

  5. 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

  6. 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)

  7. 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)

  8. 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

  9. 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

  10. 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

  11. 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

  12. Comp. view figure: • This may also be drawn as an instance of an information model

  13. IM instance model

  14. View from the deaf student (UAP-S): • UAP-S sees the interpreter as party -sees his own SI and SF EndPoint (only)

  15. 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

  16. View from the ’normal’ students (UAP-N) if they see stream flows

  17. View from AUP-Nif they see participants only(The SSM core logic still see all details)

  18. 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

  19. 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)

  20. View of applications and services