Re: [MMUSIC] ICE Mobility

Thanks for the comments, please see inline.

--Tiru.

> -----Original Message-----
> From: Lishitao [mailto:lishitao@huawei.com]
> Sent: Wednesday, July 25, 2012 9:13 AM
> To: Dan Wing (dwing); mmusic@ietf.org
> Cc: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy)
> Subject: 答复: [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?

There is no need to wait. The new pair is nominated for media after successful STUN binding response.

> 
> 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 ?

If an endpoint moves to a new interface it will inform it's peer using MOBILITY-EVENT attribute. The peer will
have to now initiate ICE connectivity checks as described below :

The ICE agent constructs a pair whose local candidate is equal to the transport address on which the STUN request was received with MOBILITY-EVENT attribute, and a remote candidate equal to the source transport address where the STUN request came from. The ICE agent will perform triggered check using this new pair and if the connectivity check is successful, the pair is then add to the valid list. The agent sets the nominated flag in the valid pair to true and can now use the new pair for sending media.

we will update the draft with this detail.

> 
> 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. " ?

It is not expected to send MOBILITY-EVENT before the ICE state is completed and media is selected. Hence the peer will
discard MOBILITY-EVENT before the ICE state is complete.

It should say "If MOBILITY-EVENT attribute arrives before the ICE state is Completed." (will fix the line)

> 
> 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 interface loss might be temporary (and soon regained), hence it could be valuable to retain the lost interface in SDP. 

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

Yes, If the Mobile device has more than one communication interface active (let's say 3G, WIFI) then change could be based on per bit cost and connection speed. 

--Tiru.

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