Change:
the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in <del> 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?] </del> <ins> 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?] </ins> If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in

Discussion:
Justin, what are you looking for me to do here?
? This is ancient.
it seems this was dealt with long ago. I have no idea why it says I assigned it to EKR and hour ago ?
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right
From EMAIL: Question 1: Should this be interpreted literally, to mean "the next call, and only the next call to createOffer will generate new ICE credentials"? If so, there are various situations wherein one could encounter unexpected behavior. For example: Before createOffer is called, a remote offer is received that triggers an ICE restart. Should the next call to createOffer trigger another, superfluous ICE restart? createOffer is called twice, without setting the local description (and kicking off a new gathering phase). Should the second call generate new credentials, or only the first? I would propose a slight change, such as: "this will cause subsequent calls to createOffer to generate new ICE credentials, until a new gathering phase has started." This would more clearly represent the intent of the original rule, in my opinion. Question 2: The next paragraph states "Any changes to the ICE candidate policy also affect the next gathering phase, in similar fashion to the server changes described above." Does this mean that changes to the candidate policy will also cause an ICE restart, according to the same rules? I assume so, but figure it's worth asking.

On , any changes should set a needs-ice-restart bit, which is only cleared by setLD with new ICE credentials (although, possibly only by setLD + setRD, since the setLD could be rolled back) On , if the ICE policy is being made more restrictive, no ICE restart is needed. Obviously if less restrictive, then the needs-ice-restart bit will be set.
Both you proposed resolutions look good to me