Transcript CLUE and RTCWEB

CLUE WG
RTCWEB & SDP/RTP building blocks
Andover, MA
Oct. 11-12th, 2011
Mary Barnes
Overview
• Both RTCWEB and CLUE involve controlling
multiple RTP audio and video streams:
•CLUE is focused on such.
•It’s just one usage for RTCWEB.
• CLUE must interoperate with SIP and other
standards for audio & video.
• RTCWEB may not necessarily interoperate with
“legacy” SIP endpoints (e.g., a CLUE endpoint)
but:
•Will use RTP for media: draft-ietf-rtcweb-rtp-usage-00
•Likely will use SDP
RTCWEB Signaling Protocols
Web Server
HTTP – Already standardized
Beyond that – several possibilities
Browser
Browser
Media Transport – In scope for IETF – DTLS-SRTP + ICE?
RTCWEB Inter-domain Signaling
Web Server
Web Server
Signaling federation –
Could be in scope for IETF –
SIP + SDP O/A?
Browser
Browser
RTCWEB Media Negotiation
Proposed Design Principles (under discussion):
The media negotiations will be done using the same SDP
offer/answer semantics that are used in SIP.
2.It will be possible to gateway between legacy SIP devices that
support ICE and appropriate RTP / SDP mechanisms and
codecs without using a media gateway. A signaling gateway
to convert between the signaling on the web side to the SIP
signaling may be needed.
3.When a new codec is specified, the JS API specification does
not need to be changed or extended. As soon as the browsers
support the new codec, old applications written before the
codecs was specified should automatically be able to use the
new codec, where appropriate, with no changes to the JS
applications.
1.
Group still needs discussion of O/A model versus an advertisement model.
Proposal
• Ensure that SDP usage is compatible and consistent to
ensure that CLUE and RTCWEB do not define two separate
ways of doing the same thing.
• CLUE should start evaluating usages of SDP/RTP as
framework is being developed.
• CLUE needs to carefully consider RTCWEB decisions in
terms of handling the multi-streams:
a. Multiplex over a single RTP session or
b. Multiple RTP sessions