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

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Oct 2015 09:23:29 +0000

Hi,

I've submitted a new version (-01) of draft-ietf-mmusic-dtls-sdp.

The main change is that the SDP 'connection' attribute has now been replaced with a new, DTLS specific, SDP attribute, 'dtls-connection'. The procedures are more or less the same.

I've also added Roman's idea of a "connection id" to the end of the draft, for people to have a look at. I'd like to decide on a way forward asap.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2015 17:41:10 -0400

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Oct 2015 18:04:08 -0400

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

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

> particularly includes the case when the answerer has no existing

You are correct, we will update the document.

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

> 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