<br><div class="gmail_quote">On Fri, Jan 22, 2010 at 1:39 AM, marc fawzi <span dir="ltr"><<a href="mailto:marc.fawzi@gmail.com">marc.fawzi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">>>p.s. we can switch to german i think (-;<div><br></div></div><div>:-( </div><div><br></div><div>I think the idea of using olsrd to provide a way for mobile devices with conventional wifi capability to switch between olsrd-enabled wifi accesspoints without losing VoIP connection is a very important telephony application of OLSR that seems to be very practical from a business perspective in the near term.</div>
</blockquote><div><br>practical for sure, but supporting voip (maybe even flickerfree) is not trivial</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><br></div><div>I'm keeping my fingers crossed and hoping that it can be done. </div></blockquote><div>do you think that requiring/recommending adhoc-mode is a big hurdle aswell?</div><div><br></div><div>it has 3 benefits, </div>
<div><br></div><div>- we can reuse the wifis forming the mesh aswell to provide connectivity for clients, ap-mode requires dedicated wifis, or VAPs (but imho VAPs will not fulfill the requirements of raphaels approach)</div>
<div><br></div><div>- and we do not have to switch hard (and fast) from one master to the other, as the client does not switch cell, it only switches it`s nexthop, this is also initiated from the new master, which at this time is already ready to provide the required connectivity</div>
<div><br></div><div>- above also implies that the switch can go within zero time on the client (it just changes the mac-adress of its gateway)</div><div>(at least if the new master is on same frequency, if the client need to switch frequency aswell, we have same situation as with raphaels approach)<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>It's far easier from a business perspective than requiring mobile phones to be in ad-hoc mode and running olsrd.</div>
</blockquote><div>so there`s are 2 other options (in my mind) inbetween those two (A, D) you mentioned</div><div><br></div><div>to summarize:</div><div><br></div><div>A ap-mode, no software on client (using dhcp, and client decides when he switches network) (the client switches (based on its wifi-drivers decision to do so), and the mesh needs to react asap on this)</div>
<div><br></div><div>B ad-hoc-mode, no software on client (we use initially dhcp and arp packets to switch the client to another master) (the olsr mesh initiates the switch of the gateway for the client, and the client could (theoretically) receive incoming traffic from multiple masters)</div>
<div><br></div><div>C adhoc-mode a lightweight client, that can be installed as normal application (requires no root priviledges) (we still use arp to switch the client, but we can do better linksensing, and maybe even display topology, or other info on the client, and give the user methods of interacting, like choosing which internet gateway of the mesh he likes to use, and so on)</div>
<div><br></div><div>D adhoc mode, full featured olsrd on client (the client gets a full router infact, (potentially using up his battery for routing other peoples traffic))</div><div><br></div><div>----</div><div><br></div>
<div>imho C is much work (on potentially multiple plattforms) and i´m not sure how much benefits it has over D in real life<br><br>D already exists for some phones</div><div><br></div><div>but imho B is the most interesting one (as it will run on "any" existing wifi on a olsrd-mesh)</div>
<div><br></div><div>(furthermore it shares quite much with A, so an A/B approach is reasonable from my point of view)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div>
<div>Sorry to interject my non-technical opinion, </div></blockquote><div>no need to be sorry, as we have to keep users in mind aswell with this feature,..</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>but I would hope you guys continue in English ;-) </div></blockquote><div><br></div><div>at least for a while,..</div><div><br></div><div>Markus</div></div>