Hi,

Section 5.2.1:

-----------------

Q_1: o- line <se= ss-version> initial value - deviation

What is the reason for recommending a <sess-versi= on> 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 gener= al: whenever we deviate from the “base” SDP procedures I think = we should justify why.

Q_2: o- line <se= ss-version> initial value - forking

When a new PeerConnection is created due to forking,= the <sess-version> value must be based (incremented) on the value as= sociated with the “mother” PeerConnection, for which the initia= l 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 stream= s (not the data channel). Also, in general, it needs to be clear what infor= mation needs to be in every m- line, and what information is protocol speci= fic. I would suggest to have a “General” sub-section, a “RTP” sub-section, etc.

Q_4: BUNDLE

The text says:

“If a m=3D sectio= n is not being bundled into another m=3D section, it MUST

         &nb= sp;      generate a unique set of ICE credentials = and gather its own set of

         &nb= sp;      candidates. Otherwise, it MUST use = the same ICE credentials and

         &nb= sp;      candidates that were used in the m=3D sec= tion that it is being bundled

         &nb= sp;      into.”

As, when BUNDLE is used, the initial Offer will cont= ain identical ICE candidates, does that mean that we will also include iden= tical 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 o= ffer was applied using setLocalDescription, but an

         &nb= sp;      answer from the remote side has not yet b= een applied, meaning the

         &nb= sp;      PeerConnection is still in the "loca= l-offer" state, the steps for

         &nb= sp;      generating an initial offer should be fol= lowed,”

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

Also, when setRemote() is called, to which Offer doe= s it apply?

Q_6:      BUNDLE

We’ll probably also need some text about BUNDL= E.

Regards,

Christer