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

2. Overview Conference models Issues: Full-mesh conferences
Membership awareness
Transitioning between models
Conference identification
Full-mesh conferences
5/17/2019

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?
5/17/2019

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/17/2019

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
5/17/2019

6. Conference Identification
We have two identifiers: SIP call-ID and (SDP) conference ID
Doesn’t 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
5/17/2019

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?
5/17/2019

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(?)
5/17/2019

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
5/17/2019

10. Simultaneous Joins A B C D B A B B,C A,B A,B INVITE or INVITE + REFER
5/17/2019

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
5/17/2019

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)
5/17/2019