[MMUSIC] 答复: ICE Mobility

Hi Dan 

I read this draft, and I think the idea of this draft is useful. Regarding the two methods mentioned in the draft, I think the TURN one is better than the ICE one, 

especially if the TURN server has the cache capability, the data lose will be quite small. 

For the mobility using ICE I got some comments,
1), in section 3.1, I believe the procedure described here is all about the endpoint who meet the mobility situation, so in step 6, the ICE connectivity check is only done by this side, do you need to wait the ICE connectivity check finished by another side (probably the procedure in section 3.2 ) before you nominate the check result?

2), in section 3.2, it said that "A STUN Binding Request containing the MOBILITY-EVENT attribute MAY be received by an ICE endpoint. "  why is MAY be here? And when     does this MOBILITY-EVENT attribute need?

3) ,  what do you mean by this words " If this is received before the endpoint is in the ICE Concluded state, it should be silently discarded. " ?

4), section 3.3, losing an interface, it recommends that not to send the SDP to remove the lost interface, instead it is better to maintain it active. For my understanding, when the mobile device switch from one interface to another(for example, wifi to 3G), the gateway and NAT before the device will change too, how can it maintain the previous interface active? The only way, I can consider is that the previous interface is not totally lost, it still active on the device, that means the two interfaces all exist at the same time, but the device can choose to use the new one because its signal is better than the previous one. 

Regards
Shitao

-----邮件原件-----
发件人: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 代表 Dan Wing
发送时间: 2012年7月25日 8:20
收件人: mmusic@ietf.org
抄送: 'Prashanth Patil (praspati)'; 'Tirumaleswar Reddy (tireddy)'
主题: [MMUSIC] ICE Mobility

MMUSIC,

Losing or acquiring an interface often happens with mobile devices, such as
when a device gets within WiFi range or leaves 3G range.  Today the industry
generally relies on techniques below layer 3 to hide the IP address change
from the remote endpoint (e.g., LISP, Mobile IP).  These existing techniques
have some drawbacks, such as requiring support in the network
infrastructure.

ICE Mobility explores how to accomplish a similar function for ICE-initiated
flows without needing support in the endpoint or in the network.  Instead,
the mobility support is provided at the ICE layer (such as RTP, SRTP, or
RTCWEB's data channel (SRTP over UDP)).  The document discusses how two
approaches:  (a) when both endpoints support ICE Mobility, and (b) when only
one endpoint supports ICE Mobility, which uses a TURN server -- a different
sort of network infrastructure.

http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility

We are unlikely to get time in MMUSIC to present this draft, but are
interested in feedback.

-d

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic