Re: API points for ICE/DTLS warmup

On Mon, Jul 27, 2015 at 11:39 AM, Stefan Håkansson LK <
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>> 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.



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



>
> >
> >
> >
> >
> >
> >      >
> >      >
> >      > Commence discussion :).
> >
> >
>
>