Re: API points for ICE/DTLS warmup

On Mon, Jul 27, 2015 at 10:47 PM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> 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).
>

​So, have a real track come out of the receive side, even if there is a
null track​ on the send side.  I like that.  I think it makes sense.  In
fact, I don't think we need to have it muted when it comes out.  I think we
can just have it appear as a normal track.



>
> >
> >
> >
> >     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 :).
> >      >
> >      >
> >
> >
>
>