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

For Q.3, doesn't RFC 5764 say the proto field for DTLS-SRTP should be "
UDP/TLS/RTP/SAVPF"


On 19 September 2013 11:08, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  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****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>