SIP Conferencing

1
SIP Conferencing

• Henning Schulzrinne
• Columbia University
• IETF SIP Interim Meeting, Feb. 2001

2
Overview

• Conference models
• Issues
• Membership awareness
• Transitioning between models
• Conference identification
• Full-mesh conferences

3
SIP Conference Modes

• Central mixer
• End system mixing
• Similar to central, but participant is mixer
• IP multicast for media
• Full mesh signaling
• Full-mesh media distribution
• Multicast media?

4
Membership Notification

• RTCP SDES
• works well for multicast
• Can be suppressed by participant in stealth
  mode
• SIP SUBSCRIBE/NOTIFY
• Works well for central server
• Not needed for mesh

5
Transition between Conference Models

• Need to be able to move participants from
  central/UA mixer to multicast or from mesh to
  mixer or multicast
• Similar to (supervised?) call transfer

6
Conference Identification

• We have two identifiers SIP call-ID and (SDP)
  conference ID
• Doesnt matter for (UA) mixer or multicast, as
  only mixer needs to know that call-legs are
  related
• Can use conference URL as identifier for
  notifications

7
Conference Identification

• Call-out only current participants can add new
  ones
• For call-out, all conference participants can
  have same IDs
• If call-in allowed, neither Call-ID nor SDP
  session id can identify conference
• Does call-in make sense for mesh?

8
Full-Mesh Conferencing

• Establish via
• INVITE with membership list, or
• REFER with Refer-To list of members
• Rule Both UAC and UAS send membership list in
  request and 200
• Send INVITE to all new, recurse
• Allow joining of separated clouds(?)

9
Full-Mesh Conferencing Cases

• Simultaneous out-calls to two parties
• Departures and re-joins
• Departures while other party joins
• Liveness detection of mesh?
• Single user participating in multiple
  simultaneous conferences

10
Simultaneous Joins
A
B
C
D
B
A
B
B,C
A,B
A,B
INVITE or INVITE REFER
11
Deleting Members

• Member leaving group send BYE to everyone
• May still be contacted by a new arrival that just
  joins before the BYE arrives just refuse
  invitation
• Propagate member only once INVITE succeeded

12
REFER vs. INVITE

• REFER is in line with general architecture, but
  more messages
• Use Refer-To with multiple addresses?
• However, here Refer-To entries need to be skipped
  if already contacted contradicts normal
  behavior needed for re-INVITE request
• Could use SDP session ID, but meaning unclear for
  call-in (check unicast definition for both sides)