Draft: draft-ietf-rtcweb-jsep

Commentary: This includes my postal address .  closed that office . small editorial changes bogus whitespace . 
 PTAL 
 I think I 've got your changes and we are ready to land ? 
 LGTM
Paragraph (version A):
The createAnswer method generates a blob of SDP that contains an SDP
answer per RFC3264 with the supported configuration for the session
that is compatible with the parameters supplied in the most recent
call to setRemoteDescription, which MUST have been called prior to
calling createAnswer.  Like createOffer, the returned blob contains
descriptions of the media added to this PeerConnection, the
codec/RTP/RTCP options negotiated for this session, and any
candidates that have been gathered by the ICE agent.  An options
parameter may be supplied to provide additional control over the
generated answer.
Paragraph (version B):
The createAnswer method generates a blob of SDP that contains an SDP
answer per RFC3264 with the supported configuration for the session
that is compatible with the parameters supplied in the most recent
call to setRemoteDescription; setRemoteDescription MUST have been
called prior to calling createAnswer.  Like createOffer, the returned
blob contains descriptions of the media added to this PeerConnection,
the codec/RTP/RTCP options negotiated for this session, and any
candidates that have been gathered by the ICE agent.  An options
parameter may be supplied to provide additional control over the
generated answer.
Paragraph (version A):
Each "m=" section, provided it is not marked as bundle-only, MUST
generate a unique set of ICE credentials and gather its own unique
set of ICE candidates.  Bundle-only "m=" sections MUST NOT contain
any ICE credentials and MUST NOT gather any candidates.
Paragraph (version B):
Each "m=" section, provided it is not marked as bundle-only, MUST
contain a unique set of ICE credentials and a unique set of ICE
candidates.  Bundle-only "m=" sections MUST NOT contain any ICE
credentials and MUST NOT gather any candidates.
Paragraph (version A):
The next step is to generate "m=" sections for each "m=" section that
is present in the remote offer, as specified in RFC3264.  For the
purposes of this discussion, any session-level attributes in the
offer that are also valid as media-level attributes are considered to
be present in each "m=" section.  Each offered "m=" section will have
an associated RtpTransceiver, as described in sec.applying-a-remote-
desc.  If there are more RtpTransceivers than there are "m="
sections, the unmatched RtpTransceivers will need to be associated in
a subsequent offer.
Paragraph (version B):
The next step is to generate a "m=" section for each "m=" section
that is present in the remote offer, as specified in RFC3264.  For
the purposes of this discussion, any session-level attributes in the
offer that are also valid as media-level attributes are considered to
be present in each "m=" section.  Each offered "m=" section will have
an associated RtpTransceiver, as described in sec.applying-a-remote-
desc.  If there are more RtpTransceivers than there are "m="
sections, the unmatched RtpTransceivers will need to be associated in
a subsequent offer.