What is + dialing?

When using the term “+ dialing” we are typically referring to storing and calling a contact’s telephone number in the Corporate/Personal, Missed/Received calls directory in the equivalent of the fully qualified domain name format which is defined by the ITU spec E164. This defines the “+” character at the start of every telephone number followed by the country code and national digits. We don’t define the telephone number in a format that is localized to a particular country- for example with an international prefix of “011” which is localized for the NANP dialing domain. To put it another way- + dialing is all about making calls using a contact’s globalized telephone number.

Read Full Entry »

Tags: + dial, called number transformation pattern, CCIE, ccie voice, ccie voice 3.0, ccie voice lab, CCIE Voice Training, e164 cisco, globalized, IPexpert's CCIE Voice Course, localized, Mark Snow, vik malhi, Voice

CCIE Voice Clients,

The 4th (of 10) lab and Solution have been released (added to your members area).  The snapshot will be active on Proctor Labs Monday.  If you don’t see the mock lab – you know the routine! (email support@ipexpert.com) ;-)

Thanks! – Wayne

Tags: ccie voice 3.0, ccie voice lab, CCIE Voice Mock Lab

A Thursday?  Oh well – yes, that’s correct.  July 16, 2009 is when the new CCIE Voice lab exam will go into effect.  Apparently, Cisco is doing less updating of their old website and putting their time into updates on the Cisco Learning Network.  And, while it makes sense that they are continuing to put all of their updates on that site, you might think that they would echo all of the more important ones back to the old faithful link that many still visit.  Anyway – it’s official!  CCIE Voice v3 Blueprint Refresh date of July 16, 2009 link

Cheers,

Mark

Tags: ccie voice lab, CCIE Voice Lab Version 3 Blueprint, CCIE Voice Training, Cisco, cisco.com, Voice

The behavior of 79XX IP phones using SIP and SCCP firmware is somewhat different when a user goes off-hook and begins to dial the digits of the intended Called Party. When SCCP is used as the protocol, UCM/UCME collects each digit that the user enters on the keypad of the phone in the StationInit message that the phone sends. Digit analysis takes place by UCM/UCME in real-time as each digit is being received until the point when there is only one possible match or outcome. The UCM/UCME comes to the conclusion that there is only one potential match and the call is routed to the Device/Route List that has the matched number assigned. In the case of UCME this would be a destination-pattern within a dial-peer.

The benefit of using the method described above is that providing the dial plan has been designed correctly and there is no overlap in Directory Numbers and Route Patterns configured, the call is routed immediately after the caller has dialed the final digit. The only instance of callers having to wait for the inter-digit timer (T302- default 15 seconds) to expire is when the caller dials an international number since each country uses a variable number of digits as part of the telephone number. For this reason the “#” character is used as a terminator to inform UCM/UCME that the caller has completed dialing. Callers can avoid the inter-digit timeout if they enter the “#” character after dialing the international number.

Digit collection when SIP phones are used can be done in one of two ways. The first method is very similar to the process used with SCCP in that UCM/UCME collects each digit as the caller enters them on the keypad of the phone. Analysis takes places in real-time and the call is routed when the search has been narrowed down to one match. The method to support this behavior in SIP is called KeyPad Markup Language (KPML). Instead of using SCCP StationInit messages, SIP NOTIFY messages are used to carry the dialed digits from the phone to the server. KPML is supported on Cisco Unified IP Phones 7911G, 7941G, 7941GE, 7961G, 7961GE, 7970G, and 7971GE. Devices that use KPML are known as Type-B SIP phones. The benefit of using KPML (or SCCP) is that the user simply needs to enter the dialed digits and the call is routed. If the calls dials an invalid digit which rules out all possible matches in UCM/UCME, the caller will immediately receive the reorder tone (or error message). For example if only extension numbers 1000-1099 has been provision and the caller dials “1-1-0-0” then the caller will hear the reorder tone (or message) after dialing the second “1” since there is no match. There is never a need to dial the “#” key unless dialing internationally.

Phones that support KPML are automatically enabled for KPML. No configuration on the UCM/UCME is necessary for these devices to support KPML. It also must be stated that KPML is not supported on phones in SRST.

Type-A SIP phones use an entirely different method to the one used by SCCP and Type-B SIP phones. Each digit that is entered onto the keypad of the phone by the caller is NOT sent to the UCM/UCME in real-time. The phone collects all digits and the call is only ever routed to the server when the caller presses the “#” terminator or the “Dial” softkey. If the caller fails to enter “#” or the “Dial” softkey, that particular call is susceptible to the inter-digit timeout. However, when the user presses the “Redial” softkey there is no timeout.

To avoid the need for callers to enter the “#” or “Dial” softkey, SIP Dial Rules on UCM and SIP Dial Plans on UCME can be configured. This allows the phone to download a dial plan file from the TFTP server when the phone boots. This file, called dialplan.xml, is created on the TFTP server when SIP Dial Rules on UCM and Voice Register Dialplan on UCME have been configured. The phone will download dialplan.xml when the phone in question has been assigned the SIP Dial Rule/Voice Register Dialplan and has subsequently been reset. This method of using dial plans downloaded to the phone is indeed the best practice since there is a reduced burden on the server and offers a more scalable solution.

When a caller enters the dialed digits on the keypad, the phone analyzes the dialed digits and compares them with the strings contained within the dialplan.xml file stored locally on the phone. Once there is a match, and the timeout is set to 0 (the timeout for each string is part of the dialplan.xml file) the phone sends a SIP INVITE message, which contains the entire Called Party Number, to the server. If the dialed number does not match any of the strings contained within the diaplan.xml file, the call will only be routed when the inter-digit timeout expires (or the caller presses “#” of “Dial”). If a dialplan.xml file is downloaded to a phone that supports KPML, KPML is disabled and the phone will behave in the same way as a Type-A SIP Phone. A hybrid of using KPML and Dial Rules is not supported and SIP Dial Rules/Dial Plan will always take priority over KPML. The exception to this statement is when UCME is used and the last statement within the dialplan contains a dial pattern with a single wildcard character (.) as the last pattern in the dial plan. For example:

voice register dialplan 1
type 7940-7960-others
pattern 1 1…
pattern 2 91……….
pattern 3 .

In the UCME dialplan configured above, if the caller dials a number which does not match either of the first two strings, then the third string will match and KPML will be invoked for phones that support KPML!!

Tags: CCIE, CCIE Training, ccie voice, ccie voice lab, CCIE Voice Training, keypad markup language, KPML, SIP Dial Plan, sip dial rule, type-a sip, type-b sip, voice register dialplan

One of the new additions to UCME 7.x (versus the previous tested version on the CCIE-V lab, 3.3) is the ability to create octo-line ephone-dn’s. In order to explain and fully appreciate the benefit of the octo-line, we must take a look at the two other types of ephone-dn we are able to configure, namely the single-line and dual-line ephone-dn.

ephone-dn  3
number 3010

The configuration above shows a single-line ephone-dn created with tag 3. The number for this ephone-dn is 3010. This actually creates a POTS dial-peer and voice-port on the gateway as shown below:

BR2-RTR#sh telephony-s dial-peer

dial-peer voice 20003 pots
destination-pattern 3010$
huntstop
progress_ind setup enable 3
port 50/0/3

BR2-RTR#sh telephony-s voice-port

voice-port 50/0/3
station-id number 3010

Only one call can be active on extension 3010 at any one time. Call Waiting is not enabled and the user of the phone which has been assigned this extension is unable to intiate an Ad-Hoc conference call or a consult transfer. The single-line actually translates down to the gateway as a single channel ephone-dn as shown below:

BR2-RTR#sh ephone-dn 3
50/0/3 CH1   DOWN

The voice-port 50/0/3 which is in effect ephone-dn 3 has a single channel which currently not in use (DOWN). Once this ephone-dn is assigned to an actual phone the state of the channel will be IDLE.

BR2-RTR(config-ephone-dn)#ephone 1
BR2-RTR(config-ephone)#button 1:3

Now let’s move onto the dual-line ephone-dn. Ephone-dn 3 was removed and re-entered into the configuration as shown below. You cannot change an ephone-dn from single-line to dual-line on the fly.

BR2-RTR(config)#ephone-dn 3 dual-line
BR2-RTR(config-ephone-dn)#number 3010

We see that using the command below there are two channels for the dual-line ephone-dn.

BR2-RTR#sh ephone-dn 3
50/0/3 CH1   DOWN         CH2   IDLE

This second channel can be used to enable Call Waiting, Conference a Consult Transfer. An extremely important point to understand when dual-lines is concerned is that these two channels cannot be used by different phones. Take a look at the example below:

ephone-dn  3  dual-line
number 3010
!
!
ephone  1
button 1:3
…
!
ephone 2
button 1:3
…

In the example above the first button on both phones 1 and 2 have been assigned extension 3010. If a call arrives at the CME destined for 3010 both phones will ring. Supposing that phone 1 answers the call, channel 1 of voice-port 50/0/3 (or ephone-dn 3) will be in use by phone 1.

If another call arrives at the CME for extension 3010 you might be expect to find phone 2 ringing but you would be incorrect. The reason is the owner of the first channel of voice-port 50/0/3 is the reserved owner of the second channel for the voice-port. This means that the second channel cannot be used by phone 2. As a result phone 1 will receive Call Waiting as the CME attempts to activate or invoke the second channel on the voice-port.

Let’s now take a look at the same example except instead of ephone-dn 3 as a dual-line, it is now configured as an octo-line ephone-dn.

ephone-dn  3  octo-line
number 3010
!
!
ephone  1
button 1:3
…
!
ephone 2
button 1:3

BR2-RTR(config-ephone)#do sh ephone-dn 3
50/0/3 CH1   IDLE         CH2   IDLE         CH3   IDLE         CH4   IDLE         CH5   IDLE         CH6   IDLE         CH7   IDLE         CH8   IDLE

We see that the voice-port or ephone-dn has 8 channels assigned. The total number of active calls (incoming calls + outgoing calls) is anything up to and including 8. The key benefit of the octo-line ephone-dn however is the ability to split the channels amongst more than one ephone. If you look back to the dual-line example, you will see that the second channel can only ever be used by the phone which has reserved the first channel. Not so with the octo-line ephone-dn. Each channel can be used by a different ephone.

So using the earlier example, if phone 1 is busy with the first call to extension 3010 and a second call arrives destined for extension 3010 what actually happens is that phone 1 will receive call waiting and phone 2 will ring.

After a connected call on an octo-line directory number is put on-hold, any phone that shares this directory number can pick up the held call. If a phone user is in the process of initiating a call transfer or creating a conference, the call is locked and other phones that share the octo-line directory number cannot steal the call.

As well as making simple hunt groups easier to define without using something call overlaid-dn’s, the octo-line ephone-dn allows implementation of features such as Barge and Privacy which were not possible beforehand. However some features such as Park and Paging still require that the ephone-dn be configured as a single-line.

Tags: ccie voice, ccie voice lab, CCIE Voice Lab Version 3 Blueprint, cme, dual-line, ephone-dn, Octo-line, single-line, telephony-service, ucme