This blog was generated from CDN blog Created by: Adrienne Moherek on 19-09-2013 03:00:20 PM Customers, Partners, and Developers, Cisco Unified Communications Manager release 10 adds support for gateway-based recording.  The feature enables Administrators to record Cisco Jabber and Cisco Mobility calls as well as calls extended off-network to mobile phones and home office devices.  Please refer to the updated Supported Devices wiki to see the updated list of phones and soft clients that support UCM Gateway Recording.  Be sure to check out our Recording Gateway Requirements wiki for a list of gateways that support this feature. Download the new overview slide deck here Best- Cisco Collaboration Product Team ... View more

This blog was generated from CDN blog Created by: David Staudt on 24-07-2013 02:11:39 PM The Cisco Unified Communications Manager SIP Trunk Messaging Guide (Extended) has been published, and can be found in the Documents area.  This document covers new features added in UCM 9.0(1) / 9.1(1): • SRTP Interworking • URI Dialing • Original Called Party Name in Placed Call History • E911 Teleworker • Enhanced Location CAC, TP-CAC • IMS Support ... View more

This blog was generated from CDN blog Created by: Prince Woodrow on 11-06-2013 03:22:28 PM On May 16th, 2013, Google launched an early access preview of Android Studio, a new Android development environment based on IntelliJ IDEA. Android Studio, which can be downloaded here , is available for free on Windows, OS X, and Linux. Android Studio is currently only available as an early access preview, meaning that several features are either not yet implemented or incomplete. There are currently known issues with installing add-ons on Android Studio. The Cisco DX650 add-on is not currently supported with the early access preview of Android Studio, but we will post a "How To" article when this changes! ... View more

This blog was generated from CDN blog Created by: Adrienne Moherek on 20-05-2013 11:01:37 AM AXL Developers: A new comprehensive AXL Change Notification Feature has been added to our Administrative XML interface in Unified CM 10.0.  Due to scalability issues, the old Notification mechanism introduced in UCM 9.0 has been removed.  The old notification feature only supported Users, Phones, and Lines, was never documented, and was not able to scale to meet our needs.   Notification requests based on the 9.x mechanism will no longer work when using UCM release 10.0.  No alternatives were available.  We apologize for any inconvenience this change in direction may cause. We are 100% confident the new 10.0 Notification feature is the right approach and aligns with our go-forward direction. Please read the AXL Change Notification page which illustrates how your application can take advantage of this new, powerful feature ... View more

This blog was generated from CDN blog Created by: Anil Verma on 30-04-2013 10:49:45 AM I am glad to see queries coming from developers as they start to develop  complex applications using the Unity Connection API. There are questions when using the notifications about the scale of the new applications being developed. The developer should plan on doing a scale test to determine the final numbers. The various components that build the solution can provide their numbers, but combining them together can lead to situations which were not clear earlier. On this page here we have posted what the performance tests on Unity Connection has determined - docwiki page about scale ... View more

This blog was generated from CDN blog Created by: Matthew Williams on 11-04-2013 03:27:10 PM Last time I talked about some of the additional features that the Cisco Unified Communications Manager brought to table in regards to the DX650. I did however leave out a crucial ability of the CUCM, which is pushing applications to the DX650. This is a feature that the system administrator of the CUCM would be able to perform. So, let's take a look at creating this IP Phone Service by going to your CUCM Administration page under Device Settings > Phone Services. Above is what you will see when you try and create your IP Phone Services. There is a few required fields that you need. Let's go through each of these fields. Service Name/ASCII Service Name: This value must be the package name of the Android Application that you are trying to install. This is required in order for the service to work. Service URL: The location of the Android APK you are installing. Service Category: Set this to Android APK. Service Type: Set this to Standard IP Phone Service. Service Version: This is the version code that is specified in the Android Manifest. If leave this blank it will automatically re-download the application every time the configuration is updated. Assuming you don't want this to happen just fill this in with the version code. If the version code you specify is different from the Android Manifest it will not update the application. If you update the version with a different value and update the subscription it will update the application. Please note this is the version code, not the version name. At the bottom you see that there is a Parameters section, this is used to send additional information to the application. For instance, you want to name the phone. Let's take a look at how we would pass this name to our device. Above you can see the parameter that we created with the name of Name. The default value or the value that will be stored with the key of Name is DX650. This parameter will be installed on your device as a shared preference. With this in mind the application can just grab the value out of the shared preference. Below is a small code snippet that would do just that.  If you need more information on Shared Preferences head on over to the Android Developer Site . Knowing about this Parameter section when writing your Android Application could come in handy. 1 SharedPreferences app_preferences = PreferenceManager.getDefaultSharedPreferences(this); 2 String text = app_preferences.getString("Name", "null"); Once the service is setup, all you have to do is go to the Device page and subscribe the device to the service you created. This will then in turn push the application to your device. ... View more

This blog was generated from CDN blog Created by: Larry Michalewicz on 08-04-2013 09:18:48 AM Designing Applications For the DX650 Writing applications for the DX650 is no different than writing applications for any other Android device.  With that being said, a very common questions about our device and I’m sure other devices as well, is “Why doesn’t my app work on your device?.”  My standard answer is “Because you did something wrong!” Obviously, that’s not a fair thing to say without more information.  To understand the problem with modern devices, you have to take a brief look at the history of Android. To gain access to Google applications like the Play store a device must meet rigorous standards as defined at http://source.android.com/compatibility/ .   The Android Compatibility Definition Document (CDD) and Compatibility Test Suite are used to define the standards and test that a device meets the standard. To fully understand why some applications don’t work on some devices, you have to look at the history of the CDD.  For example,  in version 1.6 (Éclair) the rule regarding the Camera is: Device implementations MUST include a camera Not much wiggle room there because in a formal specification, MUST means just that, it’s required and non negotiable. If you fast forward to the version 4.0 (Ice Cream Sandwich) CDD, it says: Device implementations SHOULD include a rear-facing camera and May include a front-facing camera. This is obviously a big change in the definition (a good one in my opinion), and it adds some complexity that developers need to deal with.  Why would the definition change?  In the beginning all Android devices were pretty much the same.  As time passed there was a desire to have devices in different sizes and shapes, and it really didn’t make sense to force them all to the same characteristics. Another quick example.  In Android 1.6 compatible devices were required to have an Accelerometer, Compass and GPS.  In 4.0, the requirements are that a device must correctly report the sensors that it has and that the sensors must report accurate and genuine data (no fake sensors allowed), but there is no requirement that a device has any sensors at all. As Android changed, one thing they tried to do was preserve backward compatibility, so in many cases, an old app will work on a new device.  There are exceptions of course, for example, if an application was written when cameras were required, that application will likely have problems on a modern device with no camera at all. So what’s the best approach to dealing with the fact that many different devices exists.  I’ll suggest three methods Google Play Filtering Runtime Detection Just Deal With It (my favorite) Google Play Filtering All devices that access Google Play must passed the compatibility tests which means they must accurately report their features.  For example: these are the features reported by a DX650 feature:reqGlEsVersion=0x20000 feature:android.hardware.bluetooth feature:android.hardware.camera.front feature:android.hardware.faketouch feature:android.hardware.location feature:android.hardware.location.network feature:android.hardware.microphone feature:android.hardware.screen.landscape feature:android.hardware.touchscreen feature:android.hardware.touchscreen.multitouch feature:android.hardware.touchscreen.multitouch.distinct feature:android.hardware.usb.accessory feature:android.hardware.usb.host feature:android.hardware.wifi feature:android.software.live_wallpaper In the Manifest for your application, you can if you want ,define various device requirements such as screen size, the presence of a rear camera or other device specific features. Google play looks at both the device requirement in the application Manifest and the features reported by the device and filters (removes) any applications that require a feature that doesn’t exist on a specific device.  If you’ve ever wondered why applications are available for some devices and not others, now you know. You can get a full explanation of how this works here: http://developer.android.com/google/play/filters.html This filtering feature is great for applications that are deployed from Google Play, but as an application developer you may want to have the ability to deploy your application via other means, or you may simply want more devices to have access to your application. Runtime Detection Many problems can be solved before they exist by simply writing good code.  As devices have change Android has done a great job of adding the ability to determine device characteristics at runtime rather than just assuming that the device had a specific feature.  Take the Camera for example.  Prior to Android version 2.3 the Camera had a simple “open()” method that returned the “default” camera which must be a back-facing camera.  In Android 2.3, the front cameras were first allowed and all cameras became optional, new APIs were added to allow your application to get the number of cameras, the type of camera (front, back) and a new “open(int cameraId)” method that allows you to specify which camera you want to use. In my opinion, no modern application should ever use the old Camera.open() method, but instead should use the modern APIs to detect the cameras and open the specific camera that it needs. For a good example of detecting capabilities at runtime, check out James Catalano’s blog on using the from camera .  These same techniques can be used for other device dependent features. Dealing with different screen sizes and resolutions is another complex subject.  The Android Developer site has several great guides include “ Supporting Multiple Screens ”  and “ Designing for Multiple Screens . Just Deal With It Detecting capabilities at runtime and writing your code to adjust accordingly is a good first step, but you can do more.  Rather than just failing gracefully if a feature doesn’t exist, I think you can go one step further by writing your application to adapt, or “deal with” whatever capabilities are present on a specific device. For example, the DX650 doesn’t have a GPS.  Is this a problem?  Not really.  GPS is a very low power signal and most GPS radios don’t work well or even at all indoors.  Also, a DX650 isn’t a mobile device, so exact location isn’t necessarily as important as it would be for other devices. But what if your application needs to know your location when recording some event, or because you want to show businesses nearby. Not a problem.  One of the Google services is a Wi-Fi based location technology, known as “Course Location” on Android.  Remember above when I said a device “must correctly report the sensors that it has”.  The DX650 reports Course location, but not Fine (GPS) location.  Applications can be written to use Fine Location, Course Location, or even both depending on what is available at runtime. Cisco DX650 Device specifics Now that you understand the potential problems and several solutions, it’s worth mentioning a few of specific characteristics of the DX650. Screen Size: 1024x600 Screen Density: 160dpi also known as mdpi Orientation: Landscape Cameras: 1 Front Facing Camera Sensors: None Location: Course/Network based only Conclusion Taking full advantage of the tools and APIs available in Android is key to writing stable, well-behaved applications that work on a variety of devices, now and in the future.  Even if you are only targeting a single device, like the DX650, I encourage you employ the best practices described above. ... View more

This blog was generated from CDN blog Created by: Matthew Williams on 28-03-2013 03:35:45 PM With the recent release of the Cisco Desktop Collaboration Experience DX650, it is important for us to clarify some of the differences that this product has over other generic Android Devices. One of these differences would be that it is connected to a Cisco Unified Communications Manager. With this connection, there are certain controls that the CUCM has over the device. These administrator controls give additional security to the DX600 Series products. Features Android Debug Bridge - ADB Allow Applications from Unknown Sources Allow Applications from Android Market Require Screen Lock Maximum Screen Lock Timeout Lock Device Wipe Device All of these controls can be changed by the system administrator of the CUCM the device is connected to. They can be accessed on the DX650 Device page. If you are the developer of an application that will be deployed on a DX650, make sure to notify users that they might need the system administrator to update these settings. For instance, if they are installing using the ADB, make sure it is enabled. Or perhaps your application is available on the Android Market, you would then need to make sure that the Android Market is enabled. Hopefully, having knowledge of these settings will save you from troubles you might encounter in the future. ... View more

This blog was generated from CDN blog Created by: Prince Woodrow on 26-03-2013 02:12:27 PM The Cisco DX650 Add-on contains sample projects designed to help you grasp some of the useful Cisco APIs. Read below for instructions on how to get your workspace set up to open these sample projects. Setup Cisco DX650 Add-on First, you must download and install the Cisco DX650 Add-on. Click here to download the "Cisco DX650 Add-on Installation Guide" (under the "Documents" section). NOTE: You must have the Android 4.0.3-4.0.4 (API 15) platform installed through the SDK Manager before installing the Cisco DX650 Add-on. Click here for more information on the SDK Manager. Opening Sample Projects Provided With Cisco DX650 Add-on 1. Open Eclipse. 2. Select "File > New > Other..." or press Ctrl+N on the keyboard 3. Select "Android Sample Project" and click "Next >" 4. Select the Cisco DX650 Add-on as your build target. 5. Select the sample to load into your workspace. 6. Optionally, give the project a new name in the "Project Name:" field 7. Click Finish. Sample Projects CreateCallSample: an example of how to create a call using the Cisco Telephony APIs. SamplePhoneListener: an example of how to detect and perform an action when a phone call ends. FrontCameraSample: an example of how to write an application that uses the front face camera on the Cisco DX650. Click here for more information regarding the front camera on the Cisco DX650. ... View more

This blog was generated from CDN blog Created by: James Catalano on 25-03-2013 10:45:01 AM Like many popular 7-inch Android devices on the market today, the  Cisco Desktop Collaboration Experience DX650 (or simply the Cisco DX650) has only a front-facing camera. This camera on the DX650 will primarily be used for video conferencing and other face-to-face collaboration, but it is obviously, because of the nature of Android, open to being accessed by developers through provided APIs. The API used to access the front-facing camera on the DX650 is the standard Android camera API. This means that the methods used to access the front camera on the DX650 is similar to (OK,  the same as) the way it is done on every other Android device with a front camera on the market. A front-facing camera isn't something that has been around since the beginning of Android. Neither the early Android devices nor the original iPhone for that matter had cameras on the front of the device, only on the rear for more traditional photo taking situations. It wasn't until Gingerbread (Android API level 9) that front-facing cameras were officially supported on Android. This means that Android's default implemenations for cameras on their devices revolved around back-facing cameras. Calling the default Camera.open() method will open a device's default back-facing camera. If a device doesn't have a back-facing camera, this method returns null, even if the device DOES have a front-facing camera. In order to open and use an Android device's front-facing camera (yes, this includes the DX650) you have to call a different version of the Android Camera open() method that takes a parameter referring to the "id" of the camera. But how do I know this "id", you ask? Well, the camera sample application included with the DX650 Add-on (available on this site) provides an example on how to find and open the DX650's front-facing camera. To sum it up in words, you can iterate through the device's cameras, check to see if they are front or rear facing, and select the first front-facing one you come across (you probably won't come across too many devices with multiple front-facing cameras). To sum it up in code, the following code snippet, which is also present in the sample app, shows how:  1 Camera.CameraInfo cameraInfo = new Camera.CameraInfo();  2 int cameraCount = Camera.getNumberOfCameras();  3 for (int i=0; i<cameraCount; i++) {  4     Camera.getCameraInfo(i, cameraInfo);  5     if (cameraInfo.facing == Camera.CameraInfo.CAMERA_FACING_FRONT && camera == null) {  6         try {  7             camera = Camera.open(i);  8         } catch (RuntimeException e) {  9             Log.e(LOG_TAG, "Camera failed to open", e); 10         } 11     } 12 } So now you know how to open the front camera on the DX650, but where do you put this code in your project? In our sample, we put this code in our sample Activity's onResume() method. While this is fine for basic implementations (like our sample) and facilitates code reuse, Android recommends that you open the camera on a separate thread launched from onCreate() . The Android Developer site's lesson on "Controlling the Camera" talks about this issue as well as others around controlling the camera. Also, the Android Developers' Camera overview gives a step-by-step walkthough of what your code needs to do to take a picture or record a video using the Android Camera APIs. With the information from these links and the sample application included in the DX650 Add-on, you should have no problem enabling the DX650's camera in your enterprise application. ... View more

This blog was generated from CDN blog Created by: David Lender on 25-03-2013 09:18:23 AM Here is an "as is" routine which will map a Connectio ... View more

This blog was generated from CDN blog Created by: Larry Michalewicz on 19-03-2013 11:25:17 AM Welcome to the DX600 Series Developer Experience! Today we announced our latest Video enabled Smart Desk Phone.  The Cisco Desktop Collaboration Experience DX650, or simply the DX650.  This device represents years of experience, knowledge, and technology delivered in a powerful and stylish desktop platform. Based on the Android Operating System, the DX650 provides  Cisco's high quality Voice and Video technolog plus all the richness of Android. Our team is here to help you create powerful applications for the DX650. Let us know what you think, tell us what you want to know.  We look forward to serving you! Sincerely Larry M and the rest of the Developer Experience team. @dxdevex ... View more

This blog was generated from CDN blog Created by: Amanda Whaley on 06-03-2013 10:28:02 AM Welcome to the HCS Developer Community!  Please have a look around, and subscribe to the blog for future updates. ... View more

This blog was generated from CDN blog Created by: Brett Tiller on 27-02-2013 12:56:48 PM There are limitations in SRE-V regarding tracking real time hardware events such as the failure of a hard drive.  The Service Ready Engine Virtualization platform (SRE-V)  has VMware ESXI 5.0 built into the platform which provides virtualization, and SRE-V installs onto the Service Ready Engine (SRE) service module .  ESXI utilizes a technology called CIM as well as SNMP with some limitations to track hardware events.  SRE-V uses a software RAID developed by Promise and the release implemented does not support CIM.  In addition, SRE-V does not support SNMP.  As a result we do not believe that the user can get notification of hardware events such as a disk failure on the SRE service module.  The alternative is to use the Promise CLI to check the raid status.  These CLI commands are documented in the SRE-V Installation and Configuration Guide in Chapter 7 titled "Managing RAID", and is located at: http://developer.cisco.com/web/srev/documentation . Another alternative is the UCS E-Series server which is the next generation service module released after the SRE.  This server plugs into the 29xx and 39xx routers and does support SNMP.  More information is available at http://developer.cisco.com/web/ucse . More information regarding ESXI CIM vs SNMP is provided here: http://www.vmware.com/files/pdf/techpaper/hwhm41_technote.pdf . ... View more

This blog was generated from CDN blog Created by: Adrienne Moherek on 10-01-2013 05:19:40 PM Check out the new content on the Cisco Developer Network reflecting the New & Enhanced features in Cisco Unified Communication Manager 9.1. See the new 9.1 SIP Documentation ... View more