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: Mon, 27 Jul 2015 18:39:50 +0000
To: Peter Thatcher <pthatcher@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B34208134@ESESSMB209.ericsson.se>
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

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