Cisco IP Communicator

[MrPrince1979]

Probably not… but will the uc320/300 series see support for CIPC?

Cheers.

[rvaltier]

Hi Oliver,

CIPC is not supported, UC320 is SIP based, only Cisco SPA phones 500 and 300 series are supported.

Regards,

Rogelio V.

[mmonday]

Hi Oliver,

Is it CIPC in particular you are interested in, or are you just looking for a softclient to use on PC's and Mac's?

Thanks

Mark

[David Trad]

Hi There,

I would be willing to try any SIP client if there was a config explanation as to how you would be able to do it.

I have a LAB UC-320 that I can do as much testing as needed on it, I love the unit but am finding it a little frustrating in that there is no BRI versions and no softphone ready for the unit, makes it very very hard to compete against an Asterisk install as I discovered yesterday when pinning one of these up against an Elastix installer, it competes on price but still lagging a fair bit in features, what ever the UC-320W does the Asterisk/Elastix system matches is and then some.

Any thoughts on a SIP PC client??

Cheers,

David.

[mmonday]

Hi Oliver,

I should introduce myself, I am the Vice President of the Technology group here at Cisco that produced the UC320.
So I am always curious as to what customers need, etc.

  

On the BRI, unfortunately the UC320 has only FXO and SIP trunking and does not support BRI internally.  We do support and have tested the Mediatrix bri gateway, but you probably read that.

We are expecting a great deal of customers to use SIP trunking, is that something you have tried?

I will see what is going on for a SIP PC client and post it in the community when we have a solution.  Should not be to difficult, given our strong implementation of SIP and the number of third party clients out in the market.

Thank so much for contributing to the community!

Mark

[MrPrince1979]

Thanks everyone for the replies.

It would be nice to use CIPC with a device like this… from what I’ve read so far the 300 series fits nicely below the 500 series, which for some is still overkill etc. Ideally I’d like to use CIPC and simply have one unified solution.

[David Trad]

Hi Mark,

I should introduce myself, I am the Vice President of the Technology group here at Cisco that produced the UC320. 
So I am always curious as to what customers need, etc.

Thanks for your presence on here, it is always good to know who within Cisco is monitoring what their partners/customers are saying about the products developed

On the BRI, unfortunately the UC320 has only FXO and SIP trunking and does not support BRI internally.  We do support and have tested the Mediatrix bri gateway, but you probably read that.

Not to diminish the UC-320W capabilities, as from what I have experienced so far it is quite vast for a small unit... However I would go as far as to make a bold claim that introducing a 2 port BRI version would not make it a much more expensive unit in terms of production costs, and would make it an even more appealing not to mention competitive appliance. By having a FXO version with SIP is fantastic, but having a BRI version with SIP makes it a killer appliance, the capabilities of this unit then would match that of say an IPECS unit made by LG-Erricson, or even match the embedded version of an Asterisk system both are within the sub $3500 AUD cost including install with 5 handsets (Yeah not much margin with the Cisco compared to the LG systems, but that is what we have to do to compete, and that is competing internally as well).

The Mediatrix unit is a third party device, it adds another point of failure, and on top of that it is also not currently allowed to be sold in Australia (Based on 2010 documentation which could have changed). BRI allows us to put a 100 Number in-dial or a 10/20/40 block range on the unit, and the SIP trunk allows us for LCR for outbound calls, the value add and the importance of a BRI inclusive system is far greater than what you may give it credit for, ASIA, OCEANIA and most parts of Europe still use and push ISDN/BRI services, so it wouldn't be just for the Australian market.

We are expecting a great deal of customers to use SIP trunking

There is still a significant resistance by the market to go all-out-sip trunking, if marketing it for Office calling and or a method of LCR it becomes widely accepted, and there is a huge interest in the market for it, but most shy away when they understand the risks associated with going pure SIP based services, it is a bold move by Cisco and someone has to do it, so it is commendable, but there still needs to be some maturity in the market for pure SIP trunking, and yes you can offer a PSTN backup, but then that defeats the purpose of going to SIP for the cost savings, especially when line rentals here in Australia are quite high.

I will see what is going on for a SIP PC client and post it in the community when we have a solution.  Should not be to difficult, given our strong implementation of SIP and the number of third party clients out in the market.

With the purchase of Jaba I am sure you should have a SIP stack implementation somewhere amongst the code base... Somewhere

I understand the request for CIPC but then I would say that is an over kill when really only a simple SIP client is required for a device like this. allow for the use of something like xLite  or sip-communicator with the latter being a full and complete open-source client, would help, but a Cisco version would be better as it would be common and consistent, but alas that is business decision process I guess.

Things missing on the UC-320W in my opinion (Which you will notice i free give and am quite persistent ):

• Basic BRI support (2 Port at least)
• Basic Multi-Site connectivity, this can be easily achieved via SIP trunking, and am presently looking at quoting a real estate agency that varies from 3 seats to 8 seats and over 7 sites, the UC-320W would have been the ultimate device to provide and giving the ability to allow for site to site calling with just basic Dial-Peering, nothing fancy as this is not a UC-500 system.
• Minimum 2 port FXS one for fax one for cordless dect phone or both for a cordless dect phone (Since there is no other wireless device other than the 525G2)

Still to fully get into the guts of the system, but the above ideas/suggestions/recommendations would change the dynamics of the UC-320W and also its market position. However I will reiterate that this is a fantastic unit, I am not complaining or whining just enjoying being a Cisco evangelist, love the products, love the unit and enjoy installing and selling them, but this does not mean there is no disconnect or frustration with some of the decisions that Cisco make from time-to-time.

Anyway thank you for bringing this product to market, and thank you for giving us partner the ability to put forward our thoughts and opinions.

Cheers,

David.

[mmonday]

I very much appreciate the feedback and especially the ideas!

For us, the two more difficult requests are for BRI and additional FXS. Hardware changes take time. I think we can and will handle the FXS issue by providing other ways to get cordless/mobile solutions with UC320 -- we have several initiatives underway. Certainly the feedback is strong on BRI, so we will be evaluating possibilities.

On Multisite - done the way you suggest - I will ask engineering to evaluate.  Agree that SIP trunking is a great way to resolve.

Please keep the feedback coming!!

Mark

[David Trad]

Hi Mark,

I cant stop tinkering around with the 320 and am finding this unit to be more and more appealing, there was something today that flicked on the light bulb and I figured it would be something worth while mentioning.

In the UC320W Quickstart booklet that comes with the device, on page 5 and the last table it states "USB - For Future Use" I am wondering if there is any reason as to why Cisco would not consider creating Adapters instead of the SPA8800, for instance you could offer a 2 port BRI, 4 Port BRI, 4 Port FXO, 4 Port FXS and Maybe even a 2 port FXO adapter...

The idea would be to have an easy to install method for the system, and being USB you can use the equipment ID method for auto provisioning, it also eliminates the need to have things inbuilt in it other than the standard configuration you have now. You also have 2 USB ports of which one can be reserved for creating backups and maybe even lock it out from having those adapters attached to it???

You mention that manufacturing of the units to have the higher level requirements is an issue, what about if they were just add-ons? Being accessories it becomes consumable for Cisco which means more product turn-over, where as the UC-320W is just a single unit or lets call it the base unit to which you can expand upon. The future path of this has huge implications even to the point of being able to port this to the UC-500 series so the restrictions are not limited to a single device.

If I am not mistaken there is enough bandwidth on a USB port to handle the voice traffic, and I dont think that USB would be an issue since these types of devices have already been in the market place operating on Linux platforms.

Again this is an observation and putting forward ideas, it would be interesting to see what others think of that, but I am also mindful that this is another point of failure, but being USB it is easily swapable and it is consumable which means they can upgrade or downgrade very easily

Cheers,

David.

[kfm]

Mark,

I just want to state that we also would also like to see CIPC supported. We are presently rolling CIPC out on our current CUCM installation and was looking at UC320W as a potential small branch solution.

Thanks

Kent

[mmonday]

I think using UC320 as a small branch solution may not be as effective as using CME on an ISR as the choice.  It is just not the design center for a UC320 and it is for CME.  I appreciate the concern/request for a CIPC solution and we are evaluating it.  As was mentioned CIPC compatibility is not a given since UC320 uses SIP to communicate to it's clients.

Thanks

[CTRLITINC]

Good to hear a VP getting involved and a good place for me to jump in...

My company developed Call Ctrl Call Manager, a Windows call manager for the SPA300, SPA500 and SPA900 series of IP Phones.

http://www.uctrlit.com/CallCtrl

As you well know the UC320 supports the SPA300 and SPA500 Series IP Phones. Since Call Ctrl talks with the SPA IP Phones directly, it can run under virtually and pbx. Call Ctrl shares some of the Cisco IP Communicator features, but can fill some of the gaps when the Cisco IP Communicator is not viable. This is found in mixed enviornments, hosted (RingCentral) and SIP-compliant (non cisco, such as Asterisks, 3CX).

Call Ctrl allows Windows users to perform nearly all phone function from the desktop and application use everyday. For example, there is Click-to-Dial, Redial, Directory, Speed Dial, Drag and Drop Transfer, Drag and Drop Conference. Call Forward, DND, etc. All available from the desktop which exponential increase the phones features. You can initiate a call from Outlook, Internet Explorer, FireFox, or any Windows application for that matter. We even had on client who had a Unix system and allowed them to call patients from thier Windows based unix terminals.

As Mark suggested there are many SIP Clients or what are referred to as Soft Phones. A couple you can try are:

- SIP Communicator

- sipek

- http://blog.voipsupply.com/free-sip-softphone-roundup

- google SIP SoftPhone for even more

We are currently testing the UC320. You can contact our support/sales from our web site and we can get a trail/demo of our latest release that should support the UC320 w/o much of any problems. As of today, we have not offically released to the public, but will in a matter of weeks.

Thanks,

Steve Wofford

www.uctrlit.com/CallCtrl

Call Manager for SPA IP Phones

[David Trad]

Hi Steve,

As Mark suggested there are many SIP Clients or what are referred to as Soft Phones. A couple you can try are:

In order to do this you would need to have the proper method in which the SIP client needs to register to the system, this has not been explained yet by anyone from Cisco, whilst I am certain this should not be a difficult process it is best to ensure that the correct one is followed and Id rather not risk causing issues to the unit as it is a Cisco provided LAB testing unit, not an NFR system.

I like what you have developed with Call CTRL it is interesting and will be looking further into.

Ultimately it would be best though if Cisco provide a basic Soft Phone client, it all becomes apart of the story and would like to keep the integrity of the story intact if possible.

But if all else fails, and drastic measures are required, then I will look to see if there is a safe and clean way to circumvent the road blocks

Cheers,

David.

[techiegzz]

CIPC is s great idea and wireless handssets as well because personally I would love to deply this over any Asterisk system and to have a compelling and competitive package will go a long way to fulfill such requirements.

Perhaps other UC300 series version incorporating some of the aforementioned ideas will be great and a way to accomplish this may be to widen the appliance hardware a bit more perhaps to fit on a rack (that even small businesses have these days) and at the same time have more space for more interfaces in the back of it, which will probably be able to hold upgrade modules for those who may purchase basic models.

[bjames]

David, you are one smart cookie 

USB is a great idea.

I too would like a softclient, I will assume at this point in time that nothing will be done as the Jabber clients are SLOWly rolling out and I'm sure this is Cisco direction. I just hope these clients find their way into the SMB UC market space not just the Enterprise offerings.

Bob James