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

 

3.Delay

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

 

4.Jitter

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) ).

 

clip_image001

 

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)

 

clip_image002

 

clip_image003

 

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)

clip_image004

 

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

clip_image005

 

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

 

clip_image006

 

-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

 

clip_image007

 

 

Solution for Dial Plan complexity?

clip_image008

Plan plan plan plan…

 

 

 

4.NAT and Security Issues

 

clip_image009

 

Solution for NAT and security issue?

Use CUBE as an application proxy

clip_image010

 

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

clip_image011

 

 

 

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(10.3.1.1) 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

clip_image012

 

Advertisements

Share you opinion to benefit others :)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s