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

[Roman Shpount <[e-mail]>]

On Mon, Oct 19, 2015 at 5:41 PM, Paul Kyzivat <[e-mail]> wrote:

> 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?
>

Anything which is compliant with the new specification MUST include
dtls-connection attribute. When inter-operating with legacy RFC5763
implementations, complaint implementation can receive an offer without
dtls-connection attribute. In such cases, this attribute has no default
value, and other means needs to be used in order for endpoints to determine
whether an offer or answer is associated with an event that requires the
DTLS association to be re-established.

We will extend the language in 5.1 to make this explicit.


> * 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.
>

You are correct, we will update the document.


>    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.
>

We will extend the language that if new DTLS association can be established
as a result of this offer/answer exchange, and if setup attribute "actpass"
or "passive", end point should be ready to accept the DTLS ClientHello.
Handling of DTLS association and associated media is somewhat tricky since,
on one hand end point would not want to discard DTLS packets to avoid
connection setup delay, on the other hand setting up DTLS association and
processing media received over this connection can be dangerous, since
remote party cannot be authenticate until signaling and fingerprint is
received.

We will propose the language to deal with this based on the discussions
which took place in ORTC group.

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.
>
>
Please look at my email in A.1. The end point which receives an offerless
INVITE does not know if the offer generated in response to it will be used
by some sort of 3PCC agent to setup a connection to new end point or will
be used within the existing connection. Since this ambiguity exists, we
decided to propose that a safer option should be used and new connection
should be created.
_____________
Roman Shpount