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

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

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

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

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

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

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

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

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

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

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

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