Re: actpass redux

2017-06-02 20:02 GMT+02:00 Roman Shpount <[email protected]>:
> There was a discussion regarding the setup attribute value in subsequent
> 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 protected]>

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