Subject: [MMUSIC] actpass redux

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Jun 2017 09:44:03 -0700

Hi folks,

RFC 5763 required (and JSEP imported) that all offers include

  a=setup:actpass

However, assuming I am reading:
  https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24

correctly, S 4.2 allows the initial offer to contain anything,
though encourages actpass:

   When an offerer sends the initial offer, the offerer MUST insert an
   SDP 'setup' attribute according to the procedures in [RFC4145], and
   one or more SDP 'fingerprint' attributes according to the procedures
   in [RFC8122].  In addition, the offerer MUST insert in the offer an
   SDP 'tls-id' attribute with a unique value.

   If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
   'passive' attribute value, the offerer MUST be prepared to receive a
   DTLS ClientHello message (if a new DTLS association is established by
   the answerer) from the answerer before the offerer receives the SDP
   answer.

For subequent offers, it also gives flexibility but points at 4145.

So...

1. Changing the behavior for initial offers seems like it presents
a serious interop risk, because previously you could depend on
the offer being actpass.

2. JSEP requires actpass for all offers, so at least it's stricter.

What was the rationale for these changes? Feel free to point me at the
mailing list discussion where that happened.

-Ekr
 Hi folks,

RFC 5763 required (and JSEP imported) that all offers include

  a=setup:actpass

However, assuming I am reading:
  https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24

correctly, S 4.2 allows the initial offer to contain anything,
though encourages actpass:

   When an offerer sends the initial offer, the offerer MUST insert an
   SDP 'setup' attribute according to the procedures in [RFC4145], and
   one or more SDP 'fingerprint' attributes according to the procedures
   in [RFC8122].  In addition, the offerer MUST insert in the offer an
   SDP 'tls-id' attribute with a unique value.

   If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
   'passive' attribute value, the offerer MUST be prepared to receive a
   DTLS ClientHello message (if a new DTLS association is established by
   the answerer) from the answerer before the offerer receives the SDP
   answer.

For subequent offers, it also gives flexibility but points at 4145.

So...

1. Changing the behavior for initial offers seems like it presents
a serious interop risk, because previously you could depend on
the offer being actpass.

2. JSEP requires actpass for all offers, so at least it's stricter.

What was the rationale for these changes? Feel free to point me at the
mailing list discussion where that happened.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Fri, 2 Jun 2017 14:02:17 -0400

Hi All,

There was a discussion regarding the setup attribute value in subsequent
offers when establishing new DTLS association is not desired. Based on that
discussion it was decided that setup value can be either currently
negotiated value or actpass. There are also UDP/DTLS without STUN NAT
traversal scenarios that only work when end point behind NAT is active. I
think sending actpass in offers is a generally safer option, but I think
SHOULD here is more appropriate then MUST.

Please note that https://tools.ietf.org/html/rfc5763#section-5 says:

The endpoint MUST use the setup attribute defined in [RFC4145]. The
endpoint that is the offerer MUST use the setup attribute value of
setup:actpass and be prepared to receive a client_hello before it receives
the answer.

This applies not only to initial but to ALL offers.

Finally, I can double check, but I am fairly sure there are current
implementation that violate this rule.

Regards,

_____________
Roman Shpount

On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 2 Jun 2017 17:16:14 -0400

Just to provide the historic background for this change. We have discussed
setup role in subsequent offers with Christer before IETF95 and decided to
remove the text that setup MUST be actpass in all the offers. This removed
this requirement from the initial offers as well (even though they weren't
discussed at that time).

Now we have three options:

1. setup can be whatever application wants in all offers (current text)
2. setup MUST be actpass in initial offer and whatever application wants in
subsequent (or, alternatively actpass or negotiated role in subsequent
offers).
3. setup MUST be actpass in all the offers (back to RFC 5763)

My top preference is that setup SHOULD be actpass in all the offers. Second
preference is 1 and hope that application will do the right thing.

>From my point of view 2 is strange, since there is no principal difference
between initial and subsequent offers, especially when 3pcc comes into
play. Any offer can end up being subsequent for one end point and initial
for another.

I also think that RFC 5763 requirement is too strong. There are
implementations which send offers without actpass so it is already
violated. There are also legitimate scenarios where sending current
role (subsequent
offers without ICE restart) or active (endpoints with basic UDP behind
NAT) makes
more sense.

Regards,

_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 2 Jun 2017 17:33:40 -0400

The scope for this discussion isn't defined. Is this just for SRTP? Or 
also for SCTP? Or also for TCP and TLS?

	Thanks,
	Paul

On 6/2/17 5:16 PM, Roman Shpount wrote:
> Just to provide the historic background for this change. We have 
> discussed setup role in subsequent offers with Christer before IETF95 
> and decided to remove the text that setup MUST be actpass in all the 
> offers. This removed this requirement from the initial offers as well 
> (even though they weren't discussed at that time).
> 
> 2. setup MUST be actpass in initial offer and whatever application wants 
> in subsequent (or, alternatively actpass or negotiated role in 
> subsequent offers).
> My top preference is that setup SHOULD be actpass in all the offers. 
> Second preference is 1 and hope that application will do the right thing.
> 
>  From my point of view 2 is strange, since there is no principal 
> difference between initial and subsequent offers, especially when 3pcc 
> comes into play. Any offer can end up being subsequent for one end point 
> and initial for another.
> 
> violated. There are also legitimate scenarios where sending current role 
> (subsequent offers without ICE restart) or active (endpoints with basic 
> UDP behind NAT) makes more sense.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi All,
> 
>     There was a discussion regarding the setup attribute value in
>     subsequent offers when establishing new DTLS association is not
>     desired. Based on that discussion it was decided that setup value
>     can be either currently negotiated value or actpass. There are also
>     UDP/DTLS without STUN NAT traversal scenarios that only work when
>     end point behind NAT is active. I think sending actpass in offers is
>     a generally safer option, but I think SHOULD here is more
>     appropriate then MUST.
> 
>     Please note that https://tools.ietf.org/html/rfc5763#section-5
>     <https://tools.ietf.org/html/rfc5763#section-5> says:
> 
>         The endpoint MUST use the setup attribute defined in [RFC4145].
>         The endpoint that is the offerer MUST use the setup attribute
>         value of setup:actpass and be prepared to receive a client_hello
>         before it receives the answer.
> 
> 
>     On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi folks,
> 
>         <https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24>
>         <https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> 
> 
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 2 Jun 2017 18:35:13 -0400

Paul,

I assume this is limited to anything which implements
draft-ietf-mmusic-dtls-sdp, which means it covers UDP/TLS/*, UDP/DTLS/* or
TDP/DTLS/* protocols such as UDP/TLS/RTP/SAVP, TCP/DTLS/RTP/SAVP,
UDP/DTLS/SCTP, TCP/DTLS/SCTP.

TCP/* and TLS/* protocols are not in scope of this discussion and they
continue to be covered by RFC 4145 as far as setup attribute is concerned.

Regards,

_____________
Roman Shpount

On Fri, Jun 2, 2017 at 5:33 PM, Paul Kyzivat <[email-masked]>
wrote:

>> discussed setup role in subsequent offers with Christer before IETF95 and
>> decided to remove the text that setup MUST be actpass in all the offers.
>> This removed this requirement from the initial offers as well (even though
>> they weren't discussed at that time).
>>
>> in subsequent (or, alternatively actpass or negotiated role in subsequent
>> offers).
>> (subsequent offers without ICE restart) or active (endpoints with basic UDP
>> behind NAT) makes more sense.
>>
>> Regards,
>>
>> _____________
>> Roman Shpount
>>
>> On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>     Hi All,
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Jun 2017 07:04:13 +0000

Hi,

For subsequent offers, draft-dtls-sdp says SHOULD-use-actpass-MAY-use-something-else.

We can apply that SHOULD to initial offers if people want to.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 02 June 2017 23:16
To: Eric Rescorla <[email-masked]>
Cc: mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] actpass redux

Just to provide the historic background for this change. We have discussed setup role in subsequent offers with Christer before IETF95 and decided to remove the text that setup MUST be actpass in all the offers. This removed this requirement from the initial offers as well (even though they weren't discussed at that time).

1. setup can be whatever application wants in all offers (current text)
2. setup MUST be actpass in initial offer and whatever application wants in subsequent (or, alternatively actpass or negotiated role in subsequent offers).
3. setup MUST be actpass in all the offers (back to RFC 5763)

My top preference is that setup SHOULD be actpass in all the offers. Second preference is 1 and hope that application will do the right thing.

From my point of view 2 is strange, since there is no principal difference between initial and subsequent offers, especially when 3pcc comes into play. Any offer can end up being subsequent for one end point and initial for another.

I also think that RFC 5763 requirement is too strong. There are implementations which send offers without actpass so it is already violated. There are also legitimate scenarios where sending current role (subsequent offers without ICE restart) or active (endpoints with basic UDP behind NAT) makes more sense.

Regards,

_____________
Roman Shpount

On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

There was a discussion regarding the setup attribute value in subsequent offers when establishing new DTLS association is not desired. Based on that discussion it was decided that setup value can be either currently negotiated value or actpass. There are also UDP/DTLS without STUN NAT traversal scenarios that only work when end point behind NAT is active. I think sending actpass in offers is a generally safer option, but I think SHOULD here is more appropriate then MUST.

The endpoint MUST use the setup attribute defined in [RFC4145]. The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer.

Finally, I can double check, but I am fairly sure there are current implementation that violate this rule.

Regards,

_____________
Roman Shpount

On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Hi folks,

  a=setup:actpass

So...

-Ekr
 Hi folks,

  a=setup:actpass

So...

-Ekr

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Jun 2017 14:30:44 +0200

On Fri, Jun 2, 2017 at 11:16 PM, Roman Shpount <[email-masked]> wrote:

> violated. There are also legitimate scenarios where sending current role (subsequent
> NAT) makes more sense.

The argument for initial versus subsequent is that subsequent never worked
properly in 5763
anyway, so even if it's a good idea to not require actpass in all cases,
relaxing the rule is
going to cause bustage for implementations which (correctly) rely on the
initial offer
being actpass. For this reason, I am not in favor of removing the MUST for
the initial
offer. I would be fine with MUST for initial and SHOULD for subsequent.

-Ekr

Regards,

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jun 2017 18:12:28 -0600

> On Jun 5, 2017, at 6:30 AM, Eric Rescorla <[email-masked]> wrote:
> 
> For this reason, I am not in favor of removing the MUST for the initial
> offer. I would be fine with MUST for initial
+1 above 

> and SHOULD for subsequent.

SHOULD seems sort of not great here in that some people will assume everything else will do actpass because it is SHOULD and no reason not to and other will assume that they don't have to implement actpass because is is actually SHOULD with a hind "but we know you won't"  - that combination will not help interop

I think I would prefer in subsequent offers to say 

MUST be actpass or the values that would not cause the roles to change. 

I'm open to it saying other things but I think this is a case where using SHOULD is not helpful

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Jun 2017 20:49:03 -0400

On Thu, Jun 8, 2017 at 8:12 PM, Cullen Jennings <[email-masked]> wrote:

> SHOULD seems sort of not great here in that some people will assume
> everything else will do actpass because it is SHOULD and no reason not to
> and other will assume that they don't have to implement actpass because is
> is actually SHOULD with a hind "but we know you won't"  - that combination
> will not help interop
>
I think what EKR is trying to say here SHOULD be actpass and MUST be
actpass or the value that would not cause the setup role change.

Also note that 3pcc might cause an offer to be treated as subsequent offer
by offerer and new offer by the answerer. If non-actpass setup roles are
allowed in subsequent offers, they will have to be handled in initial
offers as well. In that sense setup roles rules should be the same for both
initial and subsequent offers. Since there are already implementations that
do current role in subsequent offers, the cat is out of the bag. Because of
this, I think for the best interop, offerer MUST specify actpass for both
initial and subsequent offers but answerer MUST be able to handle active
and passive setup roles as well.

Regards,
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 Jun 2017 07:17:28 -0600

> On Jun 8, 2017, at 6:49 PM, Roman Shpount <[email-masked]> wrote:
> 
>  Because of this, I think for the best interop, offerer MUST specify actpass for both initial and subsequent offers but answerer MUST be able to handle active and passive setup roles as well.

that works for me

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Jun 2017 14:00:50 -0400

>>   Because of this, I think for the best interop, offerer MUST specify actpass for both initial and subsequent offers but answerer MUST be able to handle active and passive setup roles as well.

I don't understand what this accomplishes. If you must be able to accept 
anything in a received offer, then what is gained by restricting what 
can be used in an offer?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Jun 2017 14:23:27 -0400

On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <[email-masked]>
wrote:

>>>   Because of this, I think for the best interop, offerer MUST specify
>>> actpass for both initial and subsequent offers but answerer MUST be able to
>>> handle active and passive setup roles as well.
>>>
>>
>> that works for me
>>
>
> anything in a received offer, then what is gained by restricting what can
> be used in an offer?
>

This is all because of legacy interop. There are legacy end points that
send non-actpass, so end point MUST be able to accept active and passive to
interop with such legacy devices. There are also legacy end points that
only expect actass so end point MUST only send actpass to interop with such
devices.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Jun 2017 15:34:43 -0400

On 6/9/17 2:23 PM, Roman Shpount wrote:
> On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>             On Jun 8, 2017, at 6:49 PM, Roman Shpount <[email-masked]
>                Because of this, I think for the best interop, offerer
>             MUST specify actpass for both initial and subsequent offers
>             but answerer MUST be able to handle active and passive setup
>             roles as well.
> 
> 
>         that works for me
> 
> 
>     I don't understand what this accomplishes. If you must be able to
>     accept anything in a received offer, then what is gained by
>     restricting what can be used in an offer?
> 
> 
> send non-actpass, so end point MUST be able to accept active and passive 
> to interop with such legacy devices. There are also legacy end points 
> that only expect actass so end point MUST only send actpass to interop 
> with such devices.

I understand that. But if you accept that legacy interop is needed, then 
there ceases to be any reason to mandate actpass for things that conform 
to this spec. It would be different if you were proposing a path to 
deprecating and then dropping the legacy support. If that is the intent 
then it is worth saying something explicit about it.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Jun 2017 15:41:51 -0400

On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat <[email-masked]>
wrote:

> there ceases to be any reason to mandate actpass for things that conform to
> this spec. It would be different if you were proposing a path to

The situation right now is that there are implementations that send offers
with setup role set to active or passive. So, my suggestion for the
language (subject to future wordsmithing) is: End points MUST set setup
role to actpass in all offers. End points SHOULD accept setup role active
or passive in an offer if interoperability with legacy end points is
desired.

Does this work?
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Jun 2017 17:18:33 -0400

On 6/9/17 3:41 PM, Roman Shpount wrote:
> 
> On Fri, Jun 9, 2017 at 3:34 PM, Paul Kyzivat <[email-masked] 
>         On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>                      On Jun 8, 2017, at 6:49 PM, Roman Shpount
>         <[email-masked] <mailto:[email-masked]>
>                      <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>         This is all because of legacy interop. There are legacy end
>         points that send non-actpass, so end point MUST be able to
>         accept active and passive to interop with such legacy devices.
>         There are also legacy end points that only expect actass so end
>         point MUST only send actpass to interop with such devices.
> 
> 
>     I understand that. But if you accept that legacy interop is needed,
>     then there ceases to be any reason to mandate actpass for things
>     that conform to this spec. It would be different if you were
>     proposing a path to deprecating and then dropping the legacy
>     support. If that is the intent then it is worth saying something
>     explicit about it.
> 
> 
> The situation right now is that there are implementations that send 
> offers with setup role set to active or passive.

Why is that a problem?

> So, my suggestion for 
> the language (subject to future wordsmithing) is: End points MUST set 
> setup role to actpass in all offers. End points SHOULD accept setup role 
> active or passive in an offer if interoperability with legacy end points 
> is desired.

So is it your intent to make implementation of support for responding to 
a non-actpass offer OPTIONAL? This encourages implementations to decide 
to not support legacy interop. IMO this is a bad idea because it is 
rarely possible to ensure that it won't eventually be required.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Jun 2017 17:48:48 -0400

>> offers with setup role set to active or passive.

If we simply specify that offers MUST contain setup role set to actpass,
implementation would legitimately respond to anything with setup role set
to active or passive with an error. We want to avoid this since there are
existing end points that send active or passive in offers.

There are also legacy end points that will only accept actpass. New end
points MUST set setup role to actpass to work with them.

Finally, setup role MUST be actpass since this allows answering party to
determine the setup role. Answering end points typically should be active,
since this reduces the call setup time. There is an exception to this for
ICE-lite or symmetric UDP, where end points on public IP typically should
be passive even when they are answering, since it will require the end
point behind NAT to send the first packet to open the NAT pin-hole.

> So, my suggestion for the language (subject to future wordsmithing) is:
>> End points MUST set setup role to actpass in all offers. End points SHOULD
>> accept setup role active or passive in an offer if interoperability with
>> legacy end points is desired.
>>
>
> So is it your intent to make implementation of support for responding to a
> non-actpass offer OPTIONAL? This encourages implementations to decide to
> not support legacy interop. IMO this is a bad idea because it is rarely
> possible to ensure that it won't eventually be required.
>

You just said that we need to add language about phasing out support for
offers with active or passive. We can phase out handling of active and
passive setup roles when they are no longer used by existing
implementations. This is why it is a SHOULD. We can make handling active
and passive offers permanent and put it under a MUST.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Jun 2017 10:34:34 +0100

On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <[email-masked]> wrote:

> interop with such legacy devices.
>

Those legacy endpoints are clearly noncomformant, so I'm not sure I care
about breaking them,

> There are also legacy end points that only expect actass so end point MUST
> only send actpass to interop with such devices.
>

These legacy endpoints are conformant, which is why it's important to
accommodate them

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Jun 2017 07:33:35 +0000

Hi,

First, one of the reasons we update specs is because there are usages etc, that people weren’t aware of when the original spec was published, that we think we need to cover. So, rather than just saying that we don’t care about non-comformant endpoints, we should ask WHY they are non-comformant. Is there a specific use-case behind? If so, do we need to cover that use-case?

Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp is GENERIC - one of the main reasons we do the spec in the first place is to have the DTLS-related O/A procedures in one place. And, RFC 7345 (UDPTL-DTLS) DOES allow non-actpass values in the offer:

        "The offerer SHOULD assign the SDP "setup" attribute with a value of
        "actpass", unless the offerer insists on being either the sender or
        receiver of the DTLS ClientHello message,"

draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and by mandating actpass we would remove a valid option for UDPTL-DTLS. Sure, we can do that, but it cannot be based on a claim that existing endpoints are non-comformant.

And, I do NOT think we want to allow non-actpass for some usages (e.g., UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because that would go against the purpose of having generic DTLS O/A procedures.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Saturday 10 June 2017 at 12:34
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] actpass redux

On Fri, Jun 9, 2017 at 7:23 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Jun 9, 2017 at 2:00 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 6/9/17 9:17 AM, Cullen Jennings wrote:

On Jun 8, 2017, at 6:49 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

that works for me

I don't understand what this accomplishes. If you must be able to accept anything in a received offer, then what is gained by restricting what can be used in an offer?

This is all because of legacy interop. There are legacy end points that send non-actpass, so end point MUST be able to accept active and passive to interop with such legacy devices.

Those legacy endpoints are clearly noncomformant, so I'm not sure I care about breaking them,

There are also legacy end points that only expect actass so end point MUST only send actpass to interop with such devices.

These legacy endpoints are conformant, which is why it's important to accommodate them

-Ekr

_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Jun 2017 10:57:56 +0100

On Mon, Jun 12, 2017 at 8:33 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> First, one of the reasons we update specs is because there are usages etc,
> that people weren’t aware of when the original spec was published, that we
> think we need to cover. So, rather than just saying that we don’t care
> about non-comformant endpoints, we should ask WHY they are non-comformant.
> Is there a specific use-case behind? If so, do we need to cover that
> use-case?
>

Yes, and one of the things we have to keep in mind is not breaking
conformant endpoints.

Second, keep in mind that while RFC 5763 is for DTLS-SRTP, draft-dtls-sdp
> is GENERIC - one of the main reasons we do the spec in the first place is
> to have the DTLS-related O/A procedures in one place. And, RFC 7345
> (UDPTL-DTLS) DOES allow non-actpass values in the offer:
>
> draft-dtls-sdp replaces that text with a reference to draft-dtls-sdp, and
> by mandating actpass we would remove a valid option for UDPTL-DTLS. Sure,
> we can do that, but it cannot be based on a claim that existing endpoints
> are non-comformant.
>
> And, I do NOT think we want to allow non-actpass for some usages (e.g.,
> UDPTL-DTLS), and forbid it for other usages (e.g., DTLS-SRTP), because that
> would go against the purpose of having generic DTLS O/A procedures.
>

Well, given that we apparently have incompatible existing RFCs, I'm not
sure I see any
alternative.

-Ekr

> Regards,
>
> Christer
>
>
> From: mmusic <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> To: Roman Shpount <[email-masked]>
> Cc: Paul Kyzivat <[email-masked]>, "[email-masked]" <
> [email-masked]>
>> There are also legacy end points that only expect actass so end point
>> MUST only send actpass to interop with such devices.
>>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Jun 2017 11:25:55 +0000

Hi,

Yes, and one of the things we have to keep in mind is not breaking conformant endpoints.

"Be conservative in what you send, be liberal in what you accept”

As far as I understand, we would still mandate endpoints to support receiving non-actpass values.

Well, given that we apparently have incompatible existing RFCs, I'm not sure I see any alternative.

I object to that – we basically would have to update the spec every time there is a new data type, or define the type-specific O/A procedures in a separate spec – which is what has been previously been done.

I think our aim should be to have generic procedures, even if that means we have to change procedures some existing RFCs.

Regards,

Christer

that works for me

-Ekr

_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Jun 2017 13:32:33 +0100

On Mon, Jun 12, 2017 at 12:25 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>> First, one of the reasons we update specs is because there are usages
>> etc, that people weren’t aware of when the original spec was published,
>> that we think we need to cover. So, rather than just saying that we don’t
>> care about non-comformant endpoints, we should ask WHY they are
>> non-comformant. Is there a specific use-case behind? If so, do we need to
>> cover that use-case?
>>
>
> *"Be conservative in what you send, be liberal in what you accept”*
>

https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/

As far as I understand, we would still mandate endpoints to support
> receiving non-actpass values.
>

I don't believe that 5763-conformant endpoints are in fact required to do
so, and
therefore it's not appropriate to break them by allowing people to send
actpass
in initial offers when offering DTLS-SRTP.

-Ekr

> sure I see any alternative.
>
> I object to that – we basically would have to update the spec every time
> there is a new data type, or define the type-specific O/A procedures in a
> separate spec – which is what has been previously been done.
>
> I think our aim should be to have generic procedures, even if that means
> we have to change procedures some existing RFCs.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Jun 2017 13:18:15 +0000

Hi,

Expired :)

I don't believe that 5763-conformant endpoints are in fact required to do so, and
therefore it's not appropriate to break them by allowing people to send actpass
in initial offers when offering DTLS-SRTP.

I assume you mean non-actpass?

But, my point was that, AFAIK, the suggestion has been to say that endpoints must send actpass, but must support receiving non-actpass. Am I wrong?

Regards,

Christer

that works for me

-Ekr

_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Jun 2017 14:29:53 +0100

> https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/

Bug fixed.  Thanks for the reminder.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 13 Jun 2017 19:08:28 +0200

2017-06-02 20:02 GMT+02:00 Roman Shpount <[email-masked]>:
> offers when establishing new DTLS association is not desired

Hi, I've silently read all this thread. In fact I already participated
in this exact subject in some threads in the past (so long ago). But
it seems that problems in SDP persist forever.

I think it's time to expel SDP from our lives, specially in WebRTC
where we, the developers, can do media signaling much better than the
SDP-way.

All this kinds of problems are because a full SDP blob must be
generated and consumed by the remote party for *every* minor change in
the multimedia session. So, if I want to add a video stream on top of
the same ICE+DTLS transport, or if I want to pause it, or remove it,
or whatever, I must send a full SDP and the remote peer must figure
out whether such a SDP involves a ICE change, DTLS change, streams
change, codecs change, etc etc. This means a "full re-inspection" of
all the parameters (ICE, DTLS, RTP, RTCP, etc) for every SDP O/A
renegotiation.

When SDP was about simple bidirectional audio it was just fine. But
nowadays SDP is unsustainable.

Now we have a draft that defines a new a=tls-id attribute to avoid
DTLS re-handshake on a SDP O/A renegotiation. That's a hack IMHO. We
may also invent a new a=ice-id to avoid inspecting remote ICE
ufrag/passwd/candidates every time a multimedia session change is
desired. And also a=m-id attribute (per media section) so the receiver
figures out whether something has changed in such a media section or
not, etc. Ah, and we have BUNDLE so the "transport" is just defined in
the first media section (or the first *active* one, who knows?).

1) Transport => UDP or TCP or ICE
2) Security => DTLS or SRTP
3) Media => Parameters for independent send/recv media streams

That's all we need, nothing else: a clear layers separation so we can
signal each layer parameters independently. Yes, that's similar to
what ORTC provides, which is far from perfect, but it becomes much
more comfortable to work with.

IMHO it's really sad that WebRTC 1.0 has been polluted with this
legacy "media signaling" mechanism. WebRTC was born so many years ago
and, in 2017 with spec 1.0.0 about to be released, we still have spec
and implementation problems when it comes to "renegotiate" something
in the session because the remote may attempt a new DTLS handshake...
just LoL.

I do know that my complain is slightly off-topic given that this is
MMUSIC, which is supposed to be 100% SDP related. But I wonder why the
MMUSIC WG is still 100% tiled to SDP rather than just defining
multimedia related parameters as it should (IMHO). The longer this WG
defines multimedia stuff for just SDP, the longer the developers will
suffer the SDP re-negotiation and its inherited "full re-inspection".

I'm sorry for this email, but I just can not bear to see so many
bright minds wasting so much time due to a single SDP line whose value
may have to be different on each re-O/A (depending on who the
re-offerer is) to just keep the underlying transport untouched
("actpass ==> active", "passive <== actpass"). Having to change things
to change nothing seems surrealist.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Jun 2017 18:23:02 +0000

Hi,

I don't necessarily disagree with you, and I don't know if your e-mail is off-topic for MMUSIC, but it for sure IS off-topic for THIS thread, and the draft/charter item discussed :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jun 2017 16:33:54 -0400

Iñaki,

[Changing the subject, since it was *very* off-topic.]

I've added my comments at the end.

> suffer the SDP re-negotiation and its inherited "full re-inspection".

Everybody who has worked with SDP realizes that it is ill-suited to the 
tasks we use it for. Quite a long time ago there was an effort called 
SDPng that tried to define a new syntax. I wasn't involved in that, but 
it seemed like it was defining something reasonable (XML based IIRC). 
But it failed because (IIUC) nobody could see a viable migration plan to 
introduce it.

I think you are suggesting to do something new but limit its scope to 
WebRTC. Such a narrow scope would ease the migration effort. There would 
still be one but perhaps people would be willing to suffer through it.

BUT, WebRTC doesn't stand alone. Interworking with SIP is still 
important, and probably will be for a long time. Also, your description 
of what is needed is simplistic. What features (functionality, not 
syntax) of SDP O/A are not needed with WebRTC? AFAICT all the stuff that 
describes codecs is needed, and much of the rest. There is a lot of 
that, spread over many RFCs. All of that would have to be re-done.

Doing something new here may well be the right thing to do. But the 
first step is to carefully define the scope of applicability, and what 
interworking requirements there are with things outside that scope. Then 
perhaps the size of the effort can be estimated and the feasibility 
doing so assessed.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 13 Jun 2017 23:17:43 +0200

> I don't necessarily disagree with you, and I don't know if your e-mail is off-topic for MMUSIC, but it for sure IS off-topic for THIS thread, and the draft/charter item discussed :)

Hi Christer,

Probably you are right, and sorry for that. Being honest, I started
writing a very different email exposing my experience with the issue
being discussed in the thread. It said something as follows:

I've seen the "SDP DTLS role conflict" in many implementations. AFAIR
older versions of Firefox and Asterisk wrote, in a re-offer, an
a=setup attribute with the effective value (active or passive) as
negotiated during the initial O/A, which breaks the RFC because it
MUST be "actpass", so Chrome complained. I've also seen (and reported)
that FreeSwitch changes its DTLS a=setup role during a re-negotiation,
but the funny thing here is that it was just a cosmetic change in the
SDP (internally FreeSwitch wants to keep the initially negotiated DTLS
connection regardless what it actually writes in the re-offer):

https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-10258/FS-10258.html

But after writing it, I've realized that if it's so complex for
existing implementations to deal with this specification rule (still
in 2017) changing the spec or creating a new one won't help much (at
least in the short term), so I got really frustrated and ended sending
my original text.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 13 Jun 2017 23:45:49 +0200

2017-06-13 22:33 GMT+02:00 Paul Kyzivat <[email-masked]>:
> tasks we use it for. Quite a long time ago there was an effort called SDPng
> that tried to define a new syntax. I wasn't involved in that, but it seemed
> like it was defining something reasonable (XML based IIRC). But it failed
> because (IIUC) nobody could see a viable migration plan to introduce it.
>
> BUT, WebRTC doesn't stand alone. Interworking with SIP is still important,
> and probably will be for a long time. Also, your description of what is
> needed is simplistic. What features (functionality, not syntax) of SDP O/A
> are not needed with WebRTC? AFAICT all the stuff that describes codecs is
> needed, and much of the rest. There is a lot of that, spread over many RFCs.
> All of that would have to be re-done.
>
> Doing something new here may well be the right thing to do. But the first
> step is to carefully define the scope of applicability, and what
> perhaps the size of the effort can be estimated and the feasibility doing so
> assessed.

Hi Paul,

I'm not asking for a SDP 2.0 in JSON/XML or any other format. In your
text above, you state that "all the stuff that describes codecs is
needed, and much of the rest", and I don't agree with that:

ORTC has proven to provide the *same* functionality as SDP, but
without imposing the exchange of a full SDP blob/string. Yes, codec
parameters must be exchanged between peers, but that does not mean
that a SDP (or similar format) is required. Instead, in ORTC, it's up
to the application/developer to decide how to signal parameters
between the endpoints of a multimedia session. In ORTC an endpoint can
signal ICE parameters, DTLS parameters, RTP parameters, and other
parameters in an independent way (so, if for example a new video
stream is added, there is no need to signal all the ICE/DTLS stuff to
the remote party again, but just the RTP parameters related to the new
stream). This design prevents issues such as the "SDP DTLS role
conflict" described in the previous email thread.

You say "There is a lot of that, spread over many RFCs".

And that's true, but ORTC specification [*] collects many of those
parameters and re-uses them within their own Dictionaries about ICE,
DTLS, RTP, RTCP, etc. It's true that there are tons of RFC's that
define multimedia parameters assuming SDP syntax, but IMHO the SDP-ish
is just a minor component in those specifications, nothing too hard to
circumvent IHMO (in fact, ORTC did it).

>  I think you are suggesting to do something new but limit its scope to WebRTC

Not exactly. Continue reading, please.

> WebRTC doesn't stand alone. Interworking with SIP is still important

Sure, and I understand that SIP indeed requires a wire-signaling
format/syntax because SIP requires interoperability between different
devices in both, the signaling and media, planes. But IMHO that does
not justify the fact that all the multimedia related specifications
are tiled to just SDP. SDP should not be the minimum irreducible unit
for exchanging multimedia information, and ORTC is a good example of
the opposite.

What I would expect nowadays from the MMUSIC WG is to define
multimedia parameters (including different *layers" such as transport,
security/encryption, RTP, RTCP, etc) rather than a single format(SDP)
to cover them all. Having that, WebRTC could perfectly drop SDP and
define some proper Dictionaries (as ORTC) pointing to those parameters
defined by MMUSIC so WebRTC developers are done and free to exchange
data as they wish. And when it comes to SIP, of course the SIP
protocol needs a "multimedia format". A separate WG or a different
task within MMUSIC could be responsible of producing an standardized
"multimedia format" for SIP with those parameters, let it be SDP or
SDP 2.0.

Anyhow, if so many things within the SDP are so problematic for
WebRTC, they will also be problematic for SIP (once SIP devices
implement so many advanced features such as those in WebRTC devices),
so still I consider that sending a full SDP to just renegotiate a new
codec (or remove a specific video stream) will produce real problems
as we suffer in WebRTC. But again, this is a separate concern that
should just affect to SIP devices (because SIP chose to go with SDP),
and not to WebRTC.

Thanks a lot for your response, regards.

[*] http://draft.ortc.org/

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Jun 2017 16:32:42 -0700

First, let me apologize for contributing to this thread.

Just as my wife has counseled me to limit my viewing of TV news programming
to under 10 minutes a day (since more than this seems to lead to ranting
and foaming at the mouth), so too would it be in my best interest not to
contribute to this thread.

However, although I will try to keep this response brief, I simply cannot
resist.  In my defense, since it is now June, this is at least one new
year's resolution that I have kept for half a year, rather than the
customary three weeks.   And yes, I listened to Jim Comey's testimony last
week and Jeff Session's today, both for more than 10 minutes.

I will however, attempt to heed Tim Cook's recent advice to MIT graduates
(see:
https://www.washingtonpost.com/national/higher-education/apple-ceo-tim-cook-to-address-2017-graduates-at-mit/2017/06/09/ee763ac8-4ccb-11e7-987c-42ab5745db2e_story.html?utm_term=.676972454c80
)

"Don't listen to trolls, and don't become one."

Overall, my observation is that applications utilizing the RTCWEB protocol
stack that require interoperability with other SIP implementations tend to
utilize an "SDP adapter" (along the lines of adapter.js) that functions
much like an "in-application SBC", so as to ensure SDP interoperability.
However, those applications only requiring interoperability with versions
of the same application running on other platforms (e.g. an application
building on iOS, Android, Mac OS X and UWP) generally do not need an SDP
adapter.  Sometimes this is because they utilize JSON signaling and
therefore do not use SIP/SDP signaling at all, and sometimes it is because
their builds on all platforms utilize the same SDP dialect (typically the
dialect utilized in the webrtc.org implementation).

Within each of the categories described above, there are applications
written to a native WebRTC 1.0 API, applications written to a "shimmed"
WebRTC 1.0 API running over ORTC, and ORTC native applications.  This is
because ORTC is not so much an API as a "micro-kernel" approach to realtime
communications.

That is, just as one can use a micro-kernel to support multiple upper layer
sub-systems (e.g. Posix, Win32, etc.), using ORTC it is possible to support
multiple signaling approaches (e.g. SIP, H.323, JSON, etc.) on top of the
same core media library.

This is perhaps demonstrated most clearly in the ORTC Lib implementation
(see https://github.com/ortclib), which provides both access to ORTC as
well as the WebRTC 1.0 API, and could, I believe be used to provide support
for H.323, although so far noone has contributed an implementation of that.

However, while I have seen many different applications utilizing the RTCWEB
protocol stack with different interoperability requirements, one thing I
have not so far encountered is an a situation where there has been a need
for standardizing a non-SDP signaling mechanism.

If you are developing a basic realtime application that needs to provide
interoperable A/V with a different realtime application (either on the same
platform, or a different one), so far my experience has been that SIP/SDP
works well enough.  And where it doesn't work well enough (such as in
advanced video conferencing scenarios involving multi-stream, simulcast,
SVC, VR/AR, etc.) the odds are that interoperability between distinct
applications is not required, in which case a non-SIP/SDP signaling
approach can be utilized.

So with respect to the need to standardize a non-SDP signaling mechanism,
my view is "Don't bother, be happy."

Gotta go.  My 10 minutes are up.

On Tue, Jun 13, 2017 at 2:45 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> SDPng
> important,
> doing so
> WebRTC

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 13 Jun 2017 20:10:30 -0400

In my experience, there are a number of things that are universally
agreed to be "the wrong tool for every job".  The classical subject for
that observation is vise grips -- and every toolbox contains a pair.  In
software, it's the language Perl -- and every system has a bunch of Perl
scripts that do vital tasks.  And in media protocols, it's SDP -- and
any interoperable system can send and receive SDP.  It seems that
everyone who has dealt with SDP in the last ten years rants that SDP is
horrible, and works on systems that use SDP.

The problem with all of these tools is that they *work*, they can be
used to do whatever is needed at the moment, in a way that is adequate
for the users' needs, in environments where it is quite difficult to do
that.

It may be possible to transition a large section of real-time media away
from SDP.  But the way to argue for that is to present the outline of a
technical replacement, and a roadmap for implementing it in the overall
ecosystem -- including the strategy for interoperating with systems that
use SDP.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Jun 2017 12:40:52 +0200

2017-06-14 1:32 GMT+02:00 Bernard Aboba <[email-masked]>:
> sometimes it is because their builds on all platforms utilize the same SDP dialect (typically the dialect utilized in the webrtc.org implementation).
> [...]
> one thing I have not so far encountered is an a situation where there has
> been a need for standardizing a non-SDP signaling mechanism.

Just an observation about this: at least in WebRTC land, one cannot
just decide whether to use SDP or not, he just needs to use it (the
browser generates SDP blobs and consumes SDP blobs) but the fact is
that, in complex scenarios others than P2P audio/video calls (for
example SFUs), current vendors are doing very funny things that makes
me worry about how the adoption of SDP in WebRTC is:

I've seen that some SFU vendors (and their corresponding client's
logic) just use SDP for the initial "connection" between clients and
the SFU server. Usually there is just a single in-the-wire SDP O/A in
which ICE and DTLS parameters are exchanged, so the transport is
established. Some vendors also include some hardcoded m= sections with
various hardcoded SSRCs for audio and video which don't represent a
real remote audio/video, but a future one. Then, when a real
participant joins the same conference, the SFU signals it out-of-band
to all the others, and rewrite RTP packets (SSRC, PT, etc) from the
new participant to satisfy one of the already hardcoded SSRC values in
the already negotiated SDP O/A. When a participant leaves, or pauses
his video, etc, that's not signaled via the SDP mechanism but
out-of-band. Some other SFUs scenarios send out-of-band info to
participants and those locally mangle the remote SDP (for example, to
include a new SSRC or m= section) but there is no a real SDP exchange
from endpoint to endpoint.

So, IMHO this clearly shows the "hardcoded" way in which current
complex WebRTC scenarios make use of the SDP mechanism to make the
browser's SDP engine happy while still avoiding SDP renegotiation and
SDP signaling features as much as possible. Said in other words:
people try to avoid SDP and its semantics as much as possible.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Jun 2017 12:44:20 +0200

2017-06-14 2:10 GMT+02:00 Dale R. Worley <[email-masked]>:
> technical replacement

As said in a previous comments, there is no need for a SDP
replacement. Nobody is asking for SDP 2.0 but, instead, "define the
multimedia parameters and let me signal them in my preferred way".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Jun 2017 11:05:32 +0000

Hi,

>multimedia parameters and let me signal them in my preferred way".

Well, in order to have interoperability, people need to have a common
preferred way. That¹s why we do standardisation.
 
In WebRTC, if people download the same web site, they will automatically
get the same parameter signalling mechanism, no matter whether it¹s
standardised or not. But, if people download different web each may come
with different mechanisms, in which case they won¹t interop.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Jun 2017 11:06:22 +0000

…and, just to clarify: I do NOT suggest SDP 2.0 :)

On 14/06/17 14:05, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Jun 2017 13:08:45 +0200

> preferred way. That¹s why we do standardisation.

And that's why SDP already exists. But that does not mean that we need
that WebRTC is SDP based.

> with different mechanisms, in which case they won¹t interop.

Sure, but I'm talking about that. I just focus on the communication
between the JS application and the browser's WebRTC engine, which is
made via JS API by exchanging SDP blobs.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Jun 2017 11:20:52 +0000

Hi,

>that WebRTC is SDP based.

Well, THAT discussion IS off-topic for MMUSIC :)

The choice to use SDP was done by RTCWEB, wasn’t it?

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Jun 2017 13:25:22 +0200

> The choice to use SDP was done by RTCWEB, wasn’t it?

Right. However, the problem I see is that the only WG defining
multimedia parameters is MMUSIC, and it defines those within the SDP
context, making it hard to enable any other approach than SDP.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jun 2017 11:14:18 -0400

> context, making it hard to enable any other approach than SDP.

Well, there has to be *some* agreed upon means for defining these 
parameters. SDP is being used because that is what there is, even though 
it is far from ideal. Certainly something else could be used, but then 
that needs to be defined. I guess you are arguing that this partition 
the definition, separating semantics from syntax. While that is 
certainly possible, it probably won't make the job simpler.

What is needed is a concrete proposal.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Jun 2017 17:18:06 +0200

2017-06-14 17:14 GMT+02:00 Paul Kyzivat <[email-masked]>:
> I guess you are arguing that this partition the definition, separating
> semantics from syntax.

Yes.

> What is needed is a concrete proposal.

Agreed.

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>