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

Roman Shpount <> Mon, 22 June 2015 17:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8AC8F1B30AE for <>; Mon, 22 Jun 2015 10:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.079
X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4f6xiNkHu_V9 for <>; Mon, 22 Jun 2015 10:14:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 659C91B30AB for <>; Mon, 22 Jun 2015 10:14:21 -0700 (PDT)
Received: by igin14 with SMTP id n14so20966293igi.1 for <>; Mon, 22 Jun 2015 10:14:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LCwRaJ5HwaIaBp+BNBEuGolNNGq3r8X8Esfnz95gDs4=; b=LpMk9/snvplR8qSZQ9Ger5iZRJ+V9ueimm0XW6xR9yRKiKIRCPvoHzlE/gVXO1dwlR u/rZ+LN0a/25q/0CX3LS8H7CFftBOa/GhRRCjCxOuQ3qFJW32Po6OmvbhHhpfr06nvBk 2oRRlUWknk0EOaO5pfBS2ufQGoP2jQVsV/6DOa8j6EGjevN8pJRLl7pNabpxJzuEDfVr AmPmKNgkYyGn0/DLmxouPz52rDiiYMPOhyeMpiRJqSwuAphBX5h9ur4jLQ7/ALdpTSx8 UCIdyt1t6dbJhlchA1SrhMdu1fHNOUAcpV4qSOBc/4t/luCSqrAo/KDY6qYGjQFf+Toy LAQg==
X-Gm-Message-State: ALoCoQknUAFv4EEOUxhKP/F7kylo/DubbSU/ueKgBaB5jFCdu6P9tJ8GlhxdKXx/4f1GLSvNYvK3
X-Received: by with SMTP id eu8mr27341313icb.65.1434993260824; Mon, 22 Jun 2015 10:14:20 -0700 (PDT)
Received: from ( []) by with ESMTPSA id q10sm7883204ige.16.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2015 10:14:19 -0700 (PDT)
Received: by iecvh10 with SMTP id vh10so23333794iec.3 for <>; Mon, 22 Jun 2015 10:14:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id wc18mr27160360icb.24.1434993258622; Mon, 22 Jun 2015 10:14:18 -0700 (PDT)
Received: by with HTTP; Mon, 22 Jun 2015 10:14:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 22 Jun 2015 13:14:18 -0400
Message-ID: <>
From: Roman Shpount <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary="bcaec519611b6f7ad505191e6785"
Archived-At: <>
Cc: "" <>, Christer Holmberg <>
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jun 2015 17:14:23 -0000


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
Roman Shpount

On Mon, Jun 22, 2015 at 9:32 AM, Paul Kyzivat <> 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.