Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Makaraju, Maridi
> Raju (Raju)
> Sent: Tuesday, June 03, 2014 10:46 PM
> To: Iñaki Baz Castillo
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?
> 
> 
> > All the above can be summarized as: "RFC 5245 mandates a new SDP O/A
> > if the selected candidate-pair does not match the address in the c/m
> > lines".
> > Well, I already know that, it is written in the RFC. The point is that
> > the above is useless and a requirement that should not be added by a
> > network protocol that defines a STUN usage.
> 
> [Raju] Correct. I think we are on the same page. As we discussed earlier, what
> applies to WebRTC is for the browser to update the SDP and notify the
> application of these events. Then it is up to the application to handle them
> anyway it wants.
> 
> > > This is also obvious from that fact that new local candidates for
> > > the
> > access network must be conveyed to the peer so that ICE connectivity
> > checks start and succeed.
> >
> > Not so obvious. If the mobile is talking to a peer which has public IP
> > (and peer is a full or lite ICE implementation) then a new SDP O/A is
> 
> [Raju] Implementation MUST not assume peer having a public IP.
> 
> > useless. At the end, and regardless what the initial SDP Offer said,
> > the peer will discover the new reflexive candidates from the mobile
> > "on-the-fly" (as the ICE protocol states).
> 
> [Raju] I don't think peer discovering new reflexive candidates can happen after
> ICE is completed. First, without ICE restart the mobile which detected a new
> local candidate (WiFi) can't send ICE connectivity checks on it if the ICE state is
> completed (this is written in the same RFC). 

If both endpoints support MICE (tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06) then after mobility event, endpoint which detected local IP address change can trigger ICE connectivity checks without depending on ICE restart. If the remote peer does not support MICE but the endpoint needs mobility then it can get that using relayed candidates (TURN client and server will have to support "Mobility using TURN"). With MICE, If endpoint has multiple interfaces then it can maintain unused candidates from interfaces with lower-priority in standby mode, so that when the active interface is not available then media streams can be migrated to any one of these interfaces without depending on ICE restart.

-Tiru

> So, even if there is a NAT in between
> and peer may treat this new candidate as peer reflexive candidate, local side
> can't send STUN. Also, implementations should not assume NAT being present
> locally.
> 
> 
> BR
> Raju
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb