Currently, the examples only show non-trickle cases.

Section 5.3.1 says:

o If the "trickle" ICE option is present in the offer, an "a=ice-
options" line, with the "trickle" option, as specified in
[I-D.ietf-mmusic-trickle-ice], Section 4.
o For each candidate that has been gathered during the most recent
gathering phase, an "a=candidate" line, as specified in [RFC5245],
Section 4.3., paragraph 3.
o For the current default candidate, a "c=" line, as specific in
[RFC5245], Section 4.3., paragraph 6. If no candidates have been
gathered yet, the default candidate should be set to the 'null'
value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.

If the offer didn't provide a trickle option, should we be doing trickle
here?

Section 3.4 reads:

When a new ICE candidate is available, the ICE Agent will notify the
application via a callback; these candidates will automatically be
added to the local session description. When all candidates have
been gathered, the callback will also be invoked to signal that the
gathering process is complete.

However, we agreed in London that we would do "always trickle", and
that even if there were candidates available at the time when CreateOffer
(because of candidate pooling) was called, they would not be included
in the initial offer. Consider the following sequence of events.

1. pc = new RTCPeerConnection();
2. pc.AddStream(stream);
3. pc.CreateOffer();
4. CreateOffer callback fires with offer A, and you call SetLocalDescription();
5. onicecandidate fires with candidate X.
6. pc.CreateOffer()
7. CreateOffer callback fires with offer B.
8. onicecandidate fires with null.

So, in London, I think we agreed that offer A would have no candidates.
The above text implies that if you were to examine localdescription prior
to step #5 or at step #7 it would contain candidate X, and probably that offer B would
also contain candidate X.

Note that it's quite inconvenient for non-trickle applications to never
have any candidates in the SDP, especially after gathering is completed
at step #7. However it also seems kind of inconsistent to only update the
candidates after SetLocal() has been called.

Jonatan to send high level solution, Cullen write up details, get Flemming to review.

S 5.2. says, in the section describing generating m= sections.

o [OPEN ISSUE: Use of AppID]

This needs to be resolved.

S 5.2.1 says:

Attributes that are common between all m= sections MAY be moved to
session-level, if explicitly defined to be valid at session-level.

This seems like it would be better as a should

Does it happen on PC construction, or on receiving a remote offer? Justin and Cullen thought the former, with unlimited binding keepalive time; Eric thought the latter.

The current specification describes a rehydration procedure in S 3.6 as a new call from one side and a renegotiation from the other. This isn't worked out in much detail and it's not clear if the text here is just guidance or if it has spec impacts.

EKR had another proposal involving explicltly storing the PC briefly and then reconstructing it.

Need to go through 3.6 and see if this procedure works as-is.

S 5.2.2 says:

If the initial offer was applied using setLocalDescription, but an
answer from the remote side has not yet been applied, meaning the
PeerConnection is still in the "local-offer" state, an offer is
generated by following the steps in the "stable" state above, along
with these exceptions:

o The "s=" and "t=" lines MUST stay the same.
o Each "a=mid" line MUST stay the same.
o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same.

However, Section 5.2.3.4 says:

If the "IceRestart" constraint is specified, with a value of "true",
the offer MUST indicate an ICE restart by generating new ICE ufrag
and pwd attributes, as specified in RFC5245, Section 9.1.1.1. If
this constraint is specified on an initial offer, it has no effect
(since a new ICE ufrag and pwd are already generated).

1. Section 1):

[W3C.WD-webrtc-20111027]
This is very old version of the API, please update to the currently
relevant version.

JU: Will do.

2. Section 3.4.1.1:
   The m-line index is a zero-based index, referring to the Nth m-line in
   the SDP.

a) I think the above is a bit confusing. As a zero-based index would
mean that the first m= section would have index 0. Thus, the referring
to the Nth m-line in the SDP is unclear. Is N, the provided index, in
which case it would be the N+1th m-line. Please rewrite.

JU: Will clarify.

b) I also wonder if one has to be clearer on what "the SDP" is. I assume
it is the one that has been generated by the agent, rather than the
latest sent or received?

JU: It can be for either the local generated SDP, in the case where the candidate is gotten from the onicecandidate callback, or the remote SDP, in the case where the candidates are trickled from the remote side. We'll add some text to make this clear.

3. Section 3.4.1.1:
   "The MID uses the "media stream identification", as defined in
   [RFC5888] , to identify the m-line."

a spurious space after ref.

JU: OK.

5. Section 3.5.2:
   In the parallel forking case where the Javascript application wishes
   to simultaneously exchange media with multiple peers, the flow is
   slightly more complex, but the Javascript application can follow the
   strategy that [RFC3960] describes using UPDATE. (It is worth noting
   that use cases where this is the desired behavior are very unusual.)

I mostly react to the last sentence within the paragraph. I think the
poster child for semi-parallel forking was the MMORG that like to
establish PCs with anyone that is coming close in the virtual world.
Thus either needs to have a number of PCs on standby or have just one,
but treat that as parallel forking. And if you like to discourage the
later, then I think you might need to at least inform about the
possibility to have stand-by PCs.

JU: Is the MMORG case described in the use-case doc? If so, I agree the parenthesized text should be changed.

1. Section 4.1.1:
   There is no discussion of how the bundle policies relate to the Data
   Channels? Are they included or do they have a specific set of policies.
   Please extend this to discuss this.

JU: Will do.

1. Section 4.1.3:

This text doesn't appear to contain a requirement on that one MUST have
called setRemote prior to being able to call it.

JU: Will fix.

1. Section 4.1.4.1:
   While this could also be done with an inactive "pranswer", followed
   by a sendrecv "answer", the initial "pranswer" leaves the offer-
   answer exchange open, which means the caller cannot send an updated
   offer during this time.

Should one mention that also the callee can't send an offer without
doing a "final" answer?

JU: The callee could still send more pranswers, so it is not as restricted in this state as the caller. However, it can't add streams at this point, so there are some limitations.

If you think this is unclear I could change the text to say "neither side can send an updated offer during this time"

1. Section 4.1.4.1

By the time the human has accepted the call and
triggered the new offer, it is likely that the ICE and DTLS
handshaking for all the channels will already be set up.

Wouldn't the handshaking have "finished" rather than "set up"?

JU: Yes.

1. Section 4.1.4.2:
   Rollback can only be used to cancel proposed changes; there is no
   support for rolling back from a stable state to a previous stable
   state.

What is meant with "proposed changes"? From my side it is not clear how
much you can do after having performed a SetLocal or SetRemote. I think
these needs to be treated separately.

For an offerer, they can createOffer, SetLocal, send to peer, receive
reject and then undo the SetLocal. That is straight forward, and if they
done the SetRemote, they would be consider in a new Stable state and
can't roll back anymore?

For the answering side, it receive an offer, does SetRemote,
CreateAnswer, determines that it doesn't like it, the can undo the
SetRemote and send a reject message to offerer.

But what about this case? it receive an offer, does SetRemote,
CreateAnswer, SetLocal and sends the message, then receive a reject from
the peer, because it didn't like the answer? Are the answerer then in a
stable state that can't be unrolled, or?

JU: If you don't like the answer, I think it's game over. The answerer has already started acting on the new local/remote description at this point.

IOW, "proposed changes" really only means what has been offered.

1. Section 5.2.1:
   The CNAME must be generated
   in accordance with draft-rescorla-random-cname-00. [OPEN ISSUE:
   How are CNAMEs specified for MSTs? Are they randomly generated
   for each MediaStream? If so, can two MediaStreams be synced?]

I think you should point to the RTP usage for this particular piece.
Because we do have text there both for the CNAME generation and how
CNAMES among MSTs and between PeerConnection. Likely to be changed soon
based on the mailing list discussion.

JU: Agreed.

1. Section 5.2.1:
   Once all m= sections have been generated, a session-level "a=group"
   attribute MUST be added as specified in [RFC5888]. This attribute
   MUST have semantics "BUNDLE", and MUST include the mid identifiers of
   each m= section.

Isn't this overriding BUNDLE as currently specified, forcing everything
into a single bundle group. Thus, preventing the bundle policies to work.

JU: The BUNDLE policies only affect what is bundle-only. Between two browsers, a single BUNDLE will always be used.

1. Section 5.2.2:

   o If any MediaStreamTracks have been added, and there exist m=
   sections of the appropriate media type with no associated
   MediaStreamTracks

Isnt' the last a "MediaStreamTrack" rather than plural ones?

JU: Agree this could be clarified.

1. Section 6:
   Note: This section is still very early and is likely to significantly
   change as we get a better understanding of a) the use cases for this
   b) the implications at the protocol level c) feedback from
   implementors on what they can do.

Shouldn't this mention W3C discussion also?

JU: Sure.

1. section 10

There are a couple of draft references that are either published RFCs or
at least WG versions. Please update the reference list.

JU: OK.

1. Section 10.2:
   Looking at the spec, I think the following references are normative:

   [I-D.ietf-mmusic-trickle-ice]
   Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
   Incremental Provisioning of Candidates for the Interactive
   Connectivity Establishment (ICE) Protocol", draft-ietf-
   mmusic-trickle-ice-00 (work in progress), March 2013.

   [I-D.ietf-rtcweb-data-protocol]
   Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
   Protocol", draft-ietf-rtcweb-data-protocol-04 (work in
   progress), February 2013.

JU: OK.

The current example in S 3.2 refers to SDES, but that's not in JSEP any more.

We need a new example.

IIRC, discussion on mailing list came down in favor of emitting RTP/SAVPF but accepting RTP/SAVPF or UDP/TLS/RTP/SAVPF. Need to confirm and adjust document accordingly.

S 4.1.4.1 reads:

" Most web applications will not need to create answers using the
"pranswer" type. While it is good practice to send an immediate
response to an "offer", in order to warm up the session transport and
prevent media clipping, the preferred handling for a web application
would be to create and send an "inactive" final answer immediately
after receiving the offer. Later, when the called user actually
accepts the call, the application can create a new "sendrecv" offer
to update the previous offer/answer pair and start the media flow.
While this could also be done with an inactive "pranswer", followed
by a sendrecv "answer", the initial "pranswer" leaves the offer-
answer exchange open, which means the caller cannot send an updated
offer during this time.
"

We need an example for this.

Right now, the VAD option in the createOffer options allows the app to control use of DTX/CN in received audio. It seems like we'd want to allow this in createAnswer as well, for the audio going the other way.

Additional Q: what should the default be, if VAD is present/not present in the offer?
Additional Q: what should the default be, if VAD was previously in use in the session?

Section 5.2.1
o [OPEN ISSUE: Handling of a=imageattr]

There needs to be a way for a browser to indicate the upper bound of what it can receive (if it wants too). A mobile device may want to indicate not to send video larger than it's screen. A desktop system may not want to indicate any limit. The w3c API might surface a control surface for this.

If the browser receives a limit on what the other side can send or receive, it needs to honor that.

The text currently forbids changing of ICE credentials. There's an argument that states this is no longer necessary since DTLS is mandatory. We should resolve this point.

Outline: https://docs.google.com/a/google.com/document/d/1XzhL55Z9PibChNz7nUwE7p0tJYhItTTw0USRUirtTMg/edit

JSEP S 5.2.1 reads:

Each m= section, provided it is not being bundled into another m=
section, MUST generate a unique set of ICE credentials and gather its
own unique set of ICE candidates. Otherwise, it MUST use the same
ICE credentials and candidates that were used in the m= section that
it is being bundled into.

But Section 15.4 of ICE explicitly permits m-lines to share credentials, and of course ICE knows nothing of BUNDLE:

The "ice-pwd" and "ice-ufrag" attributes can appear at either the
session-level or media-level. When present in both, the value in the
media-level takes precedence. Thus, the value at the session-level
is effectively a default that applies to all media streams, unless
overridden by a media-level value. Whether present at the session or
media-level, there MUST be an ice-pwd and ice-ufrag attribute for
each media stream. If two media streams have identical ice-ufrag's,
they MUST have identical ice-pwd's.

Is there a reason for requiring unique credentials? If not I suggest we remove this
requirement.

Section 5.2.1:
in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs
specified for MSTs? Are they randomly generated for each
MediaStream? If so, can two MediaStreams be synced?]

The text reads:

o For each candidate that has been gathered during the most recent
gathering phase, an "a=candidate" line, as specified in [RFC5245],
Section 4.3., paragraph 3.

o For the current default candidate, a "c=" line, as specific in
[RFC5245], Section 4.3., paragraph 6. If no candidates have been
gathered yet, the default candidate should be set to the 'null'
value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1.

However, if we are doing trickle-only, than an initial offer should never have any
candidate lines. We should move this text to S 5.2.2 pending the resolution of issue #11

Long discussion on mailing list and at IETF 89, and I forget the conclusion.

Should you be allowed to create an offer in remote-pranswer?

See Section 6:
o change maximum total bandwidth (b=) [OPEN ISSUE: need to clarify
if this is CT or AS - see section 5.8 of [RFC4566]]

The text relies on the phrase "most recent gathering phase" to describe which candidates are present in SDP.

Justin enumerated a few cases where the browser gathers a completely new set of candidates for an m= section (or component thereof):

• when a new m= section is added (which happens for a new RTCPeerConnection obviously)
• when an m= section did have a port of 0, but is repurposed for new media (basically the same scenario as above)
• ICE restart

This needs a clearer definition, or maybe just a single clear description of what it means to do this. This can probably tie into the whole process of describing when candidate events fire and the interaction between that and setLocalDescription.

http://www.ietf.org/mail-archive/web/rtcweb/current/msg12390.html

Justin to respond on the list and the changes to be attached to this issue.

• circuit-breakers (SHOULD?)
• REMB (?)

Right now there is no way to mark a m= line as sendonly. RtpReceiver will add the .active property, which, when frobbed, will set a=sendonly, but no RtpReceiver exists at the time of the initial call to createOffer.

Therefore we may need some mechanism to control this. OfferToReceiveAudio:-N (a negative number) is one simple, if imperfect option.

Section 5.2.2 says:

o If any MediaStreamTracks have been added, and there exist m=
sections of the appropriate media type with no associated
MediaStreamTracks (i.e. as described in the preceding paragraph),
those m= sections MUST be recycled by adding the new
MediaStreamTrack to the m= section. This is done by adding the
necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the
recycled m= section, and removing the "a=recvonly" attribute.

ISTR that this did not have consensus. Note to myself to double-check and close if it did. I can't find it in the IETF89 minutes.

Section 6 indicates that programmers can edit the SDP and lists changes which can and cannot be made. It explicitly is preliminary and needs to be fleshed out.

The proposed scenario is where .iceTransports is set to 'relay', and so relay gathering occurs first; non-relay gathering only occurs after .iceTransports is changed to 'all'.

The flow is something like:
new PC({iceTransports: 'relay'})
setRD(offer)
createAnswer
setLD(answer)
onicegatheringstatechange(gathering)
onicecandidate(relay1)
onicecandidate(relay2)
A: setConfiguration({iceTransports: 'all'})
onicecandidate(null)
onicegatheringstatechange(complete)
B: setConfiguration({iceTransports: 'all'})

In case A, we could definitely release the gathered ICE candidates immediately, with no issues. But in case B, does it make sense to emit them, since gathering has completed?

Options:

1. Emit them. No state change occurs. You called this API, you deal with it. (My preference.)
2. Transition back to gathering, emit the candidates (which will happen immediately, necessarily), go back to complete. (Changes the meaning of a gathering transition.)
3. No candidates are emitted, no state change occurs. The new type of candidates is gathered on the next ICE restart. (Complicates the use case above. But allows changing type to a more restrictive type.)

Section 5.2.1
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-
passwd", "a=ice-options", "a=candidate", "a=fingerprint", and
"a=setup" lines MUST be included as mentioned above, along with an
"a=sctpmap" line referencing the SCTP port number and specifying the
application protocol indicated in [I-D.ietf-rtcweb-data-protocol].
[OPEN ISSUE: the -01 of this document is missing this information.]

JSEP S 4.1.7 and 4.1.8 read:

" TODO: Do we need to expose accessors for both the current and
proposed local description?"

and

" TODO: Do we need to expose accessors for both the current and
proposed remote description?"

It's confusing to have a bundle policy which is named default and is also the default.

I suggest renaming it "mixed" or something and then saying it is the default.

JSEP uses literal cross-references (e.g.,
"The exact handling of initial offer generation is detailed in Section 5.2.1. below")

These should be changed to xrefs in the XML.

The JSEP initial offer text contradicts mmusic-trickle-ice.

Add text to make it clear that if you are in the passive role, and an actpass offer comes in, you want to keep passive instead of picking active (as would typically be the case).

Right now, any changes to the session, via addStream/addTrack, or tweaks on the upcoming RtpSender object, trigger onnegotiationneeded. This makes handling of onnegotiationneeded by the application difficult.

Harald suggests only firing onnegotiationneeded when in the stable state. This doesn't solve the situation fully when you add multiple tracks, but it should allow applications to always call createOffer in response to an onnegotiationneeded.

Cullen also is concerned about how Harald's proposal would interact with PRANSWER.

The VAD section in JSEP indicates the use of CN, which is not mandated in the RTP usage draft yet. Support for CN should be mandatory.

JSEP says:

S 4.1.1.
" The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN
servers and credentials to use when gathering candidates. The size
of the ICE candidate pool can also be set, if desired; by default the
candidate pool size is zero."

The WebRTC spec says:
"At this point the ICE Agent does not know how many ICE components it needs (and hence the number of candidates to gather), but it can make a reasonable assumption such as 2. As the RTCPeerConnection object gets more information, the ICE Agent can adjust the number of components"

Depends on resolution of FEC on mailing list

S 5.3.1 reads:

For each offered m= section of a given media type, if there is a
local MediaStreamTrack of the specified type which has been added to
the PeerConnection via addStream and not yet associated with a m=
section, and the specific m= section is either sendrecv or recvonly,
the MediaStreamTrack is associated with the m= section at this time.
If there are more m= sections of a certain type than
MediaStreamTracks, some m= sections will not have an associated
MediaStreamTrack. If there are more MediaStreamTracks of a certain
type than compatible m= sections, only the first N MediaStreamTracks
will be able to be associated in the constructed answer. The
remainder will need to be associated in a subsequent offer.

I assume the ordering here should be the same as in the offer case, but this doesn't say so.

Editorial changes:

I guess my one comment addressing the document as a whole would be
that the examples used in the draft are helpful in explaining certain
aspects and therefore even more examples would be even more helpful.

J: Which particular examples were most useful - the inline hand-wavy descriptions, the API flows, or the example SDP?

• Section 1.1, Paragraph 3, Last Sentence

"This mechanism effectively removes the browser almost completely
from the core signaling flow; the only interface needed is a way
for the application to pass in the local and remote session
descriptions negotiated by whatever signaling mechanism is used,
and a way to interact with the ICE state machine."

I think this can be reworded to be clearer and more powerful, something
such as:

"JSEP removes the browser almost entirely from the core signaling flow.
The Javascript application needs interfaces for only (1) passing in
local and remote session descriptions and (2) interacting with the ICE
state machine."

Perhaps the exact wording I've suggested is not ideal, but something
that more clearly shows that JSEP removes the browser from the signaling
flow and that the application (and therefore, the application's
developer) needs to do only two things for establishing a session. The
way it is worded now is unclear at first read and does not adequately
persuade me why JSEP is awesome (IMO).

J: Agree your wording is more direct. We'll rework this part.

• Section 3.4.2, Paragraph 1

"However, to accelerate cases where the browser knows the number of
media streams to use ahead of time"

An example of a situation where the browser might know the number of
media streams ahead of time might be useful for context here, if one is
easily explained.

J: Sure, that makes sense. The typical case here is for an endpoint that wants to be able to quickly set up a received call. The caller has the ability to just start the call and leave it in the local-offer state instead.

• Section 3.5.1, Paragraph 2

"... the application can choose to apply it either as a provisional
answer, leaving open the possibility of using a different answer in
the future, or apply it as a final answer, ending the setup flow."

How does the application decide whether to apply as provisional or
final? Does JSEP care at all or is this left entirely up to the
application to decide? This is expounded on somewhat in the 2 paragraphs
that follow, but I still don't feel like these questions are completely
answered.

J: This is an application decision; in JSEP's opinion, forking should overall be avoided.

• Section 4.1.2, Paragraph 2

"the generated SDP will contain all desired functionality for the
session (certain parts that are supported but not desired by
default may be omitted)"

I think this sentence would be clearer if "certain parts that are" was
replaced with "functionality that is".

J: Agreed.

• Section 4.1.2, Paragraph 3

"For each existing stream, the generation of each SDP line must
follow the process defined for generating an updated offer from the
document that specifies the given SDP line."

This sentence was too hard to compute in my opinion, and I'm still not
quite sure what "the document" refers to. I think rewording would be
beneficial.

J: Agreed - refer to "the RFC" or somesuch

• Section 5.1.2, bullet R-2

"R-2 ICE, as specified in [RFC5245], MUST be used. Note that the
remote endpoint MAY use a Lite implementation."

This shouldn't be MAY because it is not referring to an optional
implementation specification of JSEP but rather a possible scenario that
JSEP needs to support. It should read as just a warning and possibly
specify that JSEP MUST be equipped to interface with an endpoint that is
using a Lite ICE implementation.

J: Agree. We'll adjust accordingly (MAY->may, MUST handle ice-lite)

• Section 5.2.1, bullet 3

" o The third SDP line MUST be a "s=" line, as specified in
[RFC4566], Section 5.3; to match the "o=" line, a single dash
SHOULD be used as the session name, e.g. "s=-"."

Is there a reason to ignore the following SHOULD from RFC4566?

"If a session has no meaningful name, the value "s= " SHOULD be
used (i.e., a single space as the session name)."

It seems like "-" and " " are both equally meaningless, so why deviate
from the standard? (I'm also not sure why we need to match it with the
username in the o= line). There may be good reason for both of these,
but it is not clear to me from reading the draft so I wanted to bring
it up.

J: It's entirely arbitrary. Since they are meaningless, I figured using similar meaningless values made this more clear than individual meaningless values. We can add some text to make this clear.

• Section 5.2.1, Paragraph 3

"The next step is to generate m= sections for each
MediaStreamTrack..."

Consider adding: "...as specified in [RFC4566] Section 5.14..." The
draft references specific sections for the other SDP fields and I think
it is useful here as well.

J: Sounds good.

• Section 5.2.3, Paragraph 1

"The createOffer method takes as a parameter a MediaConstraints
object. Special processing is performed when generating a SDP
description if the following constraints are present."

I think an example of when this would be useful might be nice for context.

J: I assume you are asking for when each of the individual constraints parameters would be useful. That sounds helpful. (also dictionary change)

• Section 5.2.3.1 AND Section 5.2.3.2, Paragraph 1

"If the "OfferToReceiveVideo" constraint is specified, with a value
of "N", the offer MUST include N non-rejected m= sections with
media type "video",... "

The use of "N" is confusing. Is "N" referencing an integer value or a
string with value "N". I think removing the quotes around "N" would make
it entirely more understandable.

J: Agreed. Constraints have been replaced with dictionaries, so we can clearly refer to this as an integer var.

• Section 5.3.1, Paragraph 5

"For each offered m= section of a given media type, if there is a
local MediaStreamTrack of the specified type which has been added
to the PeerConnection via addStream and not yet associated with a
m= section, and the specific m= section is either sendrecv or
recvonly, the MediaStreamTrack is associated with the m= section
at this time."

This sentence is long and hard to parse. I think rewording and/or
breaking up would be beneficial.

J: OK.

The SDP will indicate a=recvonly, but it won't be clear if the stream is stopped or merely held. Harald proposed msid-control at IETF 89 to deal with this, but IIRC there wasn't consensus for this yet.

We should probably not include these. Not clear what we want to do if someone has set values.

1. Section 4.1.9:

Should this section discuss that it might be browser that has overriding
controls regarding if other candidates then relay ones may be provided,
i.e. privacy mode?

JU: Probably. The use of host candidates is something that might be forbidden by local policy. I think the right thing to do would be to introduce the concept of iceTransports in section 3.4 (ICE), and then refer to it here in updateIce (now called setConfiguration), as well as the ctor section, where the initial policy can be set.

1. Section 5.2.1:

Structure in relation between RTP media and DATA channel. Maybe you
should try to find a structure that makes the difference between the two
types of transport more clear, and what applies to the perspective.

JU: Agree this could be improved.

1. 5.2.3.3. VoiceActivityDetection

   If the "VoiceActivityDetection" constraint is specified, with a value
   of "true", the offer MUST indicate support for silence suppression by
   including comfort noise ("CN") codecs for each supported clock rate,
   as specified in [RFC3389], Section 5.1.

As currently specified this text requires the usage of a comfort noise
codec, currently there is no such on required. I think the "MUST" needs
to be rewritten.

JU: I think this needs to be specified as a MUST in RTP usage then. Otherwise, this setting won't work in some browsers, leading to nondeterministic behavior.

This should also be updated to set usedtx=1 for Opus.

1. Section 5.3.1:
   Note
   that for simplicity, the answerer MAY use different payload types
   for codecs than the offerer, as it is not prohibited by
   Section 6.1.

I react to the word simplicity here. I never consider usage of different
PTs per direction anything simple. But, yes it is allowed by RFC 3264.
But I kind of protest to encourage the usage.

JU: Clearly this needs more explanation. The basic issue is the fact that using the same payload types gets really hairy when using RTX and when bundling. We can add an example of the problem.

Cullen wants LS groups because that is what legacy gear understands.

Magnus wants to use MSID, which carries this.

They affect generated SDP, so they need to appear in Jsep.