Re: API points for ICE/DTLS warmup

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


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