Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01

[Roman Shpount <[e-mail]>]

Paul,

What I wanted to see there, was that each party that specifies
"connection:new" SHOULD allocate a new transport. I understand that this
can cause both sides to allocate new transports, but, in case of ICE, or in
case when different addresses or ports are used to send and receive media
(asymmetric media), this is the only way for the end point to guarantee
that it will end up using a new 5-tuple for the created DTLS connection.
With ICE, it is difficult to determine that an end point is not reusing any
of the existing candidates. Without ICE, end point can continue to send
media from the same address/port even though it allocated a new
address/port to receive media. So, the options are either rely on the
remote party guarantee that it actually allocated the new transport and
detect the potential DTLS association collisions or allocate a new
transport and be sure 5-tuple is going to be unique. In cases, where remote
end point can be trusted to use new transport when "connection:new" is
used, rules for allocating new transport can be relaxed, but this is not
recommended.
_____________
Roman Shpount

On Mon, Jun 22, 2015 at 9:32 AM, Paul Kyzivat <[e-mail]> wrote:

> On 6/20/15 6:05 PM, Christer Holmberg wrote:
>
>>
>>  But there may be more to sort out about the o/a protocol for
>>> guaranteeing this. I can see a few:
>>>
>>> - if the offer has connection:new then the offer must have new
>>>    transport parameters. Else, if the offer has connection:existing
>>>    but the answer has connection:new then the answer must have new
>>>    transport parameters.
>>>
>>
>> Yes.
>>
>
> This is the algorithm you suggested above.
>
>  - if the answer has connection:new and the offer didn't have new
>>>    transport parameters, then the answer must have new ones.
>>>
>>
>> Yes.
>>
>
> This is a subtly different algorithm. It doesn't require the offerer to
> change transport parameters when specifying connection:new. It *can*, but
> it can also choose not to - forcing the answered to change them. (Or refuse
> the m-line, or refuse the offer.)
>
> It gives the offerer a little more flexibility, but then allows the
> offerer to put more burden on the answerer. There may be some obscure cases
> where the extra flexibility might be useful, though I have not yet thought
> of any.
>
> Either algorithm will work. This spec needs to choose one and explicitly
> state it.
>
>  Something about the above should probably go into section 6.
>>>
>>> * Section 5.1
>>>
>>>     A 'connection' attribute value of 'new' indicates that a new DTLS
>>>     association MUST be established.  A 'connection' attribute value of
>>>     'existing' indicates that a new DTLS association MUST NOT be
>>>     established.
>>>
>>> I think this is wrong - that the answerer is permitted to answer with
>>> connection:new.
>>>
>>
>> The was meant to say that an endpoint sending 'new' needs to use a new
>> set of transport parameters.
>>
>> However, if the offerer sends 'new', meaning it uses a new set of
>> transport parameters, I am not sure we need to mandate the answerer to use
>> a new set of transport parameters even if it sends 'new' in the answer.
>>
>
> So your intent was to specify the first of the algorithms I mentioned
> above. I did not get that out of this paragraph.
>