Re: API points for ICE/DTLS warmup

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");

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

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

Received on Monday, 27 July 2015 18:40:18 UTC