- From: Roman Shpount via GitHub <sysbot+gh@w3.org>
- Date: Mon, 03 Apr 2017 17:07:03 +0000
- To: public-webrtc-logs@w3.org
I see 3 cases here: 1. Two full ICE end points communicating -- this issue is impossible since answering end point will not send ServerHello until it runs the connectivity check, which cannot complete before answer SDP with ICE ufrag and fingerprints is received 2. ICE-lite end point sends an offer to the the full ICE WebRTC end point. WebRTC end point runs the ICE connectivity check and sends ClientHello. ICE-lite end point can receive ClientHello, send back ServerHello and establish DTLS association before the answer is received from WebRTC end point. This means ICE-lite (non-webrtc end poing) can receive data before it receives answer SDP and fingerprints. I think the right solution here is for ICE-lite end point cache ClientHello but not to send ServerHello until the answer is received. This will prevent DTLS association from being established before fingerprints are received. 3. Infamous 1-800 FedEx problem. This has nothing to do with the question, but does create the real problem. Imagine SBC which is a full ICE/DTLS end point on one side communicating with WebRTC end points and SIP/AVP (no DTLS or ICE) on the other side. Imagine then, that WebRTC end point sends an offer to SBC. SBC strips ICE and DTLS information from that offer and sends it to SIP. SIP end point immediately starts sending data to SBC before even sending the answer. SBC did not receive the answer from the SIP end point and did not send the answer to WebRTC end point. There is no ICE session or DTLS association established between the WebRTC end point and SBC, but SBC is receiving data. The question is what to do with this data? Right now the only options are: a: discard b: establish media session between SBC and WebRTC end point before sending the offer to SIP and run transcoding during the early media session. Once session is fully establish do a 3pcc session update to remove transcoding. I believe problem 3 cannot be fixed until ortc/webrtc 2.0 is ready. In either of those cases I do not see how media can flow to webrtc end point before fingerprints are available. _____________ Roman Shpount On Mon, Apr 3, 2017 at 12:07 PM, adamroach <notifications@github.com> wrote: > On their face, @pthatcherg <https://github.com/pthatcherg>'s assertions > appear to be true. Can someone who thinks this can happen draw a ladder > diagram demonstrating how the situation under discussion arises? @fluffy > <https://github.com/fluffy>? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291190245>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AEh5SutuXNrJOR4WnGkpUIJOOrEBlZW3ks5rsRkogaJpZM4L-hgv> > . > -- GitHub Notification of comment by rshpount Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291207802 using your GitHub account
Received on Monday, 3 April 2017 17:07:09 UTC