Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]

Christer Holmberg <> Mon, 10 April 2017 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23812129AC4; Mon, 10 Apr 2017 12:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4-HWEEm7biEk; Mon, 10 Apr 2017 12:31:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7200129A9C; Mon, 10 Apr 2017 12:31:36 -0700 (PDT)
X-AuditID: c1b4fb3a-baef298000005492-60-58ebdd968c2a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 3A.3D.21650.69DDBE85; Mon, 10 Apr 2017 21:31:34 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:31:32 +0200
From: Christer Holmberg <>
To: Roman Shpount <>
CC: "mmusic (E-mail)" <>, "" <>, Ben Campbell <>
Thread-Topic: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]
Thread-Index: AdKyNUrA9tbRCyqiRcKnD0Le75fq9gAATjfw///QToD//8rxoA==
Date: Mon, 10 Apr 2017 19:32:05 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E275ESESSMB102erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7ve60u68jDM5cs7aY33ma3eL8zvVM FlOXP2axmHFhKrMDi8eSJT+ZPGbtfMLicWtKQQBzFJdNSmpOZllqkb5dAlfG6Um7mAqeXGKs uL9zIlsD45yzjF2MnBwSAiYSO3qfsHUxcnEICaxnlHi0eh47hLOEUaJhRRdQhoODTcBCovuf NkiDiICqxN/vk5lAbGaBGokP7Z1sILawQIxEx/KHzBA1sRJ75y9mgbCdJBasOgRmswD1Tru0 B2wxr4CvxKbXS8DiQgI3GCWW3c8GsTkFAiWm39/JDmIzCohJfD+1BmqXuMStJ/OZII4WkFiy 5zwzhC0q8fLxP1YIW0lixfZLjCAnMwvkS2zamwixSlDi5MwnLBMYRWYhmTQLoWoWkiqIsKbE +l36ENWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGHEH t/y22sF48LnjIUYBDkYlHt4H/a8jhFgTy4orcw8xSnAwK4nwXu0ACvGmJFZWpRblxxeV5qQW H2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cDYmrVWbZFR76Kk5JqXhaWLbyj+DXF0 0/t45Y7xucqFGXV7fuYbHBC/P4W1zfr1Ak/Fl813tjj+Prgl7/TVH8ITnxbUdsqFvhLZk2Ai uOmymoHFRaGHGvn3Li/1uPG3zfSF6TrLO508b1ov8phJ3J/9z/xFf0fsqmcW1rfrzz1Mi+Tw L90QldulxFKckWioxVxUnAgAmZQG0bQCAAA=
Archived-At: <>
Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added]
X-Mailman-Version: 2.1.22
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, 10 Apr 2017 19:31:40 -0000


>A think for all the normal cases m=connection attribute must be specified when >TLS is used. There is no way to know if remote party supports tls-id when offer >is sent, so if m=connection is not specified, then it is unclear how the offer is >going to be processed.

I was thinking more about subsequent offers and answers, when it is known whether both endpoints support tls-id.

But, I am fine to keep using the connection attribute also in that case, together with tls-id. So, if the connection attribute is not present, is shall be interpreted as ‘new’, according to RFC 4145.



On Mon, Apr 10, 2017 at 3:10 PM, Christer Holmberg <<>> wrote:
And XXX stands for section 5.1 :)

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <<>>; mmusic (E-mail) <<>>
Cc:<>; Ben Campbell <<>>
Subject: SDP connection attribute optional [was: DTLS-SDP: TLS support added]


Section XXX of RFC 4145 says:

   “When an offerer generates an 'm' line that uses TCP, it SHOULD provide a
   connection attribute for the 'm' line unless the application using
   the 'm' line has other means to deal with connection reestablishment.”

Now, if both endpoints support the ‘tls-id’ attribute, that would be “other means”.

However, section of RFC 4145 says:

   “The default value of the connection attribute in both offers and

   answers is 'new'.”

So, I think we need to say something. Either:

1)      If both endpoints support tls-id, they don’t need to care about the connection attribute (or the default value in case the attribute is not present); OR

2)      We mandate that the connection attribute is present, with an ‘existing’ value, whenever an existing connection is to be maintained.

Option 2) seems most safe, i.e., we continue using the ‘connection’ attribute and its semantics even if both endpoints support the ‘tls-id’ attribute.




From: mmusic [] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <<>>
Cc:<>; Ben Campbell <<>>
Subject: [MMUSIC] DTLS-SDP: TLS support added


Based on the decision in Chicago to allow usage of the SDP ‘dtls-id’ attribute also for TLS connections, I have created a pull request:

Note that the name of the attribute has now been changed to ‘tls-id’.

The approach I’ve taken is: rather than talking about both DTLS and TLS throughout the document, I’ve basically added a section describing the TLS-specific considerations – mainly regarding the interaction with the SDP ‘connection’ attribute.

Now, I think we do need some text on WHY we also cover TLS connections since, as far as creating new connections is concerned, the ‘connection’ attribute can be used. We know that it would be needed for draft-thomson-avtcore-sdp-uks ( But, AFAIK that work has not been adopted yet, so I don’t think we can use it as justification at this point?

Note that this pull request does NOT include any of the changes to be done based on the gen-art/sec-dir reviews. I have updated the 4572-update reference, though.



mmusic mailing list<>