Re: [MMUSIC] Draft new version: DTLS-SDP-01

[Paul Kyzivat <[e-mail]>]

A few comments while reading it:

* Section 5.1 vs. 6.2:

For the initial offer of a DTLS m-line there isn't any option whether to 
establish a DTLS association - one is going to be established. Section 
5.1 says use of dtls-connection is optional, but 6.2 says it is 
required. Which is it?

* Section 6.3:

There seems to be an bug in this text:

    If an answerer receives an offer that contains an SDP 'dtls-
    connection' attribute with a 'new' value, the answerer MUST insert a
    'new' value in the associated answer.  The same applies if the
    answerer receives an offer that contains an SDP 'dtls-connection'
    attribute with a 'new' value, but the answerer determines (based on
    the criteria for establishing a new DTLS association) that a new DTLS
    association is to be established.

IIUC, in "The same applies ... with a 'new' value" the 'new' should be 
'existing'. Otherwise it simply reiterates the prior sentence. This 
particularly includes the case when the answerer has no existing 
association.

    If a new DTLS association is to be established, and if the answerer
    becomes DTLS client, the answerer MUST initiate the procedures for
    establishing the DTLS association.  If the answerer becomes DTLS
    server, it MUST wait for the offerer to establish the DTLS
    association.

Isn't there a timing problem here? What if this case applies, but the 
offerer won't know it until receiving the answer? (I.e., when the offer 
contained 'existing'.) In that case the messages to initiate might 
outrun the answer, and arrive before the offerer is ready for them.

In section 8:

    It is possible to send an INVITE request which does not contain an
    SDP offer.  Such INVITE request is often referred to as an 'empty
    INVITE', or an 'offerless INVITE'.  The receiving endpoint will
    include the SDP offer in a response associated with the response.
    When the endpoint generates such SDP offer, it MUST assign an SDP
    connection attribute, with a 'new' value, to each 'm-' line that
    describes DTLS protected media.  If ICE is used, the endpoint MUST
    allocate a new set of ICE candidates, in order to ensure that two
    DTLS association would not be running over the same transport.

Can you explain your thinking here? This makes sense if the response is 
the initial offer. But if there has been a prior O/A in the dialog, then 
this doesn't seem right to me.

	Thanks,
	Paul