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

The session graph concept (IM)

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

Comp. view figure:

• This may also be drawn as an instance of an information model

IM instance 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/200203

2.pdf