<div>Hi Markus,</div><div><br></div><div>It would seem right to think that ad-hoc mode is going to be supported as a standard feature by the newer wi-fi chips, especially if a hot market/applications is developed that depends on having it, like voip-over-mesh.</div>
<div><br></div><div>Regarding the scenarios you've outlined, A thru D, I prefer A because B sounds more complicated/more work to me on a gut-feeling level, as I don't fully understand what is involved in either scenario. What I mean is that A sounds like less work and less complicated as far as the changes you would have to make in OLSR, and that's always the right thing to do, imo, because it represents the minimum viable response to the feature being requested, and I'm a fan of "minimum work" :-) Now if B is better or more robust with respect to future vision then you may want to consider that in the roadmap, and for now go with the simplest way to provide switching without loss of connection for clients not having olsrd.  </div>
<div><br></div><div>My own interest in the tech is to provide VoIP-over-mesh in densely populated areas, starting with downtown/business district in Seattle.  </div><div><br></div><div>I have VoIP-carrier-side business knowledge and SIP provider expertise so I know that carrying and terminating traffic from mesh to regular phones or IP phones outside the mesh can cost as low as $0.003 per minute or less (for carriers with large local termination coverage and/or peering arrangements), which can lead to "basically free" or "cheap" decent quality voice service for mobile phones.</div>
<div><br><div>So, to me, it's about how fast I can deploy a "demo" mesh so I can start working on the business side.  I am connected to many investors in this space who will be very happy to see a demo voip-over-mesh work in 2-3 city blocks and I know I can make that happen because I'm as excited about it as everyone who wants to pay less for their phone bill (in 5-10 years from now)  <div>
<br></div><div><br></div><div>So "A" is best scenario for me if and only if it can work as well or better than B and is less work/less complicated than B.</div><div><br></div><div>And like I said, if B is a solution that is more relevant to the olsr team's vision and goals then you can always put it on the roadmap, and for now give us A :) because it's the least amount of work/least complicated.</div>
<div><br></div><div>:)</div><div><br></div><div>Marc</div><div><br></div><div><br><div class="gmail_quote">On Fri, Jan 22, 2010 at 2:42 AM, Markus Kittenberger <span dir="ltr"><<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><div class="gmail_quote"><div class="im">On Fri, Jan 22, 2010 at 1:39 AM, marc fawzi <span dir="ltr"><<a href="mailto:marc.fawzi@gmail.com" target="_blank">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>>>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><div><br>practical for sure, but supporting voip (maybe even flickerfree) is not trivial</div><div class="im"><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><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><div class="im"><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><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 class="im"><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><div>no need to be sorry, as we have to keep users in mind aswell with this feature,..</div><div class="im"><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><div>at least for a while,..</div><div><br></div><font color="#888888"><div>Markus</div></font></div>
</blockquote></div><br></div></div></div>