Membership and Media Management in Centralized Multimedia Conferences based on Internet Engineering Task Force Protocol Building Blocks Author: Ritu Mittal Supervisor: Prof. J

1
Membership and Media Management in
Centralized Multimedia Conferences based on
Internet Engineering Task Force Protocol Building
BlocksAuthor Ritu MittalSupervisor Prof.
Jörg OttInstructor Gonzalo CamarilloOy LM
Ericsson AB Finland
2
Contents

• Objectives
• Introduction
• Conferencing frameworks
• Conference control protocol
• Conference control protocol proposals over IETF
• Conference control protocol proposal in this
  thesis
• Prototype implementation
• conclusion

3
Objective

• Theoretical Part of this thesis
• Analysis of different Conference Control Protocol
  proposals over Internet Engineering Task Force
  (IETF) Centralized Conferencing (XCON) Working
  Group.
• Proposing a conference control mechanism
• Practical part of this thesis
• Implementation of the Conference Server using
  Session Initiation Protocol (SIP) on the existing
  Session Border Gateway (SBC) for establishing
  signaling connection between the conference
  clients and the server itself.

4
Introduction

• Session Initiation Protocol (SIP) is the most
  widely used telephony standard
• Multimedia conferencing using SIP is becoming
  popular
• But offering conference control services which
  means that managing members and their media in a
  conference session is out of the scope of SIP.
• There are some non-SIP Conference control
  protocol Proposals over IETF XCON WG for the
  conference control.

5
Conferencing Models

• Fully-distributed tightly-coupled
• Loosely-coupled

6
Conferencing Frameworks (1)

• There are two conferencing frameworks defined by
  IETF
• The frameworks defines the logical entities and
  terminology used for conferencing
• The SIPPING Conferencing framework
• The XCON Conferencing framework
• SIPPING uses SIP as the signaling protocol
• XCON framework is independent of the signaling
  protocol used e.g. Can use H.323 , SIP or PSTN
• the XCON framework is compatible with SIPPING
  framework

7
Conferencing Frameworks (2)

• The central component in the conferencing
  framework is a conference server called focus
• A participant contact to the Focus by using a
  unique Conference URI e.g. Sip
  myconference_at_sip.com
• It maintains a signaling relationship with each
  conference participant
• Responsible for media streams in the session
• Responsible for conference policies,
  notifications about the state changes in a
  conference
• It contains common conference information about
  signaling, members, media streams etc. known as
  conference object
• Common conference Information is represented by
  data elements and their attributes known as
  components
• Only the authorized participants can access and
  manipulate those components
• Needs a non-SIP conference control protocol to
  access and manipulate it.

8
Conferencing Frameworks (3)

• General arrangement of different entities for a
  conference call

9
Conferencing Frameworks (4)

• Conference policy A complete set of rules for a
  particular conference, includes
• Membership Policy (rules about participation in a
  conference)
• Media Policy (multiple media types e.g.
  Audio,video etc.)
• An participant becomes authorized if conference
  policy allows him to make the changes in the
  common conference information
• Conference policy is an integral pat of the
  conference object

10
Conference Control Protocol (CCP)

• It defines an interface between the conferencing
  client and the conference server to access and
  manipulate common conference information.
• Provides overall control over the members and
  media of a conference
• For example add, delete and modify members and
  their media in a conference
• Performs advaced conference control services e.g.
  Mute a noisy participant, change the size of
  video display, increase/decrease the volume of
  the conference session etc.

11
Conference Control Protocol (2)
12
Conference control Protocol Proposals over IETF
XCON (1)

• Conference policy control protocol (CPCP)
• Conference state change protocol (CSCP)
• Centralized Conference Manipulation Protocol
  (CCMP)
• Centralized Conference Control Protcol (CCCP)
• Every protocol has its own way to access and
  modify (manipulate) the common conference
  information represented by conference object.
• We analyse them on the basis of their syntactic
  vs. Semantic properties.
• CPCP and CSCP uses syntactic approach
• CCMP and CCCP used semantic approach

13
Semantic Vs. Syntactic Approach

• Syntactic

• Semantic

• A client performs add/delete/modify operations on
  the elements and their attributes of conference
  information.
• The client should have an complete understanding
  of the format used by the server to store the
  information.
• Modifying too many separated elements at the same
  time needs more network resources e.g. Bandwidth
• Scope is wide and can be used for multiple
  applications.
• a client have to define the whole path to modify
  the small information

• a client sends pre-defined or dedicated
  primitives, e.g. ltaddusergt, ltmodifymediagt,
  ltincreaseConferenceVolumegt etc.
• The server can store the conference information
  in any format.
• The confernce server should support all the
  primitves used by the client
• Scope is limited to only one application
• A client can extend or define new primitives even
  to modify small information

14
Conference control protoocol Proposal in this
thesis(1)

• We proposed a Centralized Conference Object
  Manipulation Protocol (CCOMP)
• It is not a new protocol
• Have features of CCMP and CCCP
• Uses conference control operations in the request
• E.g. OPTIONS, GET, CREATE, MODIFY, DELETE
• Conveys to the server about the operation a
  client wants to perform.
• Based on their semantic properties
• Used pre-defined and dedicated primitives
• Primtives can be extended
• Client-server model
• Client send a request towards the server
• Server responds with the response code of
  Success or Failure
• this maintains transparency bewteen them
• Independent of underlying transport protocol
• e.g can use HTTP or SOAP
• Uses multiple primitives inside a single request
• Saves network bandwidth
• Conferencekeys confEntitysipconf123_at_sip.com
  identifies directly a particular conference

15
Conference control protoocol Proposal in this
thesis(2)

• CCOMP OperationCREATE

16
Practical part

• Prototype Implementation

• The objective of the practical part is to
  implement the conference server (foucs)
  functionality on an existing Session Border
  Controller.
• SBC is used to manage signaling and media streams
  in a Voice-over-IP network.
• It supports small-scale multimedia conference
  calls.

17
Session setup

• Example SIP Message
• INVITE sipconference_at_131.160.36.205060 SIP/2.0
• Via SIP/2.0/UDP 127.0.0.25064
• From sipp ltsipsipp_at_127.0.0.25064gttag1
• To ltsipconference_at_131.160.36.205060gt
• Call-ID 1-11355_at_127.0.0.2
• CSeq 1 INVITE
• Contact sipsipp_at_127.0.0.25064
• Max-Forwards 70
• Subject Performance Test
• Content-Type application/sdp
• Content-Length 134
•  
• v0
• ouser1 53655765 2353687637 IN IP4 127.0.0.1
• s-
• cIN IP4 131.160.36.20
• t0 0

18
Conclusion

• Theoreical part
• Analysis of various conference control protocol
  proposals over IETF XCON WG.
• Proposed semantic-based CCOMP, combination of two
  of existing protocol proposals i.e. CCMP and
  CCCP.
• Practical Part
• The implemenation of SIP Conference server over
  existing SBC is successfully implemented.
• Future Work
• Interface between the conference server and media
  server which is known as media control protocol
• Implementing conference control fuctionality into
  SBC
• One CCP for the interface between the client and
  conference server, and between the conference
  server and the media server