Blogs

Use your WAN not the Carrier for your Remote Site

Replace your Carrier Remote or Mini Carrier Remote with an Avaya Survivable Media Gateway (SMG). The SMG connects to your main PBX through the corporate WAN. Furthermore, the SMG will operate in survival mode during a WAN failure. During a network failure, the SMG will support phone operation by engaging its own CPU. This is something your Carrier Remote cannot do. In addition, the SMG is IP based which means it will register with your main-site PBX. Therefore, if you are paying a T1 carrier in order to support your Carrier Remote or Mini Carrier Remote Cabinet, upgrade your main site to Avaya release 7.6 and install a Survivable Media Gateway.

“Survivable Media Gateway enhances the reliability of Avaya Communication Server 1000E (Avaya CS 1000E) systems by allowing the provisioning of up to 50 geographically remote Secondary Call Servers to a Primary Call Server. You can configure each Secondary Call Server as Alternate Call Server 1 or Alternate Call Server 2 for the devices assigned to it. Survivable Media Gateway provides two levels of redundancy. If the Primary Call Server fails, local and remote resources register with the Secondary Call Server configured as Alternate Call Server 1. If the Primary and Secondary Call Servers both fail, or the WAN fails, local resources register with the Secondary Call Server that is installed at the local site and configured as Alternate Call Server 2.”

Reference: NN43001-507_06_01_System_Redundancy_Fundamentals

nortelcertifiedsupportexpert

 

Enabling AACC Shadowing After 24 Hours

If your standby server has been out of synchronization for more than 24 hours, you will need to complete the following process to restart AACC 6.4 shadowing. Otherwise, the standby server will fail to synchronize with the active AACC server. Execute one restore at a time; i.e. ADMIN, CCMS, and CCT.

The procedure listed below avoids corrupting the standby server’s Backup Locations Directory by restoring one database at a time:

  • Make sure you have a recent backup from your active server; preferable located somewhere off the active and standby servers.
  • Map the active AACC server backup database folder onto the standby server.
  • On the active AACC server, run a full database backup.
  • Copy the UNC backup path on the active server into the standby server’s restore UNC path (\\Computer Name (or IP address) \ Backup Location).
  • Navigate to the standby server’s Database Utility / Database Maintenance window.*** Do not attempt to restore all three “ADMIN, CCMS, and CCT databases at the same time. This can cause corruption within the standby server’s Backup Locations directory. ***
  • Restore the standby server by first running the ADMIN database only.
  • Once the ADMIN restore is complete, verify the UNC path is correct. Adjust as necessary.
  • Restore the CCMS database. Note: the CCMS database is the largest out of three restores.
  • *** The CCMS database will restore the active server’s AACC name and IP information into your standby server. However, it will not change the actual IP address in the standby server’s network properties located in the control panel. ***
  • Open the standby server’s “Server Configuration” window located in Manger Server.
  • Adjust the standby server’s local settings to the correct name and IP addressing. *** Do Not Restart the Standby Server. ***
  • Click on the Licensing tab to correct the location of your license file on the standby server. . *** Do Not Restart the Standby Server. ***
  • Finally yet importantly, run the CCT database restore on the standby server.
  • Do not restart server.

You can now open the High Availability window on the standby server, double click System Control, select Shadowing, click start, and save. The log file will now show actively shadowing from the active server. You will notice a continuous flash on both servers if your server’s NIC cards contain LED lights.

Reference: https://support.avaya.com/documents/Avaya Aura Contact Center

nortelcertifiedsupportexpert

 

 

If additional assistance is required, please call 301.873.0080 or email at mnicholson@ashburnconsulting.com

Cisco XR IOS Code Upgrade

Summary of XR IOS Code Upgrade:

1.Download the correct image tarball from cisco.com. The image cannot be used as-is. The CCO image tarball for Release 4.3.4 (Cisco recommended) must be downloaded first and only relevant Packages Installation Emvelope (PIEs) or Software Maintenance Upgrade (SMUs) must be taken for use on the router.

2. Before upgrading to the new code, all the mandatory SMUs required to be active in the current release must be installed. For example we are upgrading from code 4.2.3 to 4.3.4 and required SMU for upgrade are:

  • CSCud98419
  • CSCud37351
  • CSCud54093

Here is the table with Mandatory SMUs: Mandatory SMUs.png. These mandatory SMUs are available in the downloaded tar file.

3. First copy SMUs to USB drive. USB drive on the ASR9000 use disk1: slot. You should see all SMUs on disk1:

RP/0/RSP0/CPU0:XR-2#dir disk1:
Fri May  2 18:08:27.040 est
Directory of disk1:
131616    -rw-  52518619    Tue Dec 18 19:48:48 2012  asr9k-p-4.2.3.CSCud37351.pie
131936    -rw-  40910815    Thu Jan 10 06:52:20 2013  asr9k-p-4.2.3.CSCud54093.pie
132448    -rw-  724868      Fri Feb  1 23:35:02 2013  asr9k-p-4.2.3.CSCud98419.pie

4. Add and activate the required SMUs. By default, they are added to installed to disk0:. All add and install operations should be performed in the admin mode.

(admin)#install add disk1:asr9k-p-4.2.3.CSCud37351.pie disk1:asr9k-p-4.2.3.CSCud54093.pie disk1:asr9k-p-4.2.3.CSCud98419.pie active


You can list all the SMUs in one line divided by space. The installation will be performed on the background. If you want to see the install status, issue the command:

show install request

If you actually want to see the full installation process, add “synchronous” at the end of the install request:

install add disk1:asr9k-p-4.2.3.CSCud37351.pie active synchronous

5. After install finished, make sure that SMUs are active now:

(admin)#show install active
Fri May  2 18:28:30.921 est
Secure Domain Router: Owner

  Node 0/RSP0/CPU0 [RP] [SDR: Owner]
    Boot Device: disk0:
    Boot Image: /disk0/asr9k-os-mbi-4.2.3.CSCud54093-1.0.0/0x100000/mbiasr9k-rp.vm
    Active Packages:
      disk0:asr9k-p-4.2.3.CSCud37351-1.0.0
      disk0:asr9k-mini-p-4.2.3
      disk0:asr9k-p-4.2.3.CSCud98419-1.0.0
      disk0:asr9k-p-4.2.3.CSCud54093-1.0.0

6. Commit the install. After commit, router will reboot automatically:

   (admin)#install commit

7. After reboot, login and add/activate all required PIEs with new code 4.3.4. mini.pie is mandatory and consist of several packages required to run the router. All other packages are for additional features (mpls, multicast, security, management, etc)

All the packages specified in the install command must match older version packages already installed on the router. Although it is not possible to upgrade with lesser number of packages than these installed, it is ok to install additional packages.

(admin)#install add disk1:asr9k-mini-px.pie-4.3 disk1:asr9k-mpls-px.pie-4.3 active synchronous

You can add and activate multiple PIEs in one command. Just list them separated by space.

After installation complete (may take 10-30 minutes), router will reboot automatically.

8. After reboot – commit the install:

(admin)#install commit

9. Verify that proper set of PIEs are active now. Old code PIEs are automatically deactivated:

(admin)#show install

10. Verify the new IOS XR version:

(admin)#show version

11. Verify that all the nodes are in “IOS XR RUN” state, SPAs in “OK” state, Fan Tray and Power Modules are in “READY” state:

(admin)#show platform

12. Upon successful upgrade checks for package and image integrity. Any found issues must be repaired using the command: “install verify package repair”.

(admin)#show install verify packages

13.  Once software upgrade or downgrade has been completed, disk space can be recovered by removing any inactive packages that are no longer needed (if the packages are required at a later time, they can be re-added)

How to encode video and screencasts optimally for the web using Handbrake

What format should you use when you make video for the web? MP4

It is important to optimize your video for web use especially for our internal use using ACTube. Non-optimized video formats and settings can cause video pauses and stuttering.

Notice that when you upload a video to YouTube or Vimeo, they transcode and prepare the video in some way that it is web optimized. There are some very good reasons for self-hosting our videos.  One reason is security for some videos that we don’t want to make public.

Handbrake is free software you can use to make web video optimized for self hosting. Handbrake does a good job in making sure self-hosted web videos are compatible with virtually all platforms.

Quicksteps for settings optimizing web video using the free Handbrake software

  1. Preferences menu.  De-select the option for “Use iPod/iTunes friendly (.m4v) file extension for MP4″
  2. Main window.
    1. Choose the Source button.  Select the video you want to optimize for the web.
    2. Under Format.  Choose “Mp4 file.”
    3. Choose (enable) the Web Optimized checkbox.
  3. Main window / Video tab.
    1. Under Video Codec, choose “H.264″
  4. Main window / Audio tab.
    1. Under Bitrate, choose 128.
  5. Main window / Advanced tab.
    1. Next to Reference Frames, choose “4.”
  6. Back to Main window / Video tab.
    1. In the Quality section, choose Average bitrate.  Use the following rules of thumb to set bitrate value:
      1. For screencasting / screencast recordings:  use 600
      2. For live action videos / “talking heads”:  use about 800 to 900
    2. Enable the checkbox labeled “2-pass encoding”
  7. Main window:
    1. In the Destination field, choose the folder where you want your converted (transcoded) file to be stored.
  8. In the tool bar, choose “Start.”

HTTP Video Streaming

Most video streams through a corporate network are using the Real Time Messaging Protocol (RTMP).  The key thing to know about RTMP is that it is different from Hypertext Transport Protocol (HTTP), the common protocol that is used to deliver Web content to your browser. In other words, a lot of video in your enterprise streams using a protocol that is not like the one that the vast majority of content in your network is using to get moved around.

Why does this matter? Chances are, if you work in a large enterprise, your network has all kinds of devices and infrastructure to speed up and optimize the flow of information traveling with HTTP. You will have all manner of caching devices, WAN accelerators, and so forth, to enable rapid and efficient transport of HTTP data all over the globe. Can RTMP video take advantage of that infrastructure? It will be tough.

For this reason, if you can enable HTTP video streaming in your enterprise, you can power better delivery of video across your network. This mostly applies to video on demand (VOD). When users in your enterprise need to access VOD material, if it can stream with HTTP, the video content can be cached and optimized all over the place. This could be more beneficial than other video streaming mediums.