1 / 10

SIP Conferencing Requirements

SIP Conferencing Requirements. Henning Schulzrinne Petri Koskelainen Columbia University. General philosophy. SIP philosophy: strictly separate media and session signaling thus, media control (e.g., retransmission requests) out of scope thus, encoding profiles out of scope

seda
Télécharger la présentation

SIP Conferencing Requirements

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 Requirements Henning Schulzrinne Petri Koskelainen Columbia University SIP/SIPPING Interim Meeting

  2. General philosophy • SIP philosophy: strictly separate media and session signaling • thus, media control (e.g., retransmission requests) out of scope • thus, encoding profiles out of scope • orthogonal  apply also to other conference types • Support central-controller conferences: • central mixing or selection/replication or end-system mix • possibly different addresses for different media sessions • media session(s) identified by single SIP URI • SSM: sources send to controller = root of multicast tree • Allow re-use of SIMPLE approaches • subscription permission  conference join permission • buddy list  pre-stored participant list SIP/SIPPING Interim Meeting

  3. Don't invent new pieces (unless we have to) • Tease out conferencing-specific needs • modular, no H.323-like vertical stack • avoid conferencing-specific profiles • no T.120 special case (except through gateways) • No need to define requirements for things that we already have: • conference creation (but may need termination) • conference joining and leaving • participant muting • renegotiation of leg codecs SIP/SIPPING Interim Meeting

  4. No meta application • Believe that meta-app model is misguided  seems to call for another signaling protocol, identifier, etc. • if no protocol or identifier, invisible • don't want uninstantiated relationships • we can set up sessions (including T.120...) via SIP SIP/SIPPING Interim Meeting

  5. General model • Divide into requests and notifications • requests = do something • notification = something happened • Requests may trigger notifications if action may be delayed or partial • human approval • group invite SIP/SIPPING Interim Meeting

  6. Motherhood and Apple Pie • Simplicity • bandwidth-frugal (mobile) • incremental notifications and command • selectable notification granularity • templates for privileges SIP/SIPPING Interim Meeting

  7. Components • Identified by object manipulated: • conferences  conference management • participants within conferences  user management • shared resource  floor control SIP/SIPPING Interim Meeting

  8. Conference management • Create conference [?] • Delete conference • name vs. resources • Conference properties: • description (subject) • visibility to searching and directories • policies? SIP/SIPPING Interim Meeting

  9. User management • Cause server to invite user(s) • Expel users • List of pre-approved attendees • User rights • invite, expel, approve others • manage & request floor • add media sessions • Join notification • with thresholding • Obtain list of members SIP/SIPPING Interim Meeting

  10. Open issues • Separate conference name existence from resource allocation • want to keep name, but not mixing and bandwidth resources • Template management: • user lists • privilege levels ("chair", "secretary", "panelist", "audience") SIP/SIPPING Interim Meeting

More Related