Hi, Ted, Excuse me for late reply, thanks for the discussion. The reason why I said before is that currently there are limtied ISP providing ICE support for open applications, anyhow, P2P made a smart way to reach it. For what I know application which need ICE like IMS is normally go to independent APN. That could be guaranteed since it is kind of application binding APN. Today most mobile application binding with APN(kind of interface like) or could be on-demand select for user. I guess Marc raised similar consideration which allow application to call such interface API, then it can run depending on different connection's characteristic. Please kind help to provide your text regarding this application scenario, it will be helpful for MIF PS could include those. I will re-read the spec which you recommend and to know the potential needs. thanks again -Hui 2009/4/24 Ted Hardie <hardie@xxxxxxxxxxxx>: > At 6:30 AM -0700 4/23/09, Hui Deng wrote: >>For what I know at the moment service provider deployment experience, >>ICE like solution has been deployed by a dedicate close network, this >>is not interact with MIF space we talked here, mif are resolve general issue >>with host connections, in that scenario, application is isolated. >> >>thanks. >> >>-Hui. > > Forgive me, Hui, but it is not clear to me whether you think the application > is isolated in situations where ICE is in use, or whether it is isolated in the > work for which MIF might be chartered. > > If your point is that not all applications have a signalling-path mechanism > for trading candidates using SDP, that is certainly true. What is truly scary > is that this makes applications which can use ICE better off than the common > case, despite ICE's complexity. I hope, after reading the full ICE spec and > recognizing that there are *still* cases where it does not work to establish > connectivity, you will see the scope of the problem. > > Interfaces/network attachments may have different reachability characteristics > (e.g. be part of different address realms or otherwise have substantially > different access to parts of the network). There are classes of application > which will want to make interface choices based on those characteristics. > > There are many other characteristics which may play into interface choices > (do I already have a data channel on interface X, and need to acquire it on > interface y?), and I do not want to minimize those, power savings being > a big deal in my day job choices for this type of thing. But the > applications' needs here can't be subordinate to those, or the whole point > of the link--you know, traffic across it--is lost. > > Just my personal opinion, despite the mention of a day job, > regards, > Ted > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf