Download Report

Membership and Media Management in
Centralized Multimedia Conferences based on
Internet Engineering Task Force Protocol
Building Blocks
Author: Ritu Mittal
Supervisor: Prof. Jörg Ott
Instructor: Gonzalo Camarillo
Oy LM Ericsson AB Finland
14 Augus t, 2007
Networking Laboratory
1
Contents
Objectives
Introduction
Conferencing frameworks
Conference control protocol
Conference control protocol proposals over IETF
Conference control protocol proposal in this
thesis
• Prototype implementation
• conclusion
•
•
•
•
•
•
14 Augus t, 2007
Networking Laboratory
2
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.
14 Augus t, 2007
Networking Laboratory
3
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.
14 Augus t, 2007
Networking Laboratory
4
Conferencing Models
Fully-distributed
tightly-coupled
Loosely-coupled
14 Augus t, 2007
Networking Laboratory
5
Conferencing Frameworks (1)
• There are two conferencing frameworks defined by IETF
• The frameworks defines the logical entities and terminology
used for conferencing
1.
2.
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
•
14 Augus t, 2007
Networking Laboratory
6
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:
[email protected]
– 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.
14 Augus t, 2007
Networking Laboratory
7
Conferencing Frameworks (3)
• General arrangement of different entities for a conference call
14 Augus t, 2007
Networking Laboratory
8
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
14 Augus t, 2007
Networking Laboratory
9
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.
14 Augus t, 2007
Networking Laboratory
10
Conference Control Protocol (2)
14 Augus t, 2007
Networking Laboratory
11
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
14 Augus t, 2007
Networking Laboratory
12
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
14 Augus t, 2007
•
•
•
•
•
a client sends pre-defined or
dedicated primitives, e.g. <adduser>,
<modifymedia>,
<increaseConferenceVolume> 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
Networking Laboratory
13
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: confEntity=sip:[email protected] identifies directly a particular
conference
14 Augus t, 2007
Networking Laboratory
14
Conference control protoocol Proposal
in this thesis(2)
• CCOMP Operation=CREATE
14 Augus t, 2007
Networking Laboratory
15
Prototype Implementation
Practical part
•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.
14 Augus t, 2007
Networking Laboratory
16
Session setup
Example SIP Message:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.2:5064
From: sipp <sip:[email protected]:5064>;tag=1
To: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected]:5064
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 134
v=0
o=user1 53655765 2353687637 IN IP4 127.0.0.1
s=c=IN IP4 131.160.36.20
t=0 0
m=audio 30105 RTP/AVP 0
a=rtpmap:0 PCMU/8000
14 Augus t, 2007
Networking Laboratory
17
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
14 Augus t, 2007
Networking Laboratory
18