W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: API points for ICE/DTLS warmup

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 28 Jul 2015 05:47:14 +0000
To: Peter Thatcher <pthatcher@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B34208413@ESESSMB209.ericsson.se>
On 27/07/15 20:51, Peter Thatcher wrote:
>
>
> On Mon, Jul 27, 2015 at 11:39 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     On 27/07/15 18:26, Peter Thatcher wrote:
>     >
>     >
>     > On Mon, Jul 27, 2015 at 2:33 AM, Stefan Håkansson LK
>      > <stefan.lk.hakansson@ericsson.com
>     <mailto:stefan.lk.hakansson@ericsson.com>
>      > <mailto:stefan.lk.hakansson@ericsson.com
>     <mailto:stefan.lk.hakansson@ericsson.com>>> wrote:
>      >
>      >     On 24/07/15 13:21, Peter Thatcher wrote:
>      >
>      >     >
>      >     > B > A, because an RtpSender without a track seems cleaner
>     than a dummy
>      >     > track. But I could live with A.
>      >     >
>      >     > D > C, because we don't have to add anything.  I think we
>     shouldn't add
>      >     > RtpReceiver.active.
>      >     >
>      >     > F > E, because we don't have to add anything.  I think that
>     even if we
>      >     > add RtpReceiver.active, it should not cause an SDP
>     renegotiation, just
>      >     > like RtpSender.setParameters doesn't.
>      >
>      >     I agree on all points.
>      >
>      >     But there are some details that needs sorting, e.g.
>      >
>      >     - Currently we have "ontrack" firing. It should not fire if
>     an empty
>      >     sender/receiver pair was created, would we need another event
>     to inform
>      >     the app at the receiving side?
>      >
>      >
>      > ​That sounds like application signalling to me.  Or the app could
>     just
>      > use the fact that it's receiving media to infer that ​the other
>     side is
>      > sending it.
>      >
>      > ​
>      >
>      >
>      >     - So far we've said that 'replace track' should not change
>     the track id
>      >     at the remote side and that no SDP exchange would be needed
>     (at least
>      >     not in most cases - Jan-Ivar has the view SDP exchanges could
>     result
>      >     from replaceTrack, we need to sort this). How should that be
>     dealt with
>      >     here? If the purpose is to "warm" the connection, ideally we
>     should not
>      >     need any SDP exchange to get the media flowing, but in this
>     case we have
>      >     no initial track id.
>      >
>      >
>      > ​The app just wants a way to know which RtpSender goes with which
>      > RtpReceiver (or which RtpSender.track goes with which
>      > RtpReceiver.track).  And the RtpSender.mid and RtpReceiver.mid
>     can serve
>      > that purpose, even with a null track.
>
>     For my understanding, your proposal is:
>
>     - The remote app is not informed via any event fired on the
>     PeerConnection as result of
>              var sender = pc.createRtpSender("audio");
>
>
> ​Actually, I think that the remote PC should fire an event.  But it's a
> good question of what event.  I can see three options:
>
> Option G.  PeerConnection​
> ​
> ​.onaddtrack, with a null track.  Very simple and consistent with the
> sending side, but will probably cause some apps to blow up when they
> don't expect a null track.
>
> ​Option H.  PeerConnection.onaddtrack, with a ​
> ​
> ​dummy track.  Not as consistent or simple, but will at least not cause
> apps to blow up if they don't expect a null track.
>
> Option I.  A new event, perhaps PeerConnection.onrtpreceiver.  Would
> come with a warning label: ".track may be null".​
>
>
> ​I'm leaning toward G, because almost all of the time, it's the same
> application on both sides.  If the sending application developer chooses
> to create an RtpSender with a null .track, it shouldn't be too surprised
> ​ when the RtpReceiver on the other end has a null .track.  And it's a
> 1-line code fix once discovered.

I don't think option G is that good, because
a) it can be made part of a MediaStream that is wired up to a video 
element (meaning it won't start playing as soon as the other end starts 
sending media)
and
b) there would be no event telling "media is actually now coming out of 
this rtpreceiver"

My preference would be

Option J: PC.onaddtrack is fired with a real track (after all we will in 
many cases not get any info about this track after this point - all info 
must come in that initial SDP - so it can just as well be created), 
however this track stays muted until there is any media coming from the 
sending side (and this can happen only after the sending app does 
sender.replaceTrack).

>
>
>
>     However, if the remote side app does
>              var receivers = pc.getReceivers();
>     the receiver would show up. But looking into the receiver,
>              receiver[x].track would return null (since no track is
>     associated).
>
>              sender.replaceTrack(trackA);
>     would also not generate any track event on the remote side (there is no
>     signaling, so nothing to trigger the event).
>
>     There would also be no way to convey any MediaStream associations (like
>     you can with pc.addTrack(X, mediastream_1, mediastream_2).
>
>
> ​That can be done via application signalling.​  And if the app can't
> handled signalling such things, it doesn't have to use the "warm up" API
> points in the first place.

I agree.

>
>
>      >
>      >
>      >
>      >
>      >
>      >      >
>      >      >
>      >      > Commence discussion :).
>      >
>      >
>
>
Received on Tuesday, 28 July 2015 05:47:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC