CAC - Call Admission Control
CAC is a bandwidth management and safe guarding call quality feature in Lync 2010. CAC allows A/V calls to be established between endpoints only if there is sufficient bandwidth on a network link, as configured by the administrator. The calls will either be allowed or rerouted via PSTN line or will be blocked, as configured.
5 Steps to configure CAC
1. Create and apply bandwidth Policy -CSCP > Network Configuration > Global > Policy Profile
2. Define Network region i.e. the central site (Regions and sites can be visualized as in the topology builder as main site and branch sites) make sure you enable the "Enable audio alternate path" option.
CSCP > Network Configuration > Region
3. Create the site - CSCP > Network Configuration > Site >
4. Assign subnet to sites creates in step 4 - CSCP > Network Configuration > Subnet > provide the Subnet, Mask and select the Site
Optional: If you have multiple Regions, you need to do two things. First, you need to create a Region link stitching together both Regions (i.e. Canada_to_USA_Region_Link). Second, you must create a Region Route even if you have only one Region Link....more on this later.
Enable audio alternate path in your Region
5. Final Step, Enabled CAC - CSCP > Network Configuration > Global > Enable CAC
CSCP > Voice Routing > Voice Policy > Enable PSTN reroute on your voice policy for your users
So with all this configured, let's talk about what happens when you call someone over a link which is bandwidth constrained, has a CAC policy, and doesn't have enough bandwidth. Here's the story: Jason is in Edmonton where he has a Survivable Branch Appliance Gateway. Anton is in Calgary where he sits next to the Front-End server, Mediation Server, and a Direct SIP connection to Cisco Call Manager. Both Edmonton and Calgary are connected by a WAN link which is limited to 10Mb. Jason has a voice policy with the "Enable PSTN reroute" option set to 'enabled' and the "Enable bandwidth policy override" option set to 'disabled'. Jason calls Anton using his Lync 2010 client. Both users are in the "Canada" Region which has the option for "Enable audio alternate path" enabled. The Canada Region contains both the Calgary and Edmonton Site. The Edmonton site has a bandwidth policy which, based on current bandwidth consumption, is fully consumed. This would normally prevent the call from proceeding. Instead of the CAC policy stopping the call or sending it to Anton's voicemail, the call is rerouted out Jason's local PSTN gateway as configured in his Lync Server topology. Nice eh? Well what happens if "Enable PSTN reroute" isn't turned on in Jason's voice policy? Well the call would end up being answered by Exchange UM or simply denied with a message being displayed to the user. What if Jason's voice policy has "Enable bandwidth policy override" turned on? Well the call would proceed over the WAN without obeying the CAC policy. You may want to enable this option for special voice policies tied to certain staff members. What if Anton's voice policy doesn't have the "Enable bandwidth policy override" turned on and Jason calls him and his IS turned on? Well the call will be denied as CAC works both ways. The only way for the call to proceed is if Jason's policy permits PSTN reroute. Now I'm still learning the underlying framework here and a lot of the "how it works" along with answers to questions in my head remain unanswered. I'll update this post with more detail as it becomes available.
Media Bypass and CAC, how they work together
CAC and MEDIA BYPASS
Media bypass it's a feature in lync 2010 which allows the media to flow directly between the clients and pstn gateways.
The signalling will always go via the mediation server and the actual media will bypass the mediation server
There is a bypass id assigned globally or per network site. If the bypass id is exchanged between the client and the mediation server and if the id's match, each other media bypass is possible.
How to enable media bypass cscp > network configuration > enable cac
During whose ocs days all the pstn bound calls had to go via the mediation server and the mediation server used to:
remove the encryption from the sip packet, convert from RT audio to G711 (transcoding) and vice viceversa. all these adds latency, jitter, packet loss, etc. & to tackle this and improve voice quality in lync 2010 media bypass was introduced. This enables the lync endpoint that is the lync client to directly talk to gateway that is the lync client can talk in G711
Media bypass is not limited only from end user to gateway but also if a call from end user to another user who is using voip phone by way of ip pbx within the organisation.
But remember the signalling will always go via the mediation server and the actual media will bypass the mediation server or ip pbx.
Media bypass requirement
====================
The next hop of the mediation server should be able to handle multi forked responses, and the next hop must be able to accept traffic directly from the Lync client.
=======================================================================
CAA – Conferencing Announcement Application –
Plays tones and prompts to PSTN participants on certain actions, such as when participants join or leave a conference, someone enter the conference lobby, or the conference is locked or unlocked. Conferencing Announcement also supports dual-tone multifrequency (DTMF) commands from the phone keypad. Conferencing Announcement is automatically installed and activated by default when you deploy a Conferencing workload and select the dial-in conferencing option.
Conferencing Attendant application – Please enter your conference ID…. (if this service is stopped users will not be able to join the conference)
Tools to use for connectivity issues:
ICE WARN Decoder
TURN SERVER=EDGE SERVER
CANDIADTE LIST
Peer to Peer = Local
Host = Local Machine's IP
Srflex IP = If you are at home, then it is the public IP of you DLink, etc. Router
Relay = The EDGE server's public or the Natted public IP
First the UDP port 3478 is tried if it does not works then TCP port 443
ICE uses two other Protocols to find and establish a suitable media path for a call, those Protocols are:
in a Lync deployment, STUN server or TURN server is always the Lync Edge server (A/V Server)
> Host or Local Candidate – The actual IP address bound directly to the remote client’s host operating system. This could include multiple candidates as the remote host could contain multiple physical or virtual network adapters including any active VPN clients. Most often this will be a single IP address of the active interface on a Lync client’s workstation.
> Reflexive or STUN Candidate – The public IP address assigned to the client’s immediate firewall perform network address translation. In most home networks this would be the public IP addresses assigned by an ISP (either dynamically or statically) to the premises modem or router, depending on the type of service.
> Relay or TURN Candidate – The publically accessible IP address assigned to the media relay server which is allocated to the client. In Lync Server this is the public IP address assigned either directly to the external A/V Edge interface or the public IP address allocated to a NAT device (e.g. firewall) which is performing static network address translation to a private IP address assigned directly to the Edge Server. In the event that an Edge Pool is deployed then this would be the IP address of one of the individual servers in the pool.
No comments:
Post a Comment