Draft: draft-ietf-rtcweb-jsep

Commentary: Python generator for SDP . Super simplified for the purposes of our examples , but should be reasonably flexible . Right now it only generates the simple example . Changes to the document : session attribs ordering now match text a = msid format now matches latest spec ( I think ) use  for MSIDs consistently use short ufrags , as one should group transport attribs together tweak indenting of fingerprint attrib Add support for dtls - id Only include a = rtcp in offers ( I think this is right ) Use simpler candidate foundations pick a more interesting port for the answer Relevant to and . 
 are these offers acceptable to chrome ? 
 I will verify this . 
 , are theses offers acceptable to FF ? 
 working on it 
 Looks like you are duplicating a = fingerprnt when you have a = bundle - only 
 " a = setup " is also " TRANSPORT " category and should n't be duplicated in answers or bundle - only / already - bundled offers . It does n't like the absence of " a = ice - ufrag " or " a = fingerprint " . I filed this bug just yesterday :  has the same issues , which I 'm working on fixing . 
 Note that bundle is not assumed in the offer , so each m= section should have its own transport attributes ( IIUC ) . [ Note that this PR only updates the example in 7.1 , not the example with bundle - only ( 7.2 ) ] 
 OK . All comments addressed . PTAL . 
 Passes 
 Follow new rules for a = rtcp , duplication of attributes Add dtls - id , rtcp - mux - only Maybe add imageattr 
 adds dtls - id , and I think follows the new rules for a = rtcp and attrib duplication . It does n't yet handle the second example or do rtcp - mux - only . 
 Fixed by 
 This would help avoid simple errors . We could polyfill the current impls to generate JSEP - compatible SDP . 
 I started work on a Python script that will do this .
Paragraph (version A):
RtpTransceivers generally have a 1:1 mapping with m= sections,
although there may be more RtpTransceivers than m= sections when
RtpTransceivers are created but not yet associated with a m= section,
or if RtpTransceivers have been stopped and disassociated from m=
sections.  An RtpTransceiver is never associated with more than one
m= section, and once a session description is applied, a m= section
is always associated with exactly one RtpTransceiver.
Paragraph (version A):
JSEP currently does not provide an API to configure receipt of
simulcast.  This means that if simulcast is offered by the remote
endpoint, the answer generated by a JSEP endpoint will not indicate
support for receipt of simulcast, and as such the remote endpoint
will only send a single encoding per m= section.  In addition, when
the JSEP endpoint is the answerer, the permitted encodings for the
RTPSender must be consistent with the offer, but this information is
currently not surfaced through any API.  This means that established
simulcast streams will continue to work through a received re-offer,
but setting up initial simulcast by way of a received offer requires
out-of-band signaling or SDP inspection.  Future versions of this
specification may add additional APIs to provide this control.
Paragraph (version B):
In addition, JSEP does not provide a mechanism to handle an incoming
offer requesting simulcast from the JSEP endpoint.  This means that
established simulcast streams will continue to work through a
received re-offer, but setting up initial simulcast by way of a
received offer requires out-of-band signaling or SDP inspection.
Future versions of this specification may add additional APIs to
provide direct control.
Paragraph (version A):
A rollback will disassociate any RtpTransceivers that were associated
with m= sections by the application of the rolled-back session
description (see sec.applying-a-remote-desc and sec.applying-a-local-
desc).  This means that some RtpTransceivers that were previously
associated will no longer be associated with any m= section; in such
cases, the value of the RtpTransceiver's mid attribute MUST be set to
null.  RtpTransceivers that were created by applying a remote offer
that was subsequently rolled back MUST be removed.  However, a
RtpTransceiver MUST NOT be removed if the RtpTransceiver's RtpSender
was activated by the addTrack method.  This is so that an application
may call addTrack, then call setRemoteDescription with an offer, then
roll back that offer, then call createOffer and have a m= section for
the added track appear in the generated offer.
Paragraph (version A):
To properly indicate use of DTLS, the <proto> field MUST be set to
"UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the
default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as
specified in I-D.nandakumar-mmusic-proto-iana-registration if the
default candidate uses TCP transport.
Paragraph (version A):
The fields of the "o=" line MUST stay the same except for the
<session-version> field, which MUST increment by one on each call
to createOffer if the offer might differ from the output of the
previous call to createOffer; implementations MAY opt to increment
<session-version> on every call.  The value of the generated
<session-version> is independent of the <session-version> of the
current local description; in particular, in the case where the
current version is N, an offer is created with version N+1, and
then that offer is rolled back so that the current version is
again N, the next generated offer will still have version N+2.
Paragraph (version A):
The 50 is based on 50 packets per second, the 40 is based on an
estimate of total header size, the 1000 changes the unit from
kbps to bps (as required by TIAS), and the 0.95 is to allocate
5% to RTCP.  If more accurate control of bandwidth is needed,
"TIAS" should be used instead of "AS".
Paragraph (version A):
Note: The following algorithm does not yet have WG consensus but is
included here as something concrete for the working group to discuss.
Paragraph (version A):
Construct a table mapping MID to RtpReceiver for each RtpReceiver
configured to receive from this transport.
Paragraph (version A):
Construct a table mapping incoming SSRC to RtpReceiver for each
RtpReceiver configured to receive from this transport and for each
SSRC that RtpReceiver is configured to receive.  Some of the SSRCs
may be present in the m= section corresponding to that RtpReceiver
in the remote description.
Paragraph (version A):
Construct a table mapping outgoing SSRC to RtpSender for each
RtpSender configured to transmit from this transport and for each
SSRC that RtpSender is configured to use when sending.
Paragraph (version A):
Construct a table mapping payload type to RtpReceiver for each
RtpReceiver configured to receive from this transport and for each
payload type that RtpReceiver is configured to receive.  The
payload types of a given RtpReceiver are found in the m= section
corresponding to that RtpReceiver in the local description.  If
any payload type could map to more than one RtpReceiver, map to
the RtpReceiver whose m= section appears earliest in the local
description.
Paragraph (version A):
As RtpTransceivers (and, thus, RtpReceivers) are added, removed,
stopped, or reconfigured, the tables above must also be updated.
Paragraph (version A):
If the packet has a MID and that MID is not in the table mapping
MID to RtpReceiver, drop the packet and stop.
Paragraph (version A):
If the packet has a MID and that MID is in the table mapping MID
to RtpReceiver, update the incoming SSRC mapping table to include
an entry that maps the packet's SSRC to the RtpReceiver for that
MID.
Paragraph (version A):
If the packet's SSRC is in the incoming SSRC mapping table,
deliver the packet to the associated RtpReceiver and stop.
Paragraph (version A):
If the packet's payload type is in the payload type table, update
the the incoming SSRC mapping table to include an entry that maps
the packet's SSRC to the RtpReceiver for that payload type.  In
addition, deliver the packet to the associated RtpReceiver and
stop.
Paragraph (version A):
Otherwise, drop the packet.
Paragraph (version A):
If the packet is of type SR, and the sender SSRC for the packet is
found in the incoming SSRC table, deliver a copy of the packet to
the RtpReceiver associated with that SSRC.  In addition, for each
report block in the report whose SSRC is found in the outgoing
SSRC table, deliver a copy of the RTCP packet to the RtpSender
associated with that SSRC.
Paragraph (version A):
If the packet is of type RR, for each report block in the packet
whose SSRC is found in the outgoing SSRC table, deliver a copy of
the RTCP packet to the RtpSender associated with that SSRC.
Paragraph (version A):
If the packet is of type BYE, for each SSRC indicated in the
packet that is found in the incoming SSRC table, deliver a copy of
the packet to the RtpReceiver associated with that SSRC.
Paragraph (version A):
If the packet is of type RTPFB or PSFB, as defined in RFC4585, and
the media source SSRC for the packet is found in the outgoing SSRC
table, deliver the packet to the RtpSender associated with that
SSRC.
Paragraph (version A):
After packets are routed to the RtpReceiver, further processing of
the RTP packets is done at the RtpReceiver level.  This includes
using I-D.ietf-mmusic-rid to distinguish between multiple Encoded
Streams, as well as determine which Source RTP stream should be
repaired by a given Redundancy RTP stream.  If the RTP packet's PT
does not match any codec in use by the RtpReceiver, the packet will
be dropped.