1 / 20

TINA streams: Service session control of multimedia streams

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

thetis
Download Presentation

TINA streams: Service session control of multimedia streams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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 http://www.ericsson.com/about/publications/review/2002_03/files/2002032.pdf

More Related