1 / 12

SIP Conferencing

SIP Conferencing. Henning Schulzrinne Columbia University IETF SIP Interim Meeting, Feb. 2001. Overview. Conference models Issues: Membership awareness Transitioning between models Conference identification Full-mesh conferences. SIP Conference Modes. Central mixer End system mixing

jdelmonte
Télécharger la présentation

SIP Conferencing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • 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

  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)

More Related