One document matched: draft-jennings-rtcweb-api-00.txt
Network Working Group C. Jennings
Internet-Draft Cisco
Intended status: Standards Track March 7, 2011
Expires: September 8, 2011
Architecture and API Requirements for RTC Web
draft-jennings-rtcweb-api-00
Abstract
Internet browsers and other software applications are enabling
support for real time interactive voice and video. This draft
outlines a set of IETF protocols that can be used for this purpose
and describes the overall architecture. It also identifies the
requirements for an application programming interface to control
these protocols.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Jennings Expires September 8, 2011 [Page 1]
Internet-Draft RTC Web API Requirements March 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Advertisement Proposal Model . . . . . . . . . . . . . . . 3
1.2. Offer Answer Model . . . . . . . . . . . . . . . . . . . . 5
1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Facebook . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Webex . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3. Amazon . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Connection API . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Session API . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Session Example Incoming . . . . . . . . . . . . . . . 11
4.1.2. Session Example Outgoing . . . . . . . . . . . . . . . 11
4.2. Connection API . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Audio Video API . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Attack Model . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Media Security . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Signaling Security . . . . . . . . . . . . . . . . . . . . 20
7. Legacy VoIP Interoperability . . . . . . . . . . . . . . . . . 20
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Jennings Expires September 8, 2011 [Page 2]
Internet-Draft RTC Web API Requirements March 2011
1. Overview
This draft describes two models of how this would work, which are
referred to as the advertisement proposal (AdProp) model and the
offer answer (OffAns) model. Both of these models are useful in
various situations, and they involve very similar code development
efforts. This draft proposes an API and protocol set standardization
that supports both models.
1.1. Advertisement Proposal Model
The AdProp model standardizes a way to send media between two
browsers and standardizes an API in the browser, such that browser-
based applications can find out the media capabilities of the browser
and can tell the browser what media streams to send and receive. We
use the term "browser app" to refer to a program that is running in
the browser and using HTML, CSS, and JavaScript to control the
browser. It is assumed that the browser app could communicate with
the web server using existing approaches, and that the web server
communicates with a SIP server as a way of federating to other
websites or connecting to legacy VoIP systems. There are many
different ways this model could be used, but the diagram below covers
a fairly complex case that most other cases end up being a subset of.
More use cases are discussed in section XXX.
Jennings Expires September 8, 2011 [Page 3]
Internet-Draft RTC Web API Requirements March 2011
+-----------+ +-----------+
| Web/ | | Web/ |
| SIP | SIP | SIP |
| |-------------| |
| Server | | Server |
| | | |
+-----------+ +-----------+
/ \
/ \ Proprietary over
/ \ HTTP/Websockets
/ \
/ Proprietary over \
/ HTTP/Websockets \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
Add ^ |Prop Add ^ | Prop
| v | v
+-----------+ +-----------+
| | | |
| | | |
| Browser | ------------------------- | Browser |
| | ICE + SRTP | |
| | | |
+-----------+ +-----------+
The API for this model has two distinct phases. First there is a
Connection API that allows the browser app to use ICE to form a
connection to the other browsers. This API assumes that the browser
applications will be able to exchange ICE candidates lists by some
out-of-band means -- most likely involving passing them up to the web
servers over HTTP. The second stage is referred to as the AVT API.
This API allows the browser apps to discover which codecs and
capabilities the browser supports. It then allows the browser app to
control which media streams the browser will send and receive. The
browser describes its range of capabilities in an advertisement
object. The browser app requests that a particular set of media
streams be set up in a proposal to the browser. This is done as an
atomic request which is either accepted or not. Partial acceptance
has proven to be very difficult to deal with in the implementation of
existing systems. The general overview and advantage of the AdProp
model is discussed in draft-peterson-sipcore-advprop
[I-D.peterson-sipcore-advprop].
The model above shows SIP as the protocol between the two web
servers, but the API proposed would also work using Jingle or H.323
as the federation signaling protocol. It would also be possible to
Jennings Expires September 8, 2011 [Page 4]
Internet-Draft RTC Web API Requirements March 2011
implement the processing of SIP messages in the JavaScript in the
browser application and then somehow tunnel the SIP messaging between
the clients. XMPP over websockets has been proposed for this. The
architecture and API in this draft would support all of these
possibilities.
1.2. Offer Answer Model
The OffAns model standardizes a way to send media between the
browsers, but it also selects an existing signaling protocol to
negotiate and set up the media. The browser app would indicate to
the browser that it wished to form a communication session with
another entity, and then the browser would take care of the rest. A
typical model for this is show below.
+------+ +------+ +------+ +------+
| Web | | SIP | SIP | SIP | | Web |
| Serv | | Serv |---------| Serv | | Serv |
+------+ +------+ +------+ +------+
| / \ |
|HTTP / SIP \ | HTTP
| / \ |
| /SIP \ |
| / \ |
| / \ |
| / \ |
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ +-----------+
| | | |
| | | |
| Browser |---------------------| Browser |
| | ICE + SRTP | |
| | | |
+-----------+ +-----------+
The major goal for this API is to be extremely simple to use in
enabling a website for voice and video. On an iPhone today, one can
simply put a tel URL on the web page and the iPhone can call it.
That is a simple approach that web developers like and use. Since
standards are involved, this proposal will have to be more complex.
The API defines an HTML session element that can be used like a
source element inside of an audio or video element. It also provides
a JavaScript API to control the session and replace the user
interface.
Jennings Expires September 8, 2011 [Page 5]
Internet-Draft RTC Web API Requirements March 2011
1.3. Use Cases
1.3.1. Facebook
Consider the case of a social networking site that allows IM between
users and wants to also allow voice and video between them, but does
not need to federate with others. The case could easily use the
AdProp model. Assuming that it was only supported on browsers
meeting a certain minimum functionality and it always uses the same
capabilities, there is no need to even negotiate or share the
advertisements between the two browsers. The browser app simply sets
up the connection to the far end, and then uses a proposal for the
media steam that is always the same.
+-----------+
| Web |
| |
| |
| Server |
| |
+-----------+
/ \
/ \ Proprietary over
/ \ HTTP/Websockets
/ \
/ \
/ \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
Add ^ |Prop Add ^ | Prop
| v | v
+-----------+ +-----------+
| | | |
| | | |
| Browser |----------| Browser |
| | ICE+RTP | |
| | | |
+-----------+ +-----------+
1.3.2. Webex
TBD
Jennings Expires September 8, 2011 [Page 6]
Internet-Draft RTC Web API Requirements March 2011
1.3.3. Amazon
Consider the case of a website that supports searching and displays
advertisements related to the search. In this case clicking on the
advertisement could directly connect the user with a sales agent at
the company associated with the advertisement.
+------+ +------+
| Web | | SIP |
| Serv | | Serv |
+------+ +------+
| / |
|HTTP / |
| / |
| /SIP |
| / |
| / |
| / | SIP
+-----------+ |
|JS/HTML/CSS| |
+-----------+ |
+-----------+ |
| | +-------+
| | | Video |
| Browser |----------| Phone |
| | ICE+SRTP | |
| | +-------+
+-----------+
In this sort of case the people operating the web server do not need
to deploy anything special to display the advertisement, and the
company associated with the advertisement can use its existing call
center, assuming it meets the legacy VoIP requirements outlined in
section XXX.
The security issue of a browser sending a SIP packet to a device that
does not meet the same origin policy is discussed in the section XXX,
but the brief preview of the solution is that the SIP messages can
use CORS REF much like a HTTP does.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Jennings Expires September 8, 2011 [Page 7]
Internet-Draft RTC Web API Requirements March 2011
3. Requirements
The section defines the set of protocols and selected subset profiles
of these protocols that a browser would need to implement, and forms
the requirements for the API to control these protocols. At a high
level we split this into connection management, transports for real
time media such as audio and video, transports for non media data,
codecs support, and signaling protocols.
All of the data plane sessions are set up using ICE [REF] or ICE-Lite
for security reasons, discussed in section XXX. Devices that could
be deployed behind NATs, such as a web browser, are REQUIRED to
support ICE while other devices that always deploy on public
addresses can do ICE-Lite. The only mode of ICE REQUIRED is
aggressive. Real time media is transported over RTP REF or SRTP
[REF]. Support for multicast RTP is OPTIONAL. To support ICE,
implementation needs to be able to do STUN REF and TURN REF. In
addition, there is a strong interest to define a TURN-like protocol
that looks like HTTP to intermediaries, so that media can be tunneled
over HTTP. Support RTCPMUX REF is REQUIRED. RTP keep alive is done
using RTCP as described in REF. The API needs to allow the DSCP REF
for each RTP or media stream to be set. The API needs to allow the
browser app to observer and control the SSRC values in the RTP.
Open Issue: There is a desire to be able to pass non media type data
directly between browsers. For example, an application such as
Second Life or gaming application may wish to pass small chunks of
data such as player position with stringent real time requirements.
There are several proposals for how to do this. The session would be
set up using ICE, just as with RTP. One proposal is just to use a
thin shim on top of UDP or DTLS to demux the packets from other
packets such as RTP on the same connection. Another proposal is DTLS
over DCCP over UDP with some appropriate congestion control scheme
chosen for DCCP. Another proposal is to define a data codec to carry
the data in RTP.
The mandatory to implement audio codecs are: PCMA, PCMU, telephone-
event, and opus [REF]. The API needs to support the following
OPTIONAL codecs: G729, G722, G7221, G723, AMR, AMR-WB, iLBC, L16 and
opus. PCMU and PMCA codecs are REQUIRED to support 1 channel with a
rate of 8000 and a ptime of 20. The mandatory to implement video
codecs are: <to be chosen by working group - leading candidates for
consideration are H.264-AVC and VP8>. The minimum profile and
resolutions supported by the mandatory to implement video codecs are
TBD. The API needs to support the following OPTIONAL codecs: H263-
2000, H264, H264-SVC, raw and VP8.
The signaling protocol selected here is SIP though very little
Jennings Expires September 8, 2011 [Page 8]
Internet-Draft RTC Web API Requirements March 2011
overall architecture would change if the WG decided to use Jingle REF
instead of SIP. The browser needs to implement the subset of SIP
REF3261,3263,3264 and is required to support registration, invite,
ack, cancel, bye, and update. Support for the following features is
OPTIONAL: INVITES without an offer, re-invite, forking, S/MIME and
sips. Support for the following is REQUIRED: sip over TLS, outbound
proxy, 3xx redirects, early media, multipart mine REF 5621, update,
identity 4916 & 4471, rport REF 3581, SIP keep alive as described in
5626.
Open Issue: define a TURN like protocol to tunnel RTP over HTTP
Open Issues: define a RTP mux protocol to multiplex RTP on top of a
single UDP port. Would likely use SSRC as the demux code point.
Open Issue: Mandatory to implement video codec(s) and minimum
profile.
Open Issue: Mandatory to implement audio codecs.
4. Connection API
It is expected this section will be removed from this draft and moved
to a W3C draft but it is provided for reference at this point. The
straw man API are many things including adequate error handling. The
API would likely end up using exceptions for many things.
4.1. Session API
The session element can be used anywhere in HTML that the source
element could be used. Fundamentally, this is an alternative way of
setting up a source for an audio or video element.
Categories: None
Contexts in which this element can be used: same as source element
Content model: Empty
Content attributes:
src: URL to destination to create session with.
Jennings Expires September 8, 2011 [Page 9]
Internet-Draft RTC Web API Requirements March 2011
aor: Address of Record that identifies this user.
credential: Password or credential for the specified AOR.
proxy: URL for outbound proxy.
DOM interface:
interface Session : HTMLElement {
attribute double volume; // control speaker volume
attribute boolean mute; // control microphone
attribute boolean sendVideo; // control camera
attribute DOMObject videoPane;
attribute DOMString aorUrl;
attribute DOMString credential;
attribute DOMString outboundProxyURL;
readonly attribute DOMString remoteName;
readonly attribute boolean secure;
readonly attribute DOMString registrationState;
// noRegistrar, registering, registered, registrationFailed
attribute Function onRegisterStateChange;
void open( in DOMString url ); // tel or SIP URL
void close();
void accept( boolean accept );
readonly attribute DOMString sessionState;
// noSession, openingSession, acceptingSession,
// inSession, closingSession
attribute Function onSessionStateChange;
boolean sendKeyPress( in DOMString key ); // send DTMF or KPML
attribute Function onReceiveKeyPress;
};
If the session will be able to display video, the DOM object for a
video tag must be provided in the videoPane parameter of the
constructor. If an aorUrl is provided, the session will attempt to
register for incoming calls at the server using the provided
credentials. If an outbound proxy is provided, all signaling for
this session will use that proxy. The progress of the registration
can be tracked with the onRegisterStateChange callback. The
registrationState attribute will be a string with one of the
following values: noRegistrar, registering, registered, or
registrationFailed.
Jennings Expires September 8, 2011 [Page 10]
Internet-Draft RTC Web API Requirements March 2011
Open Issue: need to decide how to handle credentials and if they
will be in the JavaScript. Similar issues for TURN server
credentials.
To make a call, the open session method is called and the session
state will change to "opening session".
Events:
Exceptions:
4.1.1. Session Example Incoming
The following HTML snippet would display a video pane with a user
interface such that when the user clicked, it would create an audio
video session by making a SIP call to "sales@example.com".
<video width='320' height='240' >
<session src="sip:sales@example.com" >
</video>
4.1.2. Session Example Outgoing
The following HTML snippet would register to receive calls to the
address "sip:fluffy@example.com". Furthermore it would use an
outbound SIP proxy at sip.example.com.
<video width='320' height='240' >
<session aor="sip:fluffy@example.com"
credential="password"
proxy="sip:sip.example.com" >
</video>
4.2. Connection API
[NoInterfaceObject]
interface IceCandidate {
DOMString foundation;
unsigned short component-id; // always 1 ?
DOMString transport; // udp
unsigned long priority;
DOMString type; // host, srflx, prflx, relay
DOMString addressFamily; // v4 v6
DOMString connectionAddress; // v4 or v6 ip address
unsigned short port;
};
Jennings Expires September 8, 2011 [Page 11]
Internet-Draft RTC Web API Requirements March 2011
[NoInterfaceObject]
interface IceCandidateList {
IceCandidate candiate[];
DOMString icePassword;
DOMString iceUFragment;
};
[NoInterfaceObject]
interface RelayServer {
DOMString type; // stun turn
};
[NoInterfaceObject]
interface StunServer : RelayServer {
DOMString ip;
};
[NoInterfaceObject]
interface TurnServer : RelayServer {
DOMString ip;
DOMString username;
DOMString password;
};
[Constructor(in optional RelayServer relayServers[])]
interface Connection {
attribute int keepAlivetime; // default 30 seconds
attribute RelayServer relayServers[]
readonly attribute IceCandidateList candidateList;
readonly attribute IceCandidate connectionNearEnd;
readonly attribute IceCandidate connectionFarEnd;
void open( IceCandidateList addressList );
readonly attribute DOMString state;
// creating,ready,connecting,open,closed
attribute Function onready;
attribute Function onopen;
void send(in DOMString data);
attribute Function onmessage; // implements MessageEvent interface
attribute Function onerror;
void close();
Jennings Expires September 8, 2011 [Page 12]
Internet-Draft RTC Web API Requirements March 2011
attribute Function onclose;
};
The general usage for a browser that had a stun server at 192.0.2.1
would be to create a connection, wait for ICE to gather candidates
and the state to change to ready, then send the ICE candidates list
to the far side as shown in the following code.
Open Issue: Need to add more into this so that an application can
understand what is going on and get information to provide status and
debug problems as well as statistics. Also may need parameters to
change the algorithm.
myConn = new Connection( [ {type:"stun",ip:"192.0.2.1"} ] );
myConn.onready = function() {
myCandidates = myConn.candidateList;
// send myCandidates to far side
}
Open issue: add text around setter calling function if in that state
when set.
Later when the far side has sent its candidate list to this side, the
browser app calls open to start opening the connection to the other
side. Once the connection is open, the browser app can start sending
and receiving data.
myConn.open( farSideCandidateList );
myConn.onOpen = function() {
// can start sending data for far side
myConn.send( "Hello" );
}
myConn.onmessage = function(e) {
alert "Received data:" + e.data;
}
4.3. Audio Video API
Note this section is far from complete and is more just a sketch to
get the flavor of the interface.
interface Advertisement {
CodecAd codecs[];
boolean rtcpMux; // default true
boolean rtpMux; // default true
boolean srtp; // default true
DOMString protocols[];
// RTP/AVP, RTP/AVPF, UDP/TLS/RTP/SAVP, UDP/TLS/RTP/SAPF
Jennings Expires September 8, 2011 [Page 13]
Internet-Draft RTC Web API Requirements March 2011
srtpSuites[]; // AES_CM_128_HMAC_SHA1_32
};
interface CodecAd{
string mediaType;
int clockRate;
float minBandwidth; // kbps
float maxBandwidth; // kbps
boolean canReceive;
boolean canSend;
boolean supportDscp;
};
interface TelEventDataCodecAd {
int supportCodes[]; // defaults to 0-11 if not present
};
interface AudioCodecAd : CodecAd {
int maxPacketTime; // ms
};
interface IlbcAudioCodecAd : AudioCodecAd {
int modeList [];
}
interface G729AudioCodecAd : AudioCodecAd {
boolean vadSupported;
};
interface G711uAudioCodecAd : AudioCodecAd {
// G.711 PCMU must be 1 channel at rate of 8000
};
interface G711aAudioCodecAd : AudioCodecAd {
// G.711 PCMA must be 1 channel at rate of 8000
};
interface L16AudioCodecAd : AudioCodecAd {
int rates[];
int channels[];
DOMString emphasis[];
DOMString channel-order[];
};
interface AMRAudioCodecAd : AudioCodecAd {
DOMString modeSet;
// bunch more needed here
};
Jennings Expires September 8, 2011 [Page 14]
Internet-Draft RTC Web API Requirements March 2011
interface VideoCodecAd : CodecAd {
float maxFramerate; // fps
int clockRate;
int minXsize; int maxXsize;
int minYsize; int maxYsixe;
float minPar; float maxPar; float parList[];
float minSar; float maxSar; float sarList[];
};
interface VP8CodecAd : VideoCodecAd {
int versions[];
};
interface H264CodecAd : VideoCodecAd {
unsigned short profile-levls[];
unsigned short max-recv-level;
int max-mbps;
int max-smbps;
int max-fs;
int max-cpb;
int max-dpb;
int max-br;
boolean redundant-pic-cap;
DOMString sprop-parameter-sets;
DOMString sprop-level-parameter-sets;
boolean use-level-src-parameter-sets;
boolean in-band-parameter-sets;
boolean level-asymmetry-allowed;
int packetization-modes[];
int sprop-interleaving-depth;
int sprop-deint-buf-req;
long deint-buf-cap;
int sprop-init-buf-time;
// int sprop-init-buf-time;
long max-rcmd-nalu-size;
int sar-understood;
int sar-supported;
};
interface Proposal {
StreamProp streams[];
};
interface StreamProp {
string mediaType;
int clockRate;
Jennings Expires September 8, 2011 [Page 15]
Internet-Draft RTC Web API Requirements March 2011
float minBandwidth; // kbps
float maxBandwidth; // kbps
boolean canReceive; // default true
boolean canSend; // default true
DOMString fingerprint; // RFC4572
int pTime;
DOMString protocol;
// RTP/AVP, RTP/AVPF, UDP/TLS/RTP/SAVP, UDP/TLS/RTP/SAPF
long ssrc;
int dscp;
DOMString srtpSuites;
int srtpKdr;
boolean srtpUnencryptedRtcp;
boolean srtpUnauthenticated;
DOMString srtpFecOrder; //FEC_SRTP, "SRTP_FEC"
int srtpLifetime; // log base 2 of max packets with one kety
DOMString srtpKeys[];
int srtpMki[]; // MKI corresponding to srtpKeys at same index
};
interface VideoProp : StreamProp {
int sizex;
int sizey;
float sar;
float frameRate;
};
interface AudioProp : StreamProp {
int pTime; // ms
};
interface Stats {
StreamStats steam[];
};
interface StreamStats {
// TODO RTCP stats
};
interface AVT {
attribute Connection connection;
readonly attribute Advertisement advertisement;
readonly attribute Advertisement advertisementNoVideo;
attribute DOMObject camera;
attribute DOMObject mic;
attribute HTMLVideoElement videoPane;
Jennings Expires September 8, 2011 [Page 16]
Internet-Draft RTC Web API Requirements March 2011
readonly attribute Stats stats;
readonly attribute Proposal proposal;
boolean setProposal( Proposal newProp );
};
Using this interface is fairly simple. First an AVT object is loaded
and bound to an existing Connection object. It is also bound to
cameras, microphones, and speakers, Then the current advertisement
can be retried.
Open Issue: The SRTP keying should not be per stream.
var myAvt = org.w3c.device.load("device", "AVT", "1");
myAvt.connection = myConn; // the ICE formed connection
myAvt.camera = org.w3c.device.load("device", "camera", "1");
myAvt.mic = org.w3c.device.load("device", "mic", "1");
myAVT.videoPane = document.getElementById("myVideo");
mdAdv = myAvt.advertisement;
Open Issues: What's the best way to get an AVT object? How to get
the other devices and wire them up to the AVT object?
Assume that the browser supports VP8 video at 720P and G.711. The
myAvt object might look like:
Jennings Expires September 8, 2011 [Page 17]
Internet-Draft RTC Web API Requirements March 2011
{
"codecs" : [
{
"mediaType" : "PCMU",
"clockRate": "8000",
"maxPacketTime" : "60"
},
{
"mediaType" : "PCMA",
"clockRate": "8000",
"maxPacketTime" : "60"
},
{
"mediaType" : "VP8",
"clockRate" : "90000",
"maxXsize" : ""1440,
"maxYsize" : "720",
"parList" : [ "1.0" ],
"versions" : [ "1" ]
} ],
"protocols" : ["RTP/AVP", "RTP/AVPF" ]
};
Then, based on some knowledge about what the far end browser
supports, the system would decide that it wants to use PCMU with VP8
at a QCIF resolution and 15fps. After forming a connection to the
far end and waiting for the connection object to be in the ready
state, it would construct the following proposal object and then send
that proposal to the AVT systems as shown in the code below.
Assuming the proposal is acceptable, the setProposal returns true and
(returns false if it is not).
Jennings Expires September 8, 2011 [Page 18]
Internet-Draft RTC Web API Requirements March 2011
var proposal = {
"streams" : [
{
"mediaType" : "VP8",
"clockRate: : "90000",
"protcol" : "RTP/AVP",
"sizex" : "176",
"sizey" : "144",
"sar" : "1.0",
"frameRate" : "15",
"version" : "1"
},
{
"mediaType" : "PCMU",
"clockRate: : "8000",
"pTime" : "20",
"protcol" : "RTP/AVP"
} ]
};
if ( myAvt.setProposal( proposal ) ) {
// it worked
}
5. IANA Considerations
This document does not require any action of IANA.
6. Security Considerations
6.1. Attack Model
This architecture involves all the normal security consideration and
attack models of HTTP, SIP and RTP but introduces yet another key
issue. The assumption is that a user may browse to the attacker's
website. The other assumption is that the browser is behind a
firewall, and inside that firewall there are devices that would not
have appropriate security models for the internet. For example,
there could be SIP gateways that if sent an invite to call a 1-900
number would do so with no authentication or authorization. Whatever
HTML/CS/Javascript is downloaded must not be able to send arbitrary
packets to hosts behind the firewall or send SIP or RTP to devices
that do not consent to communicate with the browser.
Jennings Expires September 8, 2011 [Page 19]
Internet-Draft RTC Web API Requirements March 2011
6.2. Media Security
The browser MUST enforce the constraint that no RTP or other media is
sent to a given destination unless that destination completes an ICE
connectivity check and proves it knows the secret generated by the
browser. The browser must keep a list of locations it has attempted
to contact with ICE in the previous 30 seconds and not contact any
locations that have previously failed.
6.3. Signaling Security
The browser stops unwanted SIP signaling by using CORS REF. The same
CORS headers used for HTTP will be added to the SIP signaling.
Before the browser sends SIP signaling, it will preflight the SIP
messaging using a SIP OPTIONS message. This is done the same ways
CORS can preflight check an HTTP request.
7. Legacy VoIP Interoperability
There is no way to meet all the security requirements and maintain
comparability with all legacy VoIP equipment. This draft tries to
minimize the impedance mismatch. The requirements here would allow
interoperability with legacy VoIP equipment as long as that equipment
either directly supported, or was fronted by an SBC that supported,
the following: SIP CORS extension, ICE or ICE-Lite, codecs from the
mandatory to implement set, supported SIP invites containing an
offer, and supported DTMF over RTP with telephone events.
A substantial fraction of VoIP equipment does all of this except for
the CORS extensions. The item most commonly lacking is ICE-Lite but
that is becoming increasingly prevalent, particularly on devices
designed to sit on the edge of a domain and connect to remote UAs
that may be behind NATs. For an edge device that was willing to
receive SIP call from others, implementing the CORS is pretty
trivial. When the UAS receives a SIP options request with an Origin
header, it checks whether the header field value is on the white
list, and if it is then the UAS copies the value to the Access-
Control-Allow-Origin header field value in the response. For many
situations the white list would be everything, while for others it
would be just the list of websites that are expected to originate
calls to this SIP device.
8. Acknowledgement
Thanks to Joe Hildebrand, Matt Miller, Matthew Kaufman, Eric Rescorla
and Lyndsay Campbell for their review, comments and contributed
Jennings Expires September 8, 2011 [Page 20]
Internet-Draft RTC Web API Requirements March 2011
ideas.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.peterson-sipcore-advprop]
Peterson, J. and C. Jennings, "The Advertisement/Proposal
Model of Session Description",
draft-peterson-sipcore-advprop-00 (work in progress),
February 2010.
Author's Address
Cullen Jennings
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Jennings Expires September 8, 2011 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-22 21:59:47 |