Posts

Showing posts from 2016

AnyConnect VPN DTLS vs TLS

Difference
DTLS is used for delay sensitive applications (voice and video) as its UDP based while TLS is TCP based DTLS is supported for AnyConnect VPN not in IKEv2
How it works?
SSL−Tunnel is the TCP tunnel that is first created to the ASAWhen it is fully established, the client will then try to negotiate a UDP DTLS−TunnelDuring DTLS negotiation, traffic will be passing over TLS tunnelWhen the DTLS−Tunnel is fully established, all data now moves to the DTLS−tunnel and the SSL−tunnel is only used for occasional control channel trafficIn case of failures in establishing DTLS Tunnel, traffic will continue passing over TLS tunnelAfter establishing DTLS, in the event of failure in DTLS Tunnel, traffic will pass over TLS tunnel until DTLS tunnel is reestablished
How Data is Forwarded?
For each packet there is a part in AnyConnect client code which decides whether to send the packet over TLS or DTLSIf the DTLS tunnel is established, …

The Importance of Understanding MTU value in AnyConnect VPN

Why do we need it?
During encryption, additional overhead will be added to the packets made by new headers and features. This means that the actual size of the unencrypted TCP segment or UDP datagram which holds the application will be reduced because the MTU of the adapter is still same.
For example with Ethernet and MTU of 1500-bytes, the unencrypted TCP segment can't be more than 1460-bytes. With encryption, for Ethernet and MTU of 1500, the unencrypted TCP segment can't be more 1380 (can be different value). The 80-bytes difference are utilized by encryption overhead.
Now the value of unencrypted TCP segment can be more which leads to MTU more than 1500-bytes but this will cause the networking devices to fragment the packet which is bad and should be avoided.
AnyConnect client builds Virtual Adapter (VA) during installation on the clients machine. This VA will receive unencrypted traffic and emulates Ethernet to forward traffic after encryption. The actual traffic then g…

QoS Enhacements in CUCM 11.X

Image
These were added in CUCM v11The main enhancements are:Separating UDP Port Ranges for Audio and VideoSeparating DSCP Markings for Audio and Video streams in Video Calls You can have separate markings for audio in Telepresence video call than Fixed video callNavigate to Device > Device Settings > SIP Profile. Current endpoints which support this enhancement (03/11/2016)Video Endpoint DSCP for Audio Portion of Video Calls DSCP for Audio Portion of TelePresence Calls 8800 Series Yes N/A 8900 Series No N/A 9900 Series No N/A Jabber Yes (Jabber for Windows uses Group Policy Objects to mark traffic on the PC else DSCP will be set to '0'. All other Jabber clients are able to mark DSCP natively) No DX Series Yes Yes TX Series N/A Yes IX Series N/A No CE 8.x Software Series (SX Series, MX Series G2, MX700, MX800) N/A Yes TC 7.1.4 Software Series (C Series, Profile Series, EX Series, MX Series G1) N/A Yes

Enable DSCP Markings on Windows OS (7, 8, 10)

By default windows OS will set DSCP markings to '0' ignoring the marking settings on the client. This can be good and bad.

A good scenario is to make sure that torrent clients aren't getting priority (while ideally your enterprise network qos policies should overcome this problem as well)

A bad scenario is overriding DSCP markings from Jabber Client which marks packets genuinely  for seperating audio and video streams treatment.

While you can still overcome the problem of Jabber Client using network QoS policies, you can allow QoS marking on windows OS as follow:

1. Go to HKLM\System\CurrentControlSet\Services\Tcpip\QoS. If "QoS" folder doesn't exist there - create it. 2. Add a DWORD parameter named "Do not use NLA" and assign "1" as its value. 3. Reboot.


Notes on Self-Service ID

The Self-Service User ID is generate automatically once the primary extension is assigned to the End UserThe Primary extension can be assigned manually, using LDAP or using BATFor LDAP Self-Service IDs it will be generated during the 1st LDAP sync (not on LDAP update)Self-Service ID will be generated only if the user doesn't have oneFor upgrades from Pre-10.x to 10.x, Self-Service ID will be generated for users with Primary ExtensionsWhen same DN is assigned to multiple partitions and to multiple users as primary extension, Self-Service ID will be made unique by prefixing a code of *01, *02, etcYou can change the Self-Service ID, manually from End User configuration page

LDAP Enhancements in CUCM

CUCM can synchronize users and groups from LDAPIntroduced in version 11LDAP Filter can be created for users and groupsPrimary use to have Active Directory groups available in the Cisco Jabber contact listCUCM can assign Access Control Groups to LDAP users from synchronization AgreementCUCM can assign Feature Group Template to LDAP users from synchronization AgreementThis will assign User Profile to synched user which includes UDT and ULTThis will assign Service Profile to synched user which include UC Services (IMP, CUC, etc for jabber)This will configure user settings such as Enable Mobility, Enable EMCC, Allow End User to Host Conference NowThis will allow user to run Self-ProvisioningCUCM can create DNs for LDAP users and assign them as primary extension using the option Apply mask to synced telephone numbers to create a new line for inserted usersThe DNs will be based on the TelephoneNumber or…

CUCM Self-Provisioning

This feature allow end-users or administrators to provision phones with minimum admin workIt was introduced with CUCM 10.xThe users need to follow the prompts on the phones to login to CUCM which will auto-provision the phonesHow it works?The phone auto-registers with CUCMDuring auto-registration it gets an idle URL. This idle URL points the phone to self-provision XPS resource running on CUCMOnce the phone contacts the XPS resource, it will be prompted for user ID/pinFrom here there are two approaches to complete Self-ProvisioningOption#1When the users enter the user ID and PIN, they are authenticated with the CM and their primary extension is determinedThe users are then prompted to confirm that they wish to provision the phone using their primary extension. If they confirm, the phone will be provisioned and resetOption#2The users can call Self-Provision IVRThe users need to enter …

Summary of CUCM Supported Codecs

I just thought to put a summary list of CUCM supported codecs


G.711: It has two versions, A-Law & Mu-Law. You can disable CUCM support for G711 using the service parameter G.711 mu-law Codec Enabled or G.711 a-law Codec EnabledG.722: This is wideband codec that is always preferred by CUCM over G.711, unless Advertise G.722 Codec enterprise parameter is Disabled.
Enterprise Parameter Setting Phone (Product-Specific) Parameter Setting Phone Advertises G.722 Advertise G.722 Codec Enabled Use System Default Yes Advertise G.722 Codec Enabled Enabled Yes Advertise G.722 Codec Enabled Disabled No Advertise G.722 Codec Disabled Use System Default No Advertise G.722 Codec Disabled Enabled Yes Advertise G.722 Codec Disabled Disabled No
When users use a headset that supports wideband, they can enable Wideband Headset feature from the phone settings for better quality. On the phone navigate to Settings > User Preferences > Audio…

MoH Combined with other Media Resources

As we mentioned earlier MOH uses G711 is the only supported codec by default (other codecs can be enabled from IPVMS service parameters). Let’s assume the following scenario, HQ-Region (which contains HQ-Phones, HQ-Servers, HQ-MediaResources) and BR1-Region (which contains BR1-Phones, BR1-MediaResources). In case HQ-Region to BR1-Region codec definition is G729 (and vice versa) and MOH Server at HQ site should be used by BR1-Phones, then how MOH will work?? NOTE: Here we are assuming that BR1 Phones are registered with HQ CUCM, i.e. no trunks are available between sites. The simple way is to enable G729 codec for MOH Server from IPVMS service parameters. The other way is through XCODER. When MoH is invoked CUCM will realize that MOH is using G711 while the inter-region configuration should use G729. Therefore, it will invoke XCODE based on MoH MRGL. MOH MRGL can be assigned to MOH Device Pool; else MOH will pick XCODE from the null group. NOTE: When CUCM invoke MOH, new call negotiat…