CCIE Voice Lab Exam v3.0 Topics (blueprint)

The blueprint is a detailed outline of the topics likely to appear on the lab exam. This blueprint introduces pre-configurations of basic tasks (such as phone registration, basic application integration, basic dial plan, etc.), in order to devote additional focus on expert level skills (advanced configuration and troubleshooting) assessments. As usual, knowledge of troubleshooting is an important skill and candidates are expected to diagnose and solve issues as part of the CCIE lab exam. The topics listed are guidelines and other relevant or related topics may also appear.

1.00
Implement and Troubleshoot Campus Infrastructure and Services
1.01
VLAN
1.02
DHCP
1.03
TFTP
1.04
NTP

2.00
Implement and Troubleshoot CUCM Endpoints
2.01
CUCM SCCP Endpoints
2.02
CUCM SIP Endpoints

3.00
Implement and Troubleshoot CUCME Endpoints
3.01
CUCME SCCP Endpoints
3.02
CUCME SIP Endpoints

4.00
Implement and Troubleshoot Voice Gateways
4.01
T1/E1 PRI
4.02
T1/E1 CAS
4.03
H.323
4.04
MGCP
4.05
SIP
4.06
H.323 RAS
4.07
IP-IP Gateway/CUBE

5.00
Implement and Troubleshoot Call Routing Policies
5.01
Route Patterns and Dial-peers
5.02
Digit Manipulations and Translations
5.03
Class of Services
5.04
Route Selection Preference and Redundancy
5.05
Mobility and Single Number Reach

6.00
Implement and Troubleshoot High Availability Features
6.01
SRST
6.02
AAR

7.00
Implement and Troubleshoot Media Resources
7.01
CODEC Selection and Flexibility
7.02
Conference Bridges
7.03
Transcoder
7.04
Music-on-hold
7.05
Media Resources Preference and Redundancy
7.06
Other CUCM Media Resources

8.00
Implement and Troubleshoot Supplementary Services
8.01
Call Park
8.02
Call Pickup
8.03
Barge
8.04
Callback
8.05
Other Supplementary Services

9.00
Implement and Troubleshoot Other CUCM Voice Applications
9.01
Extension Mobility
9.02
IPMA
9.03
Other CUCM Voice Applications

10.00
Implement and Troubleshoot QoS and CAC
10.01
L2/L3 Traffic Classifications and Policing
10.02
L2/L3 Queuing Mechanisms
10.03
L2 LFI
10.04
RSVP
10.05
Call Admission Control

11.00
Implement and Troubleshoot Messaging
11.01
Cisco Unity Connection
11.02
Cisco Unity Express
11.03
Call Handling and Routing

12.00
Implement and Troubleshoot Cisco Unified Contact Center Express
12.01
Advanced Configuration
12.02
Script Customization
12.03
Redundancy

13.00
Implement and Troubleshoot Cisco Unified Presence
13.01
CUCM Presence
13.02
Cisco Unified Presence Server Integration

CCIE Voice LAB Equipment and Software list

CCIE Voice Lab v3.0 Equipment and Software List
Passing the CCIE Voice Lab Exam requires a depth of understanding difficult to obtain without hands-on experience. Early in your preparation, you should arrange access to the equipment listed below:

Lab Equipment:
Cisco MCS-7845 Media Convergence Servers
Cisco 3825 Series Integrated Services Routers (ISR)
Cisco 2821 Series Integrated Services Routers (ISR)
ISR Modules and Interface Cards+ VWIC2-1MFT-T1/E1 - PVDM2 - HWIC-4ESW-POE - NME-CUE
Cisco Catalyst 3750 Series Switches
IP Phones and Soft Clients

Software Versions
Any major software release which has been generally available for six months is eligible for testing in the CCIE Voice Lab Exam.
Cisco Unified Communications Manager 7.0
Cisco Unified Communications Manager Express 7.0
Cisco Unified Contact Center Express 7.0
Cisco Unified Presence 7.0
Cisco Unity Connection 7.0
All routers use IOS version 12.4T Train.
Cisco Catalyst 3750 Series Switches uses 12.2 Main Train

Network Interfaces
Fast Ethernet
Frame Relay
Telephony Interfaces
T1
E1

CUCM common ports list

 

Reference:

Full list can be found here

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/7_0/CCM_7.0PortList.pdf

UNITY PIMG Integration

PIMG Integration

Unity 4.0(4) introduces support for a new device called PIMG (PBX/IP Media Gateway) that takes advantage of the Unity SIP interface. PIMG replaces the voice board as the means for Unity to integrate with legacy PBX systems. Rather than connecting lines from the legacy PBX system to a voice board installed in the Unity server, lines from the legacy PBX system are connected to the PIMG and Unity communicates with the PIMG over the network using SIP. With the PIMG integration, a voice board is no longer installed in the Unity server. Many of the PBX-specific parameters that were previously configured on the Unity server (mostly in the switch file) are now configured on the PIMG, albeit under different headings. As of Unity 4.0(4), one PIMG can support up to eight Unity voice ports. Multiple PIMGs can be configured with Unity to scale to a higher number of voice ports.

PIMG translates call-control commands from the PBX into SIP and sends these SIP messages to Unity. Likewise, PIMG translates SIP messages from Unity into call-control commands that the PBX can understand. Because the PIMG integration relies on Unity's SIP interface, much of the discussion in the previous section about SIP methods, digit generation and detection, and media-format negotiation apply to the PIMG integration as well. One SIP method that is not used with the PIMG integration is REGISTER. PIMG is configured with the IP address of the Unity server, so it knows where to send SIP messages destined for Unity. Because of this, there is no need for Unity to advertise its IP address using REGISTER. Figure 17-29 is an example call flow for a call setup between a phone on the legacy PBX system and Unity, via PIMG.

Notice that the SIP call flow between Unity and PIMG is the same as the call flow shown in the previous section, "SIP Methods used by Unity." Because the PIMG integration is new with Unity 4.0(4), Unity using PIMG does not yet support all of the legacy PBXs that Unity using a voice board can support. However, it is expected that the PIMG integration eventually will allow Unity to communicate with the entire currently supported legacy PBXs. In addition, PIMG opens the door to digital integrations with legacy PBXs that were previously not possible. In general, digital integrations to PBXs are considered more efficient and feature-rich than analog integrations to the same PBX. With PIMG, Unity will eventually support digital integrations to widely deployed PBXs like Nortel Meridian, Avaya Definity, and Siemens HiCom 300, among others. Another benefit of using PIMG with Unity instead of using voice boards is that Unity no longer needs to be collocated with the PBX. This allows for more easily managed systems, where several Unity servers could potentially be located at a central site, and each of these Unity servers could service a different legacy PBX at a remote site.

Reference:

Cisco Unity deployment and solution guide

Cisco Unity PBX IP Media Gateway

Troubleshooting Echo Problems between IP Phones and IOS Gateways

 

Introduction

This document describes how to troubleshoot and eliminate echo where possible in IP Telephony networks with Cisco IOS® gateways.

There are two sources of echo:

• Hybrid echo

• Acoustic echo

Hybrid echo is caused by an impedance mismatch in the hybrid circuit, such as a two-wire to four-wire interface. This mismatch causes the Tx signal to appear on the Rx signal.

Acoustic echo is caused by poor acoustic isolation between the earpiece and the microphone in handsets and hands-free devices.

Echo is perceived as annoying when all of these conditions are true:

• Signal leakage between the analog Tx and Rx paths.

• Sufficient delay in echo return.

• Sufficient echo amplitude.

Echo in Packet Voice Networks

The packet segment of the voice connection introduces a significant delay (typically 30 ms in each direction). The introduction of delay causes echoes (from analog tail circuits), that were normally indistinguishable from the side tone, to be now perceived by the user.

The delay introduced by packet voice is unavoidable. Therefore, the voice gateways must prevent the echo. This diagram illustrates how the gateway can reduce the echo before it can enter the packet voice network with the use of an echo canceler.

Refer to Echoed Voice for more information on echo in voice networks.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

PSTN Phone User Hears Echo

The problem exists when the PSTN phone user hears echo which is caused by acoustic coupling between the earpiece and the microphone in the IP phone handset.

The solution is to use a load ID on the IP phone, which includes echo suppression on the handset and headset. Currently, available load IDs only include echo cancellation on the speaker phone. However, there are some known issues such as talker echo and acoustic echo from IP phone to IP phone with an older load ID. Refer to Release Notes for Cisco IP CallManager Firmware for 7960, 7940, and 7910 Series Phones if you experience such issues in order to decide if an upgrade to the latest load ID can resolve the issue.

IP Phone User Hears Echo

The problem exists when IP phone users hear echo caused by hybrids in a PSTN network.

The solution is to configure and verify echo cancellation operation on a Cisco IOS gateway. The echo canceler in the voice gateway cancels the echo heard by the IP phone user.

Troubleshoot Echo in Gateways with Cisco IOS Software Releases 12.4

Intermittent echo can be heard on voice gateways that run Cisco IOS Software Release 12.4 with DSPWare 4.4.13 or 4.4.14. This is a known issue documented in Cisco bug ID CSCsd54344 ( registered customers only) . In order to resolve this issue, you need to downgrade DSPware to 4.4.12 or earlier. Contact the Cisco Systems Technical Assistance Center (TAC) in order to obtain assistance in downloading the DSPware image.

Hardware ECAN (MFT-EC-32/MFT-EC-64) on VWIC2-xMFT-T1E1 does not cancel voice echo. This is a known issue documented in Cisco bug ID CSCsb59252 ( registered customers only) .

Troubleshoot Echo Problems with these DSP Voice Quality Metrics

• Check the delay (DSP/DL) and R-factor (DSP/RF) statistics. You can potentially find perceptible delay between when the originating signal is transmitted and when the echo returns. In most telephones, sidetone helps mask some of the echo. Echos must be delayed by at least 20 milliseconds in order to be perceived.

• Check the level (DSP/LE) statitstic for sufficient echo amplitude. If the amplitude of the echo is low, it can go unnoticed.

Troubleshoot Echo in Gateways with Cisco IOS Software Releases Prior to 12.2.11T

Cisco IOS Gateway Parameters for when you Troubleshoot Echo

It is important to make sure that the echo canceler has enough information to distinguish between echo and voice conversation. The available parameters to control the distinction are:

• Input Level—Input gain of a signal is performed before the echo canceler sees the echo.

• Output Level—Output attenuation of a signal is performed after the echo canceler sees the original output signal.

• Echo Canceler Coverage—The amount of time the echo canceler remembers a signal that has been output. This parameter must be set to a value greater than the time the echo needs to return to the gateway.

Step-by-step Procedure to Troubleshoot and Eliminate Echo

Complete these steps to eliminate echo.

1. Verify that echo cancellation is enabled on the voice port. Echo cancellation is enabled by default.

   Gateway(config-voiceport)#echo-cancel
      coverage   Echo Cancel Coverage 
      enable     Echo Cancel Enable

   
   

   
   
   

   Note: You must shut, then no shut the voice port for the changes to take effect.

   
   



2. 
   

   Configure the echo canceler coverage to a value greater than the time the echo needs to return to the gateway, so that it is long enough to cover the worst case for your environment, but not longer.

   
   
   

   
   

   Gateway(config-voiceport)#echo-cancel coverage
      16  16 milliseconds echo canceler coverage 
      24  24 milliseconds echo canceler coverage 
      32  32 milliseconds echo canceler coverage 
      8   8 milliseconds echo canceler coverage

   
   

   
   
   

   Note: You must shut, then no shut the voice port for the changes to take effect.

   
   
   

   Note: The default coverage is set to 8 ms, but you can increase it up to 32 ms. If the PSTN delay (tail length) is more than 32 ms, current echo cancelers in Cisco IOS gateways are not able to cancel the echo. In Cisco IOS Software Release 12.2.13T and later, the echo coverage can be configured up to 64 ms. See the Echo Canceler Enhancements in Cisco IOS releases 12.2.11T and 12.2.13T section of this document.

   
   



3. 
   

   Measure the echo and adjust the echo signal level as required.

   
   
   

   Insufficient echo return loss (ERL) to handle the echo might cause these problems:

   
   
   
   
   
   • 
     

     Echo canceler does not cancel, but not enough to make echo inaudible.

     
     
     

     If the ERL value is too low, the total echo return loss seen by the IP network (ACOM) might be insufficient to suppress the echo. ERL needs to be approximately 20 dB (at least 15 dB).

     
     
     

     Note: Acombined (ACOM) is the total echo return loss seen across the incoming and outgoing terminals of the echo canceler (incoming terminal = signal into the ECAN toward the PSTN (voice), and outgoing terminal = signal out of the ECAN toward the IP network (echo)). ACOM is the sum of ERL + ERLE, or the total echo return loss seen by the network.

     
     
     

     Note: ACOM (Total loss) = ERL (Tail loss) + ERLE (ECAN loss)

     
     
   
   
   
   • 
     

     Echo canceler does not cancel.

     
     
     

     If the ERL value is too low, the echo signal that returns to the gateway might be too loud (within 6 dB of the talker signal). This causes the echo canceler to consider it as voice (double-talk) instead of echo. As a consequence, the echo canceler does not cancel it. ERL needs to be approximately 6 dB or higher for the echo canceler to engage. In Cisco IOS Software Release 12.2.13T, you can configure this ERL level. See the Echo Canceler Enhancements in Cisco IOS Software Releases 12.2.11T and 12.2.13T section of this document.

     
     
     

     In order to prevent these problems, measure the ERL and signal levels. Then adjust the signal levels on the Cisco IOS gateway based on the results. Configure positive values for output attenuation and negative values for input gain to adjust these levels. Input gain is performed before the echo canceler sees the echo signal, and output attenuation is performed after the echo canceler sees the original output signal.

     
     
     

     
     

     voice-port 1/1:15 
        input gain -3 
        output attenuation 3

     
     

     
     
   
   
   
   
   

   Note: You must shut, then no shut the voice port for the changes to take effect.

   
   
   

   Note: In Cisco IOS Software Release 12.2(1) and later, output attenuation can be set to a negative value which actually amplifies the output signal.

   
   



4. 
   

   Echo can also be caused by an impedance mismatch if both sides are not configured identically. Verify, and modify if needed, the impedance configured in the voice port. A default of 600 ohms is consistent with most lines on the PSTN and PBXs.

   
   
   

   
   

   Gateway(config-voiceport)#impedance
     600c 600 Ohms complex
     600r 600 Ohms real
     900c 900 Ohms complex
     complex1 complex 1
     complex2 complex 2

   
   

   
   

Echo Canceler Enhancements in Cisco IOS Software Releases 12.2.11T and 12.2.13T

Echo Suppressor

Enable echo suppressor to reduce the echo during the first two to three seconds of a call, while the echo canceler converges.

Configuration

gateway(config-voiceport)#echo-cancel ? 
  coverage    Echo Cancel Coverage 
  enable      Echo Cancel Enable 
  suppressor  echo suppressor

Software and Hardware Platforms Supported

Echo suppressor is supported in Cisco IOS Software Releases 12.2(11)T, 12.2(12), and 12.2(8)T5. The echo suppressor can only be used on T1 digital signal processors (DSPs) when the default Cisco G.165 EC is used. The echo suppressor cannot be used with the extended EC or on NextPort (Cisco AS5350 and Cisco AS5400) platforms. Except for the extended EC or on NextPort (Cisco AS5350 and Cisco AS5400) platforms, echo suppressor is supported in all platforms and all complexities (c549, c542 and c5409).

Extended Echo Canceler

Configuration

In addition to the default echo canceler used in the Cisco voice gateways (G.165 compliant), a new echo canceler is available in some of the platforms (G.168 compliant). The extended echo canceler provides:

• 
  

  Tail coverage of up to 64 ms.

  
  
  

  Enable the extended echo canceler to eliminate the echo when the tail coverage is greater than 32 ms.

  
  



• 
  

  Faster convergence.

  
  
  

  Enable the extended echo canceler to reduce the echo during the first two to three seconds of a call, while the echo canceler converges. Echo suppressor is not required anymore when you enable the extended echo canceler.

  
  



• 
  

  ERL can be tuned.

  
  
  

  Enable the extended echo canceler to eliminate the echo when ERL cannot be tuned lower than 6 dBm.

  
  

Extended echo cancellation is configured differently based on the version of Cisco IOS software you use. If you use Cisco IOS Software Release 12.3(4)XD or later, you do not have to use any Cisco IOS commands to enable the Enhanced ITU-T standard G.168 Echo Cancellation feature because the extended G.168 EC is the only available echo canceller. You have the option to disable the extended EC, but Cisco highly recommends that you leave it enabled.

The Cisco Enhanced ITU-T G.168 ECAN feature can be run either on the dedicated ECAN modules or the general voice resources that reside on the platform, network module, or advanced integration module. For example, Cisco 2800 Series and 3800 Series integrated services routers can use either the packet voice DSP modules (PVDM2s) mounted in the router chassis or the digital signal processor (DSP) resources on network modules to run the G.168 ECAN feature. When the G.168 ECAN feature is run on general voice resources, processing and memory constraints limit it to have at most 64-ms echo tailcoverage. Although this is adequate in most network conditions, a largerecho tail coverage is sometimes required. In these situations, the dedicated ECAN modules, attached to the appropriate MFT VWIC2, can be used. The processing and memory resources of the dedicated ECAN modules enable the echo canceller to be configured with predefined settings and an extended 128-ms echo tail buffer, which provides robust echo cancellation performance.

Reference:

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080149a1f.shtml

CUCM Extension Mobility

 

Extension Mobility Configuration Elements

Configuration Element Name	Configuration Element Function
Phone	Stores the configuration of physical phones. Configuration parameters include device-specific phone parameters (such as device CSS, location, or MRGL), user-specific phone parameters (such as user MOH audio source, DND, or softkey template), and (user-specific) button configuration (such as lines or speed dials).
End User	The end user is associated with one or more device profiles. The User ID and the PIN are used to log in to a phone with Extension Mobility.
Device profile	Stores user-specific phone configuration in logical profiles. Configuration parameters include user-specific phone and button parameters (such as lines and speed dials). The parameters of the device profile are applied to a physical phone after a user logs in to the phone using Extension Mobility.
Phone service	Extension Mobility is implemented as a phone service. Hardware phones and device profiles have to be subscribed to the service.
Default device profile	Stores the default device configuration parameters that should be applied when the phone model of a user’s device profile is different from the phone model of the phone where the user logs in.

Relationship Between Extension Mobility Configuration Elements

EM Operation

1. The user presses the Services button on the phone and chooses the Extension Mobility
service from the list of phone services available at the phone.

2. The Extension Mobility service requires the user to log in using his or her user ID and
PIN. The user enters the required data on the phone by pressing each phone button as
many times as needed to select the alphanumeric characters for his or her user ID
and PIN.

3. If the entered user ID and PIN are correct, Extension Mobility chooses the device
profile that is associated with the user.

NOTE If a user is associated with more than one device profile, all associated profiles
are displayed, and the user has to choose the desired profile, as illustrated for User2 in
Figure 12-3. Assigning multiple profiles to a user means that the user is provided with a
separate device profile for each site. Doing this is common when the traditional approach
is used to implement Calling Search Spaces (CSS). Extension Mobility updates only the
line configuration, including the line CSS, but not the device CSS. To allow the choice
of a local gateway for outbound PSTN calls, a different line CSS has to be applied for
each site. In such a scenario, the user chooses a site-specific device profile that differs
from the device profile that is used at other sites in its line CSS. The line CSS of such
site-specific profiles gives access to route patterns that route PSTN calls to the appropri-
ate local gateway to minimize toll charges. Extension Mobility also works well if the
more modern approach of gateway selection of PSTN at the device (phone) level and
blocking the CSS at the line level is implemented.

4. CUCM updates the phone configuration with the settings of the chosen device profile.
User-specific device-level parameters, lines, and other phone buttons are updated with
user-specific settings.

5. The IP Phone is reset and loads the updated configuration.

 

Extension Mobility Solution to Phone Model Differences
After successful authentication, if the phone model of the device profile does not match the
phone model of the actually used phone, the following happens:

1. Device-dependent parameters such as the phone button template and softkey template
from the default device profile are applied to the phone.

NOTE If the phone button template that is configured in the user's device profile
matches the number of buttons on the login device, the system uses the phone button
template from the user's device profile. Otherwise, the system uses the phone's default
device profile for phone button configuration.

2. The system copies all device-independent configuration settings, such as user hold
audio source, user locale, speed dials, and line configuration, from the device profile to
the login device. Exceptions are the parameters specified under line settings for this
device.

3. The applicable device-dependent parameters of the user's device profile are applied.
These parameters include buttons (such as line and feature buttons) based on the phone
button template that has been applied from the default device profile.

4. If supported on the login device, phone service subscriptions from the user's device
profile are applied to the phone.

5. If the user's device profile does not have phone services configured, the system uses
the phone services that are configured in the default device profile of the login device.

 

EM Configuration

Step 1 Activate the Cisco Extension Mobility service in CUCM for the cluster.

Step 2 Set Cisco Extension Mobility service parameters.

Step 3 Add the Cisco Extension Mobility phone service.

Step 4 Create default device profiles for all phone models used.

Step 5 Create device profiles, and subscribe them to the Cisco Extension Mobility phone service.

Step 6 Create end users, and associate them with device profiles.

Step 7 Enable Extension Mobility for phones, and subscribe the phones to the Cisco Extension Mobility service.

Reference:

CIPT2 v6.0 Chap12 Implementing Extension Mobility

Erlang Description

Erlang - a unit of traffic

An Erlang is a unit of telecommunications traffic measurement.  Strictly speaking, an Erlang represents the continuous use of one voice path.  In practice, it is used to describe the total traffic volume of one hour.

For example, if a group of user made 30 calls in one hour, and each call had an average call duration of 5 minutes, then the number of Erlangs this represents is worked out as follows:

Minutes of traffic in the hour=number of calls x duration

Minutes of traffic in the hour=30 x 5

Minutes of traffic in the hour=150

Hours of traffic in the hour=150 / 60

Hours of traffic in the hour=2.5

Traffic figure=2.5 Erlangs

Erlang traffic measurements are made in order to help telecommunications network designers understand traffic patterns within their voice networks.  This is essential if they are to successfully design their network topology and establish the necessary trunk group sizes.

Erlang traffic measurements or estimates can be used to work out how many lines are required between a telephone system and a central office (PSTN exchange lines), or between multiple network locations.

Erlang traffic models

Several traffic models exist which share their name with the Erlang unit of traffic.  They are formulae which can be used to estimate the number of lines required in a network, or to a central office (PSTN exchange lines).  A formula also exists to model queuing situations, and lends itself well to estimating the agent staffing requirements of call centers.

The main Erlang traffic model are listed below, with links to the free online calculators on this Web site:

• Erlang B
  This is the most commonly used traffic model, and is used to work out how many lines are required if the traffic figure (in Erlangs) during the busiest hour is known.   The model assumes that all blocked calls are immediately cleared.
• Extended Erlang B
  This model is similar to Erlang B, but takes into account that a percentage of calls are immediately represented to the system if they encounter blocking (a busy signal).  The retry percentage can be specified.
• Erlang C
  This model assumes that all blocked calls stay in the system until they can be handled.  This model can be applied to the design of call center staffing arrangements where, if calls cannot be immediately answered, they enter a queue.

Further reading

To investigate the traffic unit Erlang, and the Erlang traffic models, we suggest the following sources of information on this Web site:

1. Free online Erlang traffic Calculators
   These online calculators allow you to perform Erlang traffic calculations now.  The Call Minutes Calculator does not even require an understanding of the Erlang traffic unit, and allows entries in minutes rather than Erlangs.  Detailed information is available in the Help area (press the Help button).
2. Dimensioning Trunk Groups
   This white paper discusses a method of optimising the number of lines in a trunk group based on the traffic carried by that trunk group. This is known as dimensioning a trunk group, and uses the Erlang B traffic model.
3. Call Centre Design
   This white paper describes the steps involved in assessing the staffing requirements of a call centre and estimating the number of trunks (central office lines) required to serve a call centre for incoming calls.  The suggested method uses both Erlang B and Erlang C.

A.K. Erlang - a tribute

Agner Krarup Erlang was born in 1878 in Lønborg, Denmark.   He was a pioneer in the study of telecommunications traffic and, through his studies, proposed a formula to calculate the fraction of callers served by a village exchange who would have to wait when attempting to place a call to someone outside the village.

In 1909, he published his first work: The Theory of Probabilities and Telephone Conversations.  He gained worldwide recognition for his work, and his formula was accepted for use by the General Post Office in the UK.

Erlang never married.  He worked for the Copenhagen Telephone Company for twenty years, until his death in 1929.  During the 1940s, the Erlang became the accepted unit of telecommunication traffic measurement, and his formula is still used today in the design of modern telecommunications networks.

Reference:

http://www.erlang.com/whatis.html