> Are you saying you *are* getting stutter, or that people are > reporting it? > You need both your wifi chipset and your BT chipset to have a > couple of signaling lines which indicate when they want to > use the radio, and then arbitration logic to determine who > wins if they both want to. Without that, or with it > unconnected/misconfigured *will* get stutter due to band contention. > > It may be unimplemented due to lack of availability in the > chosen chipset, cost, marketing or idiocy; my bet's on the latter.
I think you're right. It's reports on the unit I've been reading. Awaiting word from Telus if they'll give me a free upgrade before I spring the cash for one. Everyone is complaining on the voice quality on the bb so it's gotta go. > > > For me, the limits on the blackberry > > (no sip client, no media player) are driving my push to get rid of > > this 7130 for something better. As we were talking earlier today (I > > was the guy in the orange/white shirt at lunch), lots of these > > technologies have potential, but they just always seem to > miss on the delivery. > > It's the tragedy of technology. You get people with great > ideas but who can't implement it, or they get crippled by > business decisions, terrible laws written by technophobes, > time constraints and fear of having their "great idea" stolen > and the system subsequently being locked down to protect > their investment. > > To me, it's all "blah, blah, blah..." excuses. Yes, you > need to get your product out to start making a buck so you > can cover your development expenses and gain marketshare, but > that doesn't explain the opening up of the system, publishing > of the internal file formats and generally the ability to > screw with the system you paid good money for. > Today, the perception is "first to market wins" regardless of how complete it is. And there's many an example to cite the business case of doing so. The best solution doesn't always win and the challenge is to find that balance. I'll agree, that the "bad guys" are the numbers they expect, and willing to bet that half the "IP theft" is internal based anyhow. > Let's face it: the number of people who actually *could* play > with their systems in such a way as to threaten any business > plan or product lineup disappear into the statistical "noise" > of their intended market. The evil haxors get in anyway, so > they're of no use as an excuse, although with horrible laws > like the DMCA and the up-and-coming Canadian equivalent, at > least they can sic the police on those types, and those guys > are always good for a soundbite about how horrible the big > bad Internet is and why we need more laws to protect poor > little businesses who can't be arsed to actually compete on merit. > > > The Aastra > > implementation is no different. Cellular type deployment but no > > dynamic power management. No load balancing algorithms. A > few other gripes too but > > we'll see what happens. Isn't technology wonderful. Aggh! > > I honestly do not understand this "no load balancing" issue > -- it's impossible > to load balance how it was being suggested today. If you > have two RFPs, A > and B, and each can handle 8 active calls, and A is at 6/8 > and B is at 0/8, and you have a phone P who sees both at > relatively equal link quality levels, what advantage do you > have of making P register with B instead of A? None! > Remember that they phones will bounce back and forth as > needed (although using a transfer timeslot pair in the > process). If another phone, Q, comes into the network and it > looks to link up, it's a VERY arbitrary thing to say that it > will likely find A before B, and therefore a phone which sees > both A and B the same relative link quality should choose the > lessor-loaded one. If P moves and it hands off to A, you're > using one of the "transfer" channels, and not one of the main > conversation ones. If you have a site where that > *is* a real, honest-to-goodness issue, put A and B at the > front entrance and C somewhere inside. This technology is > *cheap* compared to what else is out there. Skinnying up on > the RFPs is like skinnying up on the server memory; sure cost > is everything... until you can't get the work done! True enough. For me, the simple algorithm though of max power wins..if full, fall back to next base station...leaves something to be desired. Using today's conference room example...a base station in each corner...every device in that room would likely see it. The algorthm could be something like... 1. anything above a min threshold...ie..I think they said -90db or something was their min power needed ...so take half that...Any base station showing power of at least half...find the lowest loaded of it...since they use the oom software anyhow..it makes the decision...not the base stations...let it load them accordingly... Then walk-ins, etc have less chance of switching etc...and nobody should get a "overflow" and unavailable. Extend that situation to a warehouse with 20-30% overlap...it becomes even more viable since workers tend to concentrate in locations... > > I dunno; to me it's totally, completely arbitrary. Load > balancing them gives no apparent benefit that I can see, and > the only thing I can really see a nice use for is if A is > already at capacity *and* is transferring media for two > additional channels (i.e. it's at spectrum capacity), then I > don't see why it wouldn't do a SIP REINVITE to hand off the > media. They're marketing the lack of REINVITE as a feature, > but I think that feature's of rather dubious value. SIP > REINVITES are pretty seamless in and of themselves, and > having the additional proxy traffic between RFPs seems a waste. > I missed the sip reinvite ..guess that was session 1. To me, sip reinvite is a moot point as it's only merit comes in offloading heavily loaded servers...and in today's environment, that 512 phone capacity is well short of a modern server anyhow. > You're right though, the inability to turn DOWN the transmit > power (or have it AUTOMATICALLY adjust like a cell > phone/tower) seems to be a shortcoming, as that could > potentially have significant power savings as well. That may > be part of the DECT standard though; I'm not sure. Completely agree..it's a big requirement...microcells are going to be the only way to go > > SNMP for ALL radio data will be very helpful, as will TFTP > for provisioning, phone books and other configurable items. > And let's PRAY there are a set of decent OFFICE ringtones for > these things! > SNMP and the whole host of reporting...way short on that ... Haven't even begun to think about what I'd like to see here but at the minimum, dropped calls, call quality, handoffs, rfp loading... Then items like visible phones from each rfp (with signal strength)...tie that into some mapping program...get a 3d picture of where a phone is located... Then again, a good rfid tag system and a few dozen sensors around a building could tell me more about a phone's location... I guess I'd like to see something like the AGPS on most cell phones now for emergency locating. I actually had the experience a year ago to use it...guy near drowning up at cottage on one of those kite surf boards. Did a 911 call, get put through to OPP marine unit but got disconnected due to loss of signal. Wasn't 5 minutes and 5 OPP as well as a couple of the local reserve police showed up parked behind my vehicle where the phone was located. Marine unit did their job but was surprised that they pinpointed the phone's location as well as they did. And another though was the integration of WiFi and RFP...mesh network ... Wifi handoff still not working yet..need that to improve then tie phone/computer and everything together...1 package..would be nice D. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
