Problems in CUCM 9 Installation

Problem 1: Stuck in Installing database component

During my CUCM 9.1 installation on a VMWare workstartion. The process stuck in Installing database component for more than a hour without any progress.


Read More »


Install CUCM 9.1 Boot error

Recently I got an ISO image for CUCM 9.1(UCSInstall_UCOS_9.1.2.12900-11.sgn.iso) and I intend to play around with it cause I have a project with a customer and he need to install CUCM on a UCS server. I tried to install it in my VMWare Workstation but I get the following error after I fire the VM.


it seems that the ISO wasn’t bootable…hmmm

Run Multiple CIPCs on Just One single PC

لقد هرمنا من اجل هذه اللحظة التاريخية…اه وربنا. اخيرا ممكن تشغل اكتر من

Ip communictor

علي نفس الجهاز (عشان تعمل فويس لاب) من غير متحتاج انك تسطب اكتر من فيرتشوال ماشين..اينعم في سوفتوير اللي هو

Ip blue

بيعمل نفس الوظيفة بس المشكلة انه مش فري وبيديك دقيقتين بس غير انه مش سيسكو 🙂

See the following link from cisco support forum

CCIE Lab is visiting Egypt!

انتوا عارفين طبعا ان لاب ال
عشان تمتحنه مالوش غير 3 اماكن..امريكا و دبي و المانيا تقريبا
فده بيخلي ناس كتير بتكتفي بس بأمتحان ال

بتاعه و تنفض للاب
بس فيه حاجة دلوقتي اسمها ال
Mobile Lab
سيسكو عملتها…كل مدة بتروح دولة معينة وتعمل فيها اللاب ده للي عايز يمتحنه
اللاب هو اللي هيجيلك لحد عندك :D…
سيسكو بدءت تضيف اماكن جديدة غير التلاتة دول…ومنهم مصر 🙂
ده جدول فيه مواعيد اللابات ال
في كل دولة وكل فترة بيتعمله تحديث

كان فيه لاب اتعمل في مصر في فبراير اللي فات…في الراوتينج والسيكيورتي…
السنة اللي جاية ان شاء الله هيبقي نفس اللاب ده هيتعمل في شهر مارس…فشدوا حيلكوا بأة للي عايز يحجزه


Unified Communication Servers 7.1 torrent

واخيرا…بعد ساعتين من البحث في جوجل (اللي بأة بالمناسبة وحش جدا في عرض نتايج البحث) لقيت فايل تورنت شغال لل

Cisco UCServers




seed 1

فادعوا ان الراجل ميدخلش ينام و يقفل جهازه ويلبسني في الحيطة


المشكلة ان سيسكو طقت في دماغها ان نسخة


متشتغلش علي بروسيسور



بعد كدة صلحت غلطتها في النسخة اللي بعدها



احدث نسخة..طالبين امكانيات خرافية…300 جيجا من الهارد و 16 جيجا رام و حاجات هموت قبل ماشوفها

فخلينا في نسخة


وناس كتير بتقول مفيش فرق اوي غير في حاجات بسيطة زي ال


Service Advertisement Framework

ده بروتوكول جديد عاملاه سيسكو بيسمح بأن ال

Phone Extensions



في ال


بتاعتك من غير متعملها انت كونفجريشن

حاجة كدة زي متكون مشغل ال


في النتورك عندك بس المرادي بدل مهو شايل النتوركس بأة شايل ال


بيوفر جدا في وقت الكونفجريشن

 عموما لينك التورنت اهو لو حد عايزه

Cisco Voice Multisite Design

1.Understanding Problem in multisite design and Finding Solutions


1.Quality of services and Bandwidth challenges

2.Availablity issues

3.Dial Plan madness (complexity)

4.Security and NAT hurdles (39bat)



1.Quality and Bandwidth challenges


Four main concern in bandwidth

1.Lack of bandwidth

You have a T1 line for both data and voice which isn’t enough


2.Packet loss



The packet takes LONG time to reach to other side (Cisco recommends that delay should be <150ms)



Every packet take variant times to reach to other side(100 ms for first packet, 190 ms for second packets and so on)


Solution for bandwidth challenges?



  1. Apply QoS(LLQ for voice, WFQ for data(telnet will get priority over Heavy file transfer) and finally a constant QoS for some services FTP(10% of BW) and HTTP(25% of BW) ).




Cisco best practice is that the priority queue should not exceed 33% of the interface bandwidth.


  1. Use Compressed Codecs to save bandwidth (on expense of DSP resources in your routers)
  2. RTP header compression (cRTP)






a voice packet for a call with the G.711 codec and a 20-ms Packetization(160 byte payload) period is being passed along a Frame Relay WAN link. The RTP frame has a total size of 206 bytes, composed of 6 bytes of Frame Relay header, 20 bytes of IP header, 8 of bytes UDP header, 12 bytes of RTP header, and a 160-byte payload of digitized voice. The packet rate is 50 packets per second (20 ms =50 pps), resulting in a bandwidth need of 82.4 kbps.

Note that when compressed RTP (cRTP) is used, the bandwidth is considerably reduced to 11.2 or 12 kbps


-if you combine the last two option, you will have 12 kbps for call instead of 80 kbps (amazing)


  1. Use the Local Resources (Annunciator,Conference,Bridge,MTP and MOH)



you don’t have to cross the wan to get the annunciator voice or MOH from the main CUCM, get it from your local router at office


  1. Transcoders
  2. Limit the WAN calls

once the call reach to certain amount, divert to PSTN networks. (remember the Cisco best practice is voice activity should not exceed 33% of your wan link)


2.Availablity Issues (first problem is lack of BW)


The redundancy low: two is one, one is none!


Solution for Availability Issues?


1.PSTN failover



2.MGCP fallback and SRST

Allow the local router to work as SRST router when the wan link is down between it and MGCP master server


3.Forwarding calls for unregistered phones

When wan link is down, you can instruct the CUCM to route the incoming calls to the cell phone of the users not to their desktop phone.(simple to provision feature)


4.Automated Alternate Routing(AAR)

5.Mobility Options



3.Dial Plan Issues




-Overlapping in dial peer is just like duplicate IP address but with the solution: SUBNETTING in routing and switching and partitioning plus site codes in dial peer


-DID will allow you to dial from PSTN directly to inside of your network but this will add headache in mapping with internal extension, you may decide to lose this in favor of having receptionist or IVR system to handle the incoming calls from PSTN


-TEHO allows you to route the calls through WAN to far location which is connected to PSTN. Then you’re able to make cheap and local calls





Solution for Dial Plan complexity?


Plan plan plan plan…




4.NAT and Security Issues




Solution for NAT and security issue?

Use CUBE as an application proxy



Flow through mode will terminate all CUCM signaling and RTP message at the edge of UDP and repackage them to outside network (ITSP network)





When CUCM wants to signal calls to the ITSP, it does not send the packets to the IP address of the ITSP (IP address B). Instead, it sends them to the internal IP address of the CUBE( via a SIP trunk configuration. CUBE then establishes a second call leg to the ITSP using its public IP address A as the source and IP address B (ITSP) as the destination. As soon as the call is set up, the CUBE terminates RTP toward the ITSP using its public IP address and sends the received RTP packets to the internal IP Phone using its internal IP address. This solution allows CUCM and IP Phones to communicate only with the internal, private IP address of the CUBE. The only IP address visible to the ITSP or anyone sniffing traffic on the outside is the public IP address of CUBE.



Flow-around: In this mode, only signaling is intercepted by CUBE. Media exchange occurs directly between endpoints (and flows around CUBE). Only signaling devices (CUCM) are hidden from the outside.



*Summary of Solutions