[rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

[Christer Holmberg <[e-mail]>]

Hi,

Section 5.2.1:
-----------------

Q_1:      o- line <sess-version> initial value - deviation

What is the reason for recommending a <sess-version> zero value in the initial Offer, when the RFC says SHOULD use an NTP format timestamp?

I don't have any strong feelings, but in general: whenever we deviate from the "base" SDP procedures I think we should justify why.


Q_2:      o- line <sess-version> initial value - forking

When a new PeerConnection is created due to forking, the <sess-version> value must be based (incremented) on the value associated with the "mother" PeerConnection, for which the initial Offer of the whole communication session was created.


Q_3:      RTP

The text says:

"The <proto> field MUST be set to "RTP/SAVPF". "

But, that of course only applies to RTP based streams (not the data channel). Also, in general, it needs to be clear what information needs to be in every m- line, and what information is protocol specific. I would suggest to have a "General" sub-section, a "RTP" sub-section, etc.


Q_4:      BUNDLE

The text says:

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

As, when BUNDLE is used, the initial Offer will contain identical ICE candidates, does that mean that we will also include identical address information in the initial Offer?

I don't object to that - I just want to clarify, as it has impacts on the text in the BUNDLE spec :)


Section 5.2.2:
-----------------


Q_5:      Offer when in "local-offer"

The text 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, the steps for
                generating an initial offer should be followed,"

I don't understand this. Why would you create a new Offer while you are waiting for an Answer to the previously sent Offer?

Also, when setRemote() is called, to which Offer does it apply?


Q_6:      BUNDLE

We'll probably also need some text about BUNDLE.


Regards,

Christer