[MMUSIC] 答复: ICE Mobility

Lishitao <lishitao@huawei.com> Wed, 25 July 2012 03:45 UTC

Return-Path: <lishitao@huawei.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9526E11E8080 for <mmusic@ietfa.amsl.com>; Tue, 24 Jul 2012 20:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.077
X-Spam-Level: **
X-Spam-Status: No, score=2.077 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_73=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PtmiGuxTfaAg for <mmusic@ietfa.amsl.com>; Tue, 24 Jul 2012 20:45:22 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6018811E807F for <mmusic@ietf.org>; Tue, 24 Jul 2012 20:45:22 -0700 (PDT)
Received: from (EHLO dfweml202-edg.china.huawei.com) ([]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB00171; Tue, 24 Jul 2012 23:45:22 -0400 (EDT)
Received: from DFWEML406-HUB.china.huawei.com ( by dfweml202-edg.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 20:43:29 -0700
Received: from SZXEML416-HUB.china.huawei.com ( by dfweml406-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 20:43:27 -0700
Received: from SZXEML534-MBX.china.huawei.com ([]) by szxeml416-hub.china.huawei.com ([]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 11:43:24 +0800
From: Lishitao <lishitao@huawei.com>
To: Dan Wing <dwing@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] ICE Mobility
Thread-Index: Ac1p+zUFva24pK9+Re6kqju1dkzYXAAFXwSA
Date: Wed, 25 Jul 2012 03:43:24 +0000
Message-ID: <DA165A8A2929C6429CAB403A76B573A514679790@szxeml534-mbx.china.huawei.com>
References: <048b01cd69fb$35469ba0$9fd3d2e0$@com>
In-Reply-To: <048b01cd69fb$35469ba0$9fd3d2e0$@com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "'Prashanth Patil (praspati)'" <praspati@cisco.com>, "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>
Subject: [MMUSIC] 答复: ICE Mobility
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jul 2012 03:45:23 -0000

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. 


发件人: 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


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

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.


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


mmusic mailing list