This is a post to Cisco for a bit of feedback regarding the BE3000. I've been using the device in the lab for the past few days and I wanted to make the follwoing points regarding the BE3K.
Just outline where I'm coming from I have a BE 3K with 8.6.4 installed with UK locale. I'm used to designing and deploying CUCM, CUC, CUPS, and integration with UCCX and UCCE, so I like to see alot of customisation in my CUCMs.
This seems like I'm poking holes in the device but I actually believe it could be really good. There is a lot about the box that I like, it is great for unexperienced users, it's a breeze to deploy (I set my one up in less than a day with a customised dial plan), and it's competitively priced for the SMB. I'd like to see more attention to the Unity and IVR on the server, and the unlocking of the advanced configuration options.
It would be really good for Cisco to release a roadmap for the features due to be implemented on the BE3K, or perhaps if it exists someone could point me towards it.
With respect to point 1 above - the 6 second delay on redial. Are you testing this with re-dialling to internal extensions or externally to PSTN mobile - cell phones? The reason I'm asking is that it takes about 5 seconds for a mobile phone to reach session progress (ringing) under normal circumstances anyway. I'm wondering whether the call is actually processed straight away when you press redial - but the display on the phone is only updated on session progress ? If so this is a more accurate description of the 'feature' you've noticed.
With respect to 5 - SIP Advanced. We as a service provider will at some point soon have a Service Provider profile for our SIP Trunks which means a partner wouldn't need to know which boxes to tick for our service - and therefore we should reduce the support cost of implementation. I imagine the same goes for Cisco support. However as an engineer I agree with you. I'd like to suggest that Cisco make available a set of COP files that unlock a comprehensive list of advanced GUI utilities that would solve the remaining items on your list?
James & Adam,
Thanks for the feedback. It helps us greatly in creating the roadmap for the product.
Responding to some of your specific points:
1) As Adam mentioned, please clarify whether it is a PSTN call or an internal number. There may be some delay in getting the alert/progress from the PSTN network, if it is a pstn call. I tested on myself, and there is some delay, if redial is to a PSTN number.
3) Will look into this, Meanwhile the FAX solution is to use FXS on SPA8800.
4) Will see if there is an problem with uploading COP file using USB.
5) The Cisco supported configuration of SIP trunk is to connect to a CUBE. The configuration options which are exposed on SIP trunk page are configuration items which are required, if SIP trunk is connected to a CUBE. There is a smart design guide which provides details on what configuration is required on CUBE.
If you are not connecting SIP trunk to CUBE, then you would require advanced connection pack, if you want to expose more configurable options for SIP trunk settings.
6) We understand that the boot time is high. It should be reduced in upcoming releases.
2 & 7) These items are asking for advanced configuration options, which partners like you, who have worked with CUCM, CUP etc. are used to. This product is mainly targeted to SMB customers or partners who may not have that kind of expertise with advanced configuration options.
We understand that it is important to meet requirement from advanced partners also. We will take this feedback and see how we can expose these parameters and keeping the system simplified at the same time. I do not have any timeline on when it will be done, since there is lof ot work required to fix things like high reboot and upgrade time.
It's great to see your response
One thing though - you say:
We will take this feedback and see how we can expose these parameters and keeping the system simplified at the same time. I do not have any timeline on when it will be done, since there is lof ot work required to fix things like high reboot and upgrade time."
Actually I think you should understand that although the slow boot time / upgrade time is annoying, it doesn't actually make any difference to the partner selling units to customers. What makes a difference to the partner is being able to meet the customers' expectations by providing them with a phone system that operates in a way that matches their business practices.Could your priorities might be the wrong way around? The slow boot time can be managed by setting expectations in advance. I really like the BE3000. It's fantastic, the handsets are superb and once configured it seams to work OK.
High priority items include meeting customer expectations in terms of features that they expect from a phone system, system stability and usability improvements.
My point is, once we have completed these tasks, then we can look at ways to meet advanced partner requirements, like having the same CLI interface and set as CUCM, exposing voicemail configuration parameters etc.