CCIE Voice Lab Preparation Notes #2

SRST
There are four SRST scenarios:

• SRST configuration for MGCP gateways
• SRST for H.323 gateways
• SRST for SIP gateways
• SRST on CME

1. MGCP Gateway

• Enables fallback for MGCP gateway
  router(config)#ccm-manager fallback-mgcp
• Enters SRST configuration mode
  router(config)#call-manager-fallback
• Configure Basic SRST settings
  router(config-cm-fallback)#max-dn value [dual-line] [preference preference-order]
  router(config-cm-fallback)#max-ephone value
  router(config-cm-fallback)#ip source-address ip-address
  router(config-cm-fallback)#system message primary message
  router(config-cm-fallback)#user-local country-code
  router(config-cm-fallback)#time-format [12|24]
  router(config-cm-fallback)#date-format format
  router(config-cm-fallback)#moh filename
  router(config-cm-fallback)#max-conferences value
  router(config-cm-fallback)#call-forward reason number
  router(config-cm-fallback)#voicemail number
  router(config-cm-fallback)#secondary-dialtone digit-string
• Configure the MGCP gateway as SRST reference in CUCM.
• Assign the SRST reference to IP phones by configuring corresponding device pool.
• The last step is to configure H.323 incoming and outgoing dial peers for SRST.
  

Additionally, you can use the router to provide multicast MOH to IP phones.

router(config)#ccm-manager music-on-hold

router(config)#call-manager-fallback

router(config-cm-fallback)#moh filename

router(config-cm-fallback)#multicast moh multicast-address route address-to-send-packets-to

2. SRST for H.323

On H.323 gateways, when the WAN link fails, active calls from Cisco Unified IP phones to PSTN are not maintained by default. Call preservation may work with 'no h225 timeout keepalive' command under 'voice service voip' 'h323' configuration mode.

3. SRST for SIP Gateway

SIP SRST feature is using Back-to-Back User Agent Mode.

By default, when configuring 'voice register global', it is SRST mode.

4. SRST on CME

router(config)#telephony-service

router(config-telephony)#srst mode auto-provision {all|dn|none}

Use none when configuring SRST with CUCM.

CCIE Voice Lab Preparation Notes #1

Understanding COR on Cisco IOS Gateways

• Calling privileges on IOS gateways are implemented using class of restriction (COR).
• COR lists contain CORs and are used to control call routing.
• COR lists are assigned to dial peers (Incoming COR List & Outgoing COR List).
• For each call, the incoming COR list is matched against the outgoing COR list. If the outgoing COR list is a subset of the incoming COR list, or no incoming COR list is configured, call is routed.

A COR is the building block of calling privileges. A COR list contains multiple CORs and is bound to dial peers. For CallManager Express, COR is applied to ephone-dns. For SRST, COR is applied to number range.

COR only takes in place when both incoming COR list and outgoing COR list are applied.

Normally, when configuring Outgoing COR list, we assign one COR to one Outgoing COR list, and the Outgoing COR list is analogous to the concept of Partition in CUCM, and the Incoming COR list is analogous to Calling Search Space.

Configuration Commands:

First, you need to define COR:

router(config)#dial-peer cor custom

router(config-dp-cor)#name COR-name

Then, you need to configure COR lists:

router(config)#dial-peer cor list list-name

router(config-dp-corlist)#member name

Lastly, you need to apply COR lists to incoming or outgoing dial-peers or ephone-dns.

router(config-dial-peer)#corlist incoming | outgoing list-name

router(config-ephone-dn)#corlist incoming | outgoing list-name

To apply COR lists to SRST ephones:

router(config-cm-fallback)#cor {incoming | outgoing} cor-list-name {cor-list-tag starting-number - ending-number | default}

CME Conference Resource

1. Configure DSP as SCCP device and register to CME.
voice-card 0
no dspfarm
dsp service dspfarm

sccp local voice-interface
sccp ccm cme-address identifier 1 version 7.0+
sccp
sccp ccm group 1
associate ccm 1 priority 1
associate profile 1 register CONF

dspfarm profile 1
associate application sccp
maximum session 2
no shut

telephony-service
sdspfarm unit 2
sdspfarm tag 1 CONF
conference hardware

2. Configure ephone-dn for Ad-hoc and Meet-me conference
ephone-dn 200 octo-line
number 6666
conference ad-hoc

ephone-dn 201 octo-line
number 7777
conference meetme

3. Change ephone-template to include conf button for connected status.

CME Night Service

The instructions from CME system admin guide is not complete when configuring Night Service. Below is a brief guide on how to enable the feature on CME.

1. The first step is to define night service hours under telephony-service configuration mode.
telephony-service
night-service day Sun 18:00 23:59
night-service day ...

2. The second step is to utilize night service.
ephone-dn 1
call-forward night-service ....

CUE Licensing

CUE has two types of licensing, the license for core application, and the license for IVR.

For core application license, you can choose between CME and CM. You can have either CME or CM, but not both.

Difference between H245 Signal and H245 Alphanumaric

H245 Signal and H245 Alphanumaric are two DTMF relay methods for h.323 dial peers. They are both out of band DTMF relay methods.

H245 Signal transmits two events, the start and the stop when holding the key and releasing the key. In another word, it records the duration. It is useful in calling card scenario.

H245 Alphanumaric only sends one event, and it has the default during period for 200ms.

The Cisco recommended DTMF relay method is H245 Alphanumaric.

CUE Upgrade from Version 1 to Version 7.0.3

I just bought a Cisco Unity Express module from ebay (NM-CUE), and it arrived this morning. I never touched it before. I connected it to a Cisco 3845 ISR.

After loading the IOS, I issued 'show version', and there is a service engine found. Using 'show ip interface brief' displays the new service engine interface.

So I configured an IP address on the service engine interface, and then under service engine interface configuration mode, I configured another ip address within same subnet of the service engine interface, pointing the default gateway address as the service engine interface address, and then enabled the interface.

Then I issued 'service-module service-engine slot/port session' command to switch the console to NM-CUE. Using 'show software version', I found out the version of CUE is 1.0.7. The version required on CCIE Voice blueprint is version 7.

Further investigations show that there are several ways for the upgrade, but after some testing, I realize that to upgrade from version 1 to version 7, the only way is to upgrade through boot helper.

Before doing the upgrade, some preparation work needs to be done. First is to download the related installation pack, language files and licenses for version 7 (I downloaded version 7.0.3).

FTP server and TFTP server need to be setup. TFTP is used to upgrade the boot helper, and FTP server is used to upgrade the software, language files and licenses. I simply put all files under one directory and point both ftp and tftp path to this directory.

Reload the CUE and type '***' to get into boot helper when it is prompted to do so.

Input 'config', and configure the related information, like ip address, subnet mask, default gateway, tftp server address and boot helper file name. When config is finished, type 'boot helper', and the boot helper upgrade is started. When finished, choose '1' to install software, and type the related package name, ftp server address, username and password. When prompted, select the language file to install.

When it is done, you can have some basic initialization configurations.

Using 'software install clean url' command to install the license files.

:-D I now have version 7.0.3 installed on Unity Express.

SIP Significant Digits - SigDigits

Configuration of Unified CVP SIP Service:
The Unified CVP SIP Service does not currently have a configuration field for setting the significant digits that should be stripped. Instead, you must edit the sip.properties file. The sip.properties file is located in the C:\Cisco\CVP\conf directory by default. Add the following line to the end of the sip.properties file (to strip four digits from the DNIS number):
SIP.SigDigits = 4

Configuration of VoiceXML gateway:
Configure the VXML gateway to match the DNIS string, including the prepended digits:
dial-peer voice 3000 voip
incoming-called number 33335551000T
service bootstrap
...
Configure the Unified CVP bootstrap.tcl application with the sigdigits parameter, telling it how many digits to strip off of the incoming DNIS string:
application
service bootstrap flash:bootstrap.tcl
param sigdigits 4
...

Cisco Unified CM configuration (if used):
Configure Unified CM to strip the prepended digits, either by using the Significant Digits configuration on the SIP Trunk configuration page or by using translation patterns.

SIP Proxy configuration:
Define static routes on the SIP Proxy, with the prepended digit present, to be sent to the appropriate VoiceXML gateway. Because transfers to agents on a Unified CM cluster will also have the digits prepended, the static routes for agent phones must also contain the prepended digits.

IOS Gateway Configuration for SIP-Proxy Redundancy

With Cisco IOS gateways, dial-peers are used to match phone numbers, and the destination can be a SIP Proxy Server, DNS SRV, or IP address. The following example shows a Cisco IOS gateway configuration to send calls to a SIP Proxy Server using the SIP Proxy's IP address.
sip-ua
sip-server ipv4:10.4.1.100:5060
dial-peer voice 1000 voip
session target sip-server
...
The sip-server command on the dial-peer tells the Cisco IOS gateway to use the globally defined
sip-server that is configured under the sip-ua settings. In order to configure multiple SIP Proxies for redundancy, you can change the IP address to a DNS SRV record, as shown in the following example. The DNS SRV record allows a single DNS name to be mapped to multiple servers.
sip-ua
sip-server dns:cvp.cisco.com
dial-peer voice 1000 voip
session target sip-server
...
Alternatively, you can configure multiple dial-peers to point directly at multiple SIP Proxy servers, as shown in the following example. This configuration allows you to specify IP addresses instead of relyingon DNS.
dial-peer voice 1000 voip
session target ipv4:10.4.1.100
preference 1
...
dial-peer voice 1000 voip
session target ipv4:10.4.1.101
preference 1
...
In the preceding examples, the calls are sent to the SIP Proxy server for dial plan resolution and callrouting. If there are multiple Unified CVP Call Servers, the SIP Proxy server would be configured with multiple routes for load balancing and redundancy.

DNS SRV records allow an administrator to configure redundancy and load balancing with finer
granularity than with DNS round-robin redundancy and load balancing. A DNS SRV record allows you to define which hosts should be used for a particular service (the service in this case is SIP), and it allowsyou to define the load-balancing characteristics among those hosts. In the following example, the
redundancy provided by the three dial-peers configured above is replaced with a single dial-peer using a DNS SRV record. Note that a DNS server is required in order to do the DNS lookups.
ip name-server 10.4.33.200
dial-peer voice 1000 voip
session target dns:cvp.cisco.com


With Cisco IOS gateways, it is possible to define DNS SRV records statically, similar to static host records. This capability allows you to simplify dial-peer configuration while also providing DNS SRV load balancing and redundancy. The downside of this method is that, if the SRV record needs to be changed, it must be changed on each gateway instead of on a centralized DNS server. The following example shows the configuration of static SRV records for SIP services handled by cvp.cisco.com, and the SIP SRV records for cvp.cisco.com are configured to load-balance across three servers.
ip host cvp4cc2.cisco.com 10.4.33.132
ip host cvp4cc3.cisco.com 10.4.33.133
ip host cvp4cc1.cisco.com 10.4.33.131
(SRV records for SIP/TCP)
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._tcp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com
(SRV records for SIP/UDP)
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc3.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc2.cisco.com
ip host _sip._udp.cvp.cisco.com srv 1 50 5060 cvp4cc1.cisco.com
Cisco highly recommends the use of UDP instead of TCP for SIP signaling. TCP stack timeout delays can cause significant delays to the caller during failures.

DTMF Relay for SIP

DTMF tones are the tones that are generated when a telephone key is pressed on a touchtone phone. Sometimes the called endpoint needs to hear those tones, such as when you enter digits during the call in response to a menu. Low-bandwidth codecs can distort the sound, however. DTMF relay allows that tone information to be reliably passed from one endpoint to the other. By default, SIP uses in-band signaling, sending the DTMF information in the voice stream. However, you can configure it to use RTP-NTE, SIP INFO messages, SIP NOTIFY messages, or KPML for transmitting DTMF tone information.

RTP-NTE is an in-band DTMF relay method, which uses RTP Named Telephony Event (NTE) packets to carry DTMF information instead of voice. If RTP-NTE is configured, SDP is used to negotiate the payload type value for NTE packets and the events that will be sent using NTE.

RTP-NTE can cause problems communicating with SCCP phones, which use only out-of-band DTMF relay. In a CallManager 4.x network with SCCP phones, you must provision an MTP for calls that traverse the SIP trunk. This MTP translates between in-band and out-of-band DTMF signals. You must configure a separate MTP for each side of the SIP trunk. You can do this MTP in hardware, or in software on CallManager.

Cisco has two out-of-band procedures for DTMF relay. One uses SIP INFO methods, and the other uses SIP NOTIFY methods. The SIP INFO method sends DTMF digits in INFO messages. It is always enabled. When a gateway receives an INFO message containing DTMF relay information, it sends the corresponding tone.

NOTIFY-based out-of-band DTMF relay is negotiated by including a Call-Info field in the SIP INVITE and response messages. This field indicates an ability to use NOTIFY for DTMF tones and the duration of each tone in milliseconds. Using this method can help SIP gateways interoperate with Skinny phones. You can also use it for analog phones that are connected to Foreign Exchange Station (FXS) ports on the gateway.

CVP Static Route for SIP Proxy Redundancy

When configuring static routes on CVP call servers to route to two SIP Proxy servers for redundancy, there are two ways to do it.

One is to add SRV DNS records in your DNS server, and the other one is to use local DNS SRV records.
• Static routes using DNS SRV records on a DNS Server
– Advantages:
Weighted load balancing and redundancy.
– Disadvantages:
Might not be able to use an existing DNS server, depending on the location of the DNS server.
The ability to share or delegate DNS server administration rights might not be possible in
some organizations.
Dial-plan configuration needs to be configured on each device individually (Cisco Unified
Communications Manager, Unified CVP, and gateways).
DNS SRV lookup is performed for each and every call by Unified CVP. If the DNS server is
slow to respond, is unavailable, is across the WAN, or so forth, this will affect performance.
• Static routes using local DNS SRV records
– Advantages:
Weighted load balancing and redundancy.
Does not depend on an external DNS Server, thus eliminating a point of failure, latency, and
DNS Server performance concerns.
– Disadvantages:
Dial plan must be configured on each device individually (Cisco Unified Communications
Manager, Unified CVP, and gateways).

Below is an example local SRV configuration file. It must be named in a text file named srv.xml and manually placed in the c:\cisco\cvp\conf directory of the Call Server where the SIP Service is running.

<?xml version="1.0" encoding="UTF-8" ?><locater>

<host name="cups.cisco.com">
<record weight="30" priority="1" destination="10.86.129.1" port="5060"/>
<record weight="30" priority="2" destination="10.86.129.2" port="5060"/>
</host>


<host name="vxml-gateway.cisco.com">
<record weight="30" priority="1" destination="10.86.129.23" port="5060"/>
<record weight="30" priority="2" destination="10.86.129.109" port="5060"/>
</host>


<host name="vgw.cisco.com">
<record weight="30" priority="1" destination="10.86.129.100" port="5060"/>
<record weight="30" priority="1" destination="10.86.129.101" port="5060"/>

</host>

</locater>

• So in example above (host with cups.cisco.com), SIP request will always go to 10.86.129.1 and if 129.1 is failed it will go to .2
  
• Because the priority is different (when priority is different, the weight is ignored)
  
• CVP is going to wait till the SIP timer expires and then send it to 129.2
  

• In the second example above (one with the vxml-gw.cisco.com) first record is on the top priority
  
• So all calls will be routed always to 10.86.129.23.
  
• Only when first host goes down, then the call will be sent to 10.86.129.109
  
• But in this case CVP has no way of knowing about 10.86.129.23 going down dynamically
  
• And after SIP retry timer kicks in, then it will send it to 10.86.129.109
  
• So each and every call will have to wait before the timer expires and then it will be sent to 10.86.129.109
  

• In the third example above (one with the vgw.cisco.com)
  
• Since the priority and weight both are same, that means all calls will go into round-robin fashion
  
• Lets assume that the first host is down, then every second call will have to wait till SIP timer expires and then it will switch to 10.86.129.109
  

Post-installation Setup for CUPS

When lauching CUPS admin page first time after installation, some configuration needs to be done.

First, an AXL account needs to be created on CUCM. Create an application account, call it 'AXL' and create a group 'AXL', and assign 'Standard AXL API Access' role to the group. Assign the application user to the group.

Next, on CUPS, put in the CUCM publisher address, the AXL account info just created, and the security string configured when installing CUCM. Personally, I prefer to use the same key when installing CUCM and CUPS.

After completion, the user database should be synched with 'Sync Agent'.

What after My CCIE Routing & Switching

I failed my CCIE Lab in June last year, on some really complicated topic even Cisco didn't recommend the way to do it, and I took it again in August. Finally I got my CCIE number. After all these years I've been working as a network engineer, I did it.

I was thinking about changing a job after I received my certificate, but, just not the right timing.

So I decided to take my next level -- CCIE Voice. Cisco is going to change content of the exam, which makes more sense. 6608 E1 blade for Catalyst 6500 switches is not on the list, which is a good news. In real world, my company replaced 6608 blade with CMM for most of the major sites, because only CMM is supported under native IOS. After UCCE is deployed, even the CMM will be replaced with 3845 ISRs.

My company is through the testing phase of corporate IM and unified communications, and currently, we are testing integrating MOC with CUPS (Cisco Unified Presence Server), and upgrading CUCM to version 7. So I got some exposure to the new version of the applications.

Meanwhile, my company is deploying UCCE (Unified Contact Centre Enterprise), so CUPS is heavily depended upon.

So, I decided to build my own lab. In my previous post, I mentioned I fixed a Quad-Core computer with 4GB memories, and recently, I upgraded the RAM to 8GB. It took me two days for the upgrade. I ordered additional 4GB RAM from ebay, and after I installed them, the OS crashes all the time. It took me some time to realize that it was the problem of BIOS firmware. To update BIOS firmware, floopy drive is needed. The problem was I didn't buy the floopy drive. Luckily, the mother board supports booting from USB drive. It took a while to create a USB boot disk with upgrading software and new BIOS firmware. The rest is just easy. Anyway, with the new RAM, I am able to install the new applications.

I started with installing CUCM 7 on the vmware server. I ran into some small problems when installing it, but after googling for some topics, problems gone. The trick is when setting up the vmware image, better choose IDE rather than SCSI.

Then I installed CUC 7 (Cisco Unity Connection) on another vmware server. After logging into the admin page, I found out that no service is enabled. Then I realized when choosing the country, I chose Australia instead of leaving it as default. I didn't want to reinstall it, so I downloaded the Locale file for Australia. After updating the OS, I was happy.

Installing CUPS 7 (Cisco Unified Presence Server) was quite smooth, but you need to run post installation setup the first time you lauch the application. I will cover it on later post.

The last bit was to install IPCC Express 7. Only after booting up the vmware server, I realized that it is some application running under Windows Server 2003 Standard. I tried the Windows 2003 server for the testing, not working. It requires Cisco supported platform. So I got the Cisco MCS 2003 OS image, and installed it, and then everything started working.

Another trick I forgot to mention is when configuring vmware, configure the memory to be 2GB. And after the installation, you can thrink down the memory size.

Now the four vmware servers running beautifully on my computer.

Triggered Update for RIP

To configure triggered update for RIP, you need to enable following command on the interface configuration mode:
ip rip triggered

This command only works on point-to-point sub-interface if it is a Frame-Relay interface.

Bridging over Frame Relay

Three routers connecting to the frame relay cloud with hub spoke topology, with R1 being the hub and R2 and R3 being the spokes.

R2 --(201)--(102)--R1--(103)--(301)--R3

IP address on R2 is 10.10.10.2/31, and IP address on R3 is 10.10.10.3/31.

Because the subnet mask is 31 bit, there is no space for R1. We have to run bridge over frame relay.

We will enable IRB on R2 and R3, and either IRB or CRB on R1. We will create two multipoint sub-interfaces on R1, to map the dlci with the bridge-group and bridge the DLCIs together.

Configurations below:

R1

bridge crb
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial1/0.1 multipoint
frame-relay map bridge 102 broadcast
bridge-group 1
!
interface Serial1/0.2 multipoint
frame-relay map bridge 103 broadcast
bridge-group 1
!
bridge 1 protocol ieee


R2

bridge irb
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay map bridge 201 broadcast
no frame-relay inverse-arp
bridge-group 1
!
interface BVI1
ip address 10.10.10.2 255.255.255.254
!
bridge 1 protocol ieee
bridge 1 route ip
!


R3

bridge irb
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay map bridge 301 broadcast
no frame-relay inverse-arp
bridge-group 1
!
interface BVI1
ip address 10.10.10.3 255.255.255.254
!
bridge 1 protocol ieee
bridge 1 route ip
!


Pinging R2 from R3 to test:
R3#ping 10.10.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/228/276 ms
R3#

Catalyst 3550 and WCCP

To enable WCCP on Cisco Catalyst 3550 switch, first, you need to enable the SDM for routing with extended-match:
sdm prefer routing extended-match

Secondly, enable wccp globly:
ip wccp web-cache

Thirdly, WCCP on 3550 can only run inbound redirect, so under the user interface, run
ip wccp web-cache redirect in

Frame-Relay Traffic Shaping and QoS

When configuring frame relay traffic shaping and applying service policy to the map-class, keep the followings in mind:

• Use 'max-reserved-bandwidth' interface command to change the bandwidth available.
• Configure the 'frame-relay mincir' under the map-class to guarantee the bandwidth.

Frame Relay Full Status Polling

Cisco Frame Relay interface will send 6 keeps of exchanges before requesting a full status message.

This is done by keepalive packets. Every 10 seconds, it sends out a keepalive message, and every 60 seconds (6 times of keepalives), it requests a full status message.

If not allowed to change the keepalive, you can use 'frame-relay lmi-n391dte keep-exchanges' command to change the number of keepalives to request the full status message.

For example, if you are required to change the full status message interval to 180 seconds, and you are not allowed to change the keepalive interval, you can change the keep-exchanges to 18 using 'frame-relay lmi-n391dte 18'.

TCL Script to Test Reachabilities

After you finish configuration the routing protocols and redistributions, you need to test connectivity to all the interfaces for all routers.

We can configure TCL Script to achieve this:

Router##tclsh
+>foreach address {
+>192.168.1.1
+>192.168.1.2
+>192.168.1.3
+>192.168.1.4
+>} { ping $address }
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/86/89 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router(tcl)#exit
Router#

Reflective ACL and Local PBR

The locally generated traffic from the router doesn't go through the ACL configured on the interface, so it would be some problem for the reflective ACL. The ACL won't allow the return traffic to pass through.

R1------Frame Relay------R2

R1 Configuration:

interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial1/0.1 point-to-point
ip address 10.1.12.1 255.255.255.0
ip access-group inbound in
ip access-group outbound out
frame-relay interface-dlci 102
!
ip access-list extended inbound
permit ospf any any
evaluate TELNET
ip access-list extended outbound
permit ospf any any
permit tcp any any eq telnet reflect TELNET
!

R2 Configuration:
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial1/0.1 point-to-point
ip address 10.1.12.2 255.255.255.0
frame-relay interface-dlci 201
!

Telnet from R1 to R2 will be timed out.

What you can do is to create a loopback interface on R1 and configure a local PBR to direct the telnet traffic generated from R1 to go to the loopback interface.

R1:
interface Loopback0
ip address 10.10.10.10 255.255.255.255
!
access-list 100 permit tcp any any eq telnet
!
!
!
route-map myPolicy permit 10
match ip address 100
set ip next-hop 10.10.10.10
!
ip local policy route-map myPolicy
!

By doing so, you force the traffic generated from the router to go back into the routing process, and go through the outbound ACL. And the reflective ACL would open a stateful hole for the return traffic.