woojar

Japan team prepared cisco 2651xm+VIC_2BRI_NT to test communication between CME and our MAG. The below is configuration file:

>
User Access Verification> >Password:
CCME>en
Password:
CCME#show run
Building configuration…> >Current configuration : 3218 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname CCME
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
no aaa new-model
!
resource policy
!
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.19.1 192.168.19.99
ip dhcp excluded-address 192.168.19.200 192.168.19.254
!
ip dhcp pool cme
   network 192.168.19.0 255.255.255.0
   default-router 192.168.19.1
   option 150 ip 192.168.19.2
!
!
no ip domain lookup
isdn switch-type ntt
voice-card 1
!
!
!
trunk group  WORD
!
!
voice call send-alert
voice rtp send-recv
!
voice service voip
 sip
!
!
!
!
!
!
!
!
!
!
!
!
voice translation-rule 1
 rule 1 /^5320279/ /279/
!
voice translation-rule 2
 rule 1 /^2791/ /53202791/
 rule 2 /^2792/ /53202792/
!
voice translation-rule 3
 rule 1 /^2791/ /3030802791/
 rule 2 /^2792/ /3030802792/
!
!
voice translation-profile PSTNin
 translate called 1
!
voice translation-profile PSTNout
 translate calling 2
!
voice translation-profile SIPout
 translate calling 3
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
 ip address 192.168.19.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface BRI1/0
 no ip address
 isdn switch-type ntt
 isdn point-to-point-setup
 isdn incoming-voice voice
 isdn map address .* plan unknown type unknown
!
interface BRI1/1
 no ip address
 isdn switch-type ntt
 isdn point-to-point-setup
 isdn incoming-voice voice
 isdn map address .* plan unknown type unknown
!
ip route 0.0.0.0 0.0.0.0 192.168.19.1
!
ip http server
no ip http secure-server
!
!
!
control-plane
!
!
!
voice-port 1/0/0
 cptone JP
!
voice-port 1/0/1
 cptone JP
!
!
!
!
!
dial-peer voice 1001 pots
 translation-profile outgoing PSTNout
 destination-pattern 0T
 port 1/0/0
!
dial-peer voice 1002 pots
 translation-profile outgoing PSTNout
 preference 1
 destination-pattern 0T
 port 1/0/1
!
dial-peer voice 2001 pots
 incoming called-number 53202790
 port 1/0/0
!
dial-peer voice 2002 pots
 preference 1
 incoming called-number 53202790
 port 1/0/1
!
dial-peer voice 2011 pots
 translation-profile incoming PSTNin
 incoming called-number 5320279[1-5]
 direct-inward-dial
 port 1/0/0
!
dial-peer voice 2012 pots
 translation-profile incoming PSTNin
 preference 1
 incoming called-number 5320279[1-5]
 direct-inward-dial
 port 1/0/1
!
dial-peer voice 3001 voip
 translation-profile outgoing SIPout
 destination-pattern 279[3-5]
 session protocol sipv2
 session target ipv4:192.168.19.200:5061
 session transport udp
 codec g711ulaw
 no vad
!
!
!
telephony-service
 max-ephones 4
 max-dn 8
 ip source-address 192.168.19.2 port 2000
 time-format 24
 max-conferences 4 gain -6
 moh flash:/music-on-hold.au
 transfer-system full-consult
 secondary-dialtone 0
 create cnf-files version-stamp Jan 01 2002 00:00:00
!
!
ephone-dn  1  dual-line
 number 2791
!
!
ephone-dn  2  dual-line
 number 2792
!
!
ephone  1
 mac-address 0002.4BCC.D77A
 button  1:1
!
!
!
ephone  2
 mac-address 0004.27E8.C8A8
 button  1:2
!
!
!
line con 0
line aux 0
line vty 0 4
 password cisco
 login
!
!
end> >CCME#dir flash:
Directory of flash:/> >    1  -rw-    25269228                      c2600-ipvoicek9-mz.124-9.T.bin
    2  -rw-      496521                      music-on-hold.au> >49807356 bytes total (24041476 bytes free)
CCME#>The other infomation as refferrence:>Cisco 2651XM (MPC860P) processor (revision 3.1) with 253952K/8192K bytes of memory.
Processor board ID FOC08382FWH
M860 processor: part number 5, mask 2
2 FastEthernet interfaces
2 ISDN Basic Rate interfaces
32K bytes of NVRAM.
49152K bytes of processor board System flash (Read/Write)>Configuration register is 0×2102> > 

The Berkeley Internet Name Domain (BIND) is a distributed network information lookup service. It allows you to retrieve host names and Internet addresses for any node on the network. It also provides mail routing capability by supplying a list of hosts that accept mail for other hosts

You can configure your host as any of the following types of BIND name servers:

>

• >

  Master Server

  A master server is the authority for its domain and contains data corresponding to its domain. The master server obtains its information from a master file on the disk. On previous versions of BIND, the master server was referred to as a primary server.

• >

  Slave Server

  A slave server is also the authority for its domain and contains the domain’s data, but it receives data over a network fromanother master server. On previous versions of BIND, the slave server was referred to as a secondary server.

• >

  Caching-Only Server

  A caching-only server is not authoritative for any domain. The only function that a caching-only server performs is to look up data from an authoritative server and store the data in its cache.

• >

  Forwarding Server

  A forwarding server always forwards queries that it cannot satisfy from its authoritative data or cache to a fixed list of other servers. A forwarding server is typically used when you do not want all the servers at a given site to interact with the rest of the Internet servers. An added benefit of using the forwarding feature is that the forwarding server develops a complete cache of information that all the workstations can use.

If you do not want to run a name server on your host, you can configure the resolver to query a name server on another host. By default, the resolver is configured to query the name server on the local host.

	NOTE: Throughout this document, the terms zone and domain are used interchangeably, though they describe different concepts. A zone describes the domain name spacethat a name server has authority over. As such, a zone does not contain any delegated subdomains, whereas a domain can contain data delegated to other name servers. Therefore, as long as subdomains are not delegated, a zone and a domain contain the same data.

>>>>

Choosing the Type of Name Server

>

You can use any server configuration on a host. Following are some suggestions for the configuration:

>

• >

  You must configure timeshare machines or cluster servers as master or slave servers.

• >

  If you want the benefits of a name server but do not want to maintain authoritative data, you can set up a caching-only server. Running a caching-only server provides you better performance than querying a name server on a remote system, especially if the remote system is on the other side of a gateway or router.

• >

  You must configure PCs, workstations that do not want to maintain a server, and other small networked systems to query a name server on another host. Cluster nodes must query the name server on the cluster server.

• >

  If your network is isolated from the Internet, and your host is the only BIND name server in your organization, you must configure a root name server. See “Configuring a Root Name Server” for information.

The configuration file, /etc/named.conf, informs the master server of the location of all the required data files. The master name server loads its database from these data files. The hosts_to_named program creates the named.conf file.

Following is an example configuration file for a master server authoritative for the domain div.inc.com, and for the network 15.19.8.

## type domain source file#option {         directory “/etc/named.data”;};zone “0.0.127.IN-ADDR.ARPA” {         type master;         file “db.127.0.0”;};zone “div.inc.com” {       type master;       file “db.div”;

};zone “8.19.15.IN-ADDR.ARPA” {       type master;       file “db.15.19.8”;};zone “.” {       type hint;       file “db.cache”;};

Figure 2-1 “Structure of a Master Server and Slave Servers” shows the structure of a master server and a slave server. In the Figure 2-1 “Structure of a Master Server and Slave Servers”, the master server is rabbit.div.inc.com and the slave servers are cheetah.div.inc.com and indigo.div.inc.com.

>

Figure 2-1 Structure of a Master Server and Slave Servers

Master server data File

A master server has one /etc/named.data/db.domain file for each domain for which it is authoritative. domain is the first part of the domain specified with the -d option in the hosts_to_named command. This file must contain an A (address) record for every host in the zone.

The following is an example db.div file:

;; db.div;＄TTL    86400@   IN   SOA   rabbit.div.inc.com root.moon.div.inc.com (     1          ; Serial     10800      ; Refresh every 3 hours     3600       ; Retry every hour     604800     ; Expires after a week     86400      ; Minimum ttl of 1 day    IN   NS    rabbit.div.inc.com    IN   NS    indigo.div.inc.comlocalhost IN    A   127.0.0.1indigo    IN    A   15.19.8.197          IN    A   15.19.13.197          IN    HINFO  HP9000/840 HPUXincindigo IN    CNAME   indigo

cheetah   IN    A      15.19.8.64          IN    HINFO  HP9000/850  HPUX          IN    WKS    15.19.8.64  UPD  syslog  domain  route           IN    WKS    15.19.8.64  TCP (telnet smtp ftp shell domain)rabbit    IN    MX    5   rabbit.div.inc.com          IN    MX   10   indigo.div.inc.comrabbit     IN    A         15.19.8.119

The example file db.div contains the following types of records:

>

The above resources is from www.hp.com.
Detailed information about BIND9, Please reffer to www.bind9.net

计世网特约撰稿 曹江华

一、DNS服务器的重要性

DNS是因特网建设的基础，几乎所有的网络应用, 都必须依赖 DNS 系统做网址查询的指引动作。如果 DNS 系统运作不正常, 即使Web 服务器都完好如

初, 防火墙系统都善尽其职, 相关的后端应用服务器以及数据库系统运作正常, 因为无法在期限时间内查得到网址, 将会导致电子邮件无法传递, 想要使用网域名称去连接某个网页, 也会因查不出网络地址, 以致联机失败。2001年1月24日, 美国微软公司所管理的相关网络系统, 遭受网络黑客的拒绝服务攻击后导致全球各地的用户 接近 24 小时的时间 无法连上该公司相关的网站, 造成该公司相当严重的商业损失。根据以往的经验之中, 网络攻击的对象 多数主要集中在控制网络路由的设备(路由器, 防火墙等)和各类应用服务器(Web、邮件 等)。因此,目前多数的网络系统安全保护, 通常都集中在路由设备和应用服务器本身。然而, 这一次的微软公司被攻击事件, 与以往其它网站攻击事件的最大不同, 就在于这一次被攻击的对象是 DNS 服务器 而不是 WEB 服务器本身。这次的事件宣告另一种新型的网络攻击类别, 往后将可能成为常态。互联网上DNS服务器的事实标准就是ISC（http://www.isc.org/ ）公司的Berkeley Internert Name Domain(BIND)，它具有广泛的使用基础，互联网上的绝大多数DNS服务器都是基于这个软件的。Netcraft在域名服务器上的统计(http://www.netcraft.com/ )显示 2003年第二季度进行的一个调查发现，在互联网上运行着的DNS服务器中，ISC的BIND占据了95%的市场份额。互联网是由很多不可见的基础构件组成。这其中就包含了DNS，它给用户提供了易于记忆的机器名称(比如sina.com)，并且将它们翻译成数字地址的形式。对于那些用于公共服务的机器一般还提供“反向查询”的功能，这种功能可以把数字转换成名字。由于历史的原因，这种功能使用的是被隐藏的“in-addr.arpa”域。对in-addr域的调查，可以让我们更加了解整个Internet是如何运作的。Bill Manning对in-addr域的调查发现，有95%的域名服务器(2的2000次方个服务器中)使用的是各种版本的“bind”。这其中包括了所有的DNS根服务器，而这些根服务器对整个服务器的正常运转起着至关重要的作用。如何能加强确保 DNS 系统的运作正常, 或者当DNS系统在遭受网络攻击时候, 能够让管理者及早发现是日益重要的系统安全的课题。首先我们要了解DNS服务面临的安全问题。

二、DNS服务面临的安全问题：
DNS服务面临的安全问题主要包括：DNS欺骗（DNS Spoffing）、拒绝服务（Denial of service，DoS）攻击、分布式拒绝服务攻击和缓冲区漏洞溢出攻击（Buffer Overflow）。

1.DNS欺骗
DNS欺骗即域名信息欺骗是最常见的DNS安全问题。当一个DNS服务器掉入陷阱，使用了来自一个恶意DNS服务器的错误信息，那么该DNS服务器就被欺骗了。DNS欺骗会使那些易受攻击的DNS服务器产生许多安全问题，例如：将用户引导到错误的互联网站点，或者发送一个电子邮件到一个未经授权的邮件服务器。网络攻击者通常通过三种方法进行DNS欺骗。图1是一个典型的DNS欺骗的示意图。

图1 典型DNS欺骗过程
（1）缓存感染
黑客会熟练的使用DNS请求，将数据放入一个没有设防的DNS服务器的缓存当中。这些缓存信息会在客户进行DNS访问时返回给客户，从而将客户引导到入侵者所设置的运行木马的Web服务器或邮件服务器上，然后黑客从这些服务器上获取用户信息。
（2）DNS信息劫持
入侵者通过监听客户端和DNS服务器的对话，通过猜测服务器响应给客户端的DNS查询ID。每个DNS报文包括一个相关联的16位ID号，DNS服务器根据这个ID号获取请求源位置。黑客在DNS服务器之前将虚假的响应交给用户，从而欺骗客户端去访问恶意的网站。
（3）DNS复位定向
攻击者能够将DNS名称查询复位向到恶意DNS服务器。这样攻击者可以获得DNS服务器的写权限。

2.拒绝服务攻击
黑客主要利用一些DNS软件的漏洞，如在BIND 9版本（版本9.2.0以前的 9系列）如果有人向运行BIND的设备发送特定的DNS数据包请求，BIND就会自动关闭。攻击者只能使BIND关闭，而无法在服务器上执行任意命令。如果得不到DNS服务，那么就会产生一场灾难：由于网址不能解析为IP地址，用户将无方访问互联网。这样，DNS产生的问题就好像是互联网本身所产生的问题，这将导致大量的混乱。

3、分布式拒绝服务攻击
DDOS 攻击通过使用攻击者控制的几十台或几百台计算机攻击一台主机，使得服务
拒绝攻击更难以防范：使服务拒绝攻击更难以通过阻塞单一攻击源主机的数据流，来防范服务拒绝攻击。Syn Flood是针对DNS服务器最常见的分布式拒绝服务攻击。

4.缓冲区漏洞
Bind软件的缺省设置是允许主机间进行区域传输（zone transfer）。区域传输主要用于主域名服务器与辅域名服务器之间的数据同步，使辅域名服务器可以从主域名服务器获得新的数据信息。一旦起用区域传输而不做任何限制，很可能会造成信息泄漏，黑客将可以获得整个授权区域内的所有主机的信息，判断主机功能及安全性，从中发现目标进行攻击。

应对以上这些安全问题有两个比较有效方法：TSIG和DNSSEC技术。

二、TSIG技术
DNS 的事务签名分为 TSIG (Transaction Signatures) 与 SIG0 (SIGnature)两种。该如何选择呢? 首先，要先判断客户端与服务器间的信任关系为何，若是可信任者，可选择对称式的 TSIG。TSIG 只有一组密码，并无公开/私密金钥之分；若是非完全信任者，可选择非对称式金钥的 SIG0，虽有公开/私密金钥之分，相对的，设定上也较复杂。至于要选用哪种较适合，就由自己来判断。通常区带传输是主域名服务器到辅助域名服务器。通常在主域名服务器配置文件/etc/named.conf的dns-ip-list的访问控制列表（ACL，access control list）会列出一些IP地址，它们只能为主域进行传输区带信息。一个典型例子如下：

acl“dns-ip-list” {
172.20.15.100;
172.20.15.123;
};
zone “yourdomain.com” {
type master;
file “mydomain.dns”;
allow-query { any; };
allow-update { none; };
allow-transfer { dns-ip-list; }; };
都是黑客会利用IP欺骗一个DNS服务器，迫使其进行非法区带传输。TSIG技术可以进行有效防范。1.TSIG技术
　　交易签章 (TSIGRFC 2845)，是为了保护 DNS安全而发展的。从BIND 8.2版本开始引入 TSIG 机制，其验证 DNS 讯息方式是使用共享金钥 (Secret Key) 及单向杂凑函式(One-way hash function) 来提供讯息的验证和数据的完整性。主要针对区带传输（ZONE Transfer）进行保护的作用，利用密码学编码方式为通讯传输信息加密以保证 DNS 讯息的安全，特别是响应与更新的讯息数据。也就是说在DNS服务器之间进行辖区传送时所提供保护的机制，以确保传输数据不被窃取及监听。下面以BIND 9.21为例：
首先在开始设置，必须为主域名服务器（master DNS）和辅助域名（ slave DNS） 进行时间同步，否则会造成区带传输的失败。可以使用ntp或者rdate工具进行服务器时间同步。
假设要限制yourdomain.com的主域到IP地址分别是172.20.15.100 (ns1.yourdomain. com) 和 172.20.15.123 (ns2.yourdomain.com). 的两个辅助域名服务器之间进行区带传输。在此将详述 TSIG 的实际操作，可以防止DNS服务器和黑客的DNS服务器之间不会发生IP欺骗。
步骤一：执行 dnssec-keygen function 产生加密金钥，一个为 public key 文件，另一个
为 private key 文件：
产生加密金钥：dnssec-keygen -a hmac-md5 -b 128 -n HOST zone-xfr-key
该文件中公开金钥（public key）是： Kzone-xfr-key.+157+08825.key；私有金钥（private key）是Kzone-xfr-key.+157+08825.private。此时查看文件通常包括以下内容：

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: YH8Onz5×0/twQnvYPyh1qg==

步骤二：使用TSIG 金钥在主域名服务器和辅助域名服务器的设置文件named.conf设定：
key zone-xfr-key {
algorithm hmac-md5;
secret “YH8Onz5×0/twQnvYPyh1qg==”;
};

步骤三：将下面的声明加入服务器ns1.yourdomain.com的设置文件/etc/named.conf中：
server 172.20.15.123 {
keys { zone-xfr-key; };
};

步骤四：将下面的声明加入服务器ns2.yourdomain.com的设置文件/etc/named.conf中：
server 172.20.15.100 {
keys { zone-xfr-key; };
};

步骤五：为主域名服务器ns1.yourdomain.com的yourdomain.com区带的设置文件/etc/named.conf写入以下配置：
acl “dns-ip-list” {
172.20.15.100;
172.20.15.123;
};
key zone-xfr-key {
algorithm hmac-md5;
secret “YH8Onz5×0/twQnvYPyh1qg==”;
};
server 172.20.15.123 {
keys { zone-xfr-key; };
};
zone “yourdomain.com” {
type master;
file “mydomain.dns”;
allow-query { any; };
allow-update { none; };
allow-transfer { dns-ip-list; };
};

步骤六：为辅助域名服务器ns2.yourdomain.com的yourdomain.com区带的设置文件/etc/named.conf写入以下配置：
acl “dns-ip-list” {
172.20.15.100;
172.20.15.123;
};
key zone-xfr-key {
algorithm hmac-md5;
secret “YH8Onz5×0/twQnvYPyh1qg==”;
};
server 172.20.15.100 {
keys { zone-xfr-key; };
};
zone “yourdomain.com” {
type master;
file “mydomain.dns”;
allow-query { any; };
allow-update { none; };
allow-transfer { dns-ip-list; };
};

步骤七：再次重新启动主域名服务器和辅助域名服务器。
说明为确保安全性的问题，TSIG 可确认 DNS 之信息是由某特定 DNS Server 所提供。通常
TSIG 应用于域名服务器间的区带传输，确保数据不会被篡改或产生 dns spoofing。
步骤八：
验证TSIG技术是否生效，步骤如下：
 删除辅助域名服务器(ns2.yourdomain.com)的区带文件。
 重新启动辅助域名服务器。
 检查辅助域名服务器的区带文件是否自动建立。辅助域名服务器用来从主服务器中转移一整套域信息。区带文件是从主服务器转移出的，作为磁盘文件保存在辅助域名服务器中。
注意事项：如果为域名服务器配置了TSIG，那么要确保普通用户不能接触主域名服务器和辅助域名服务器的配置文件/etc/named.conf。另外也不能修改两台服务器的共享的TSIG密钥。

2.SIG0 技术简介
SIG0是一九九九年三月 由 IBM公司的D. Eastlake 提出成为标准。其是利用公开金钥机制为辖区资料进行数字签章的动作，以保证每笔传输的 source record 具有可验证性与不可否认性。实际上 SIG0 才是防止 DNS Spoofing 发生最主要的技术，SIG0 是使用公开金钥加密法，让辖区管理者为其辖区数据加上数字签章，由此证明辖区资料的可信赖性。除此之外，SIG0 保有是否选择认证机制的弹性，以及可灵活地配合自订的安全机制。

三、DNSSEC技术

DNS欺骗是对目前网络应用, 最大的冲击在于冒名者借着提供假的网域名称与网址的对照信息, 可以将不知情用户的网页联机, 导引到错误的网站, 原本属于用户的电子邮件也可能因而遗失, 甚而进一步空开成为阻断服务的攻击。所幸, 目前较新的 BIND 版本, 针对这一类问题, 已经有加入许多改进的方法, 不过真正的解决方案, 则有赖封包认证机制的建立与推动。DNSSEC就是试图解决这一类问题的全新机制, BIND9 已经完整加以设计并完成。DNSSEC引入两个全新的资源记录类型：KEY和SIG，允许客户端和域名服务器对任何DNS数据的来源进行密码验证。

DNSSEC主要依靠公钥技术对于包含在DNS中的信息创建密码签名。密码签名通过计算出一个密码hash数来提供DNS中数据的完整性，并将该hash 数封装进行保护。私/公钥对中的私钥用来封装hash数，然后可以用公钥把hash数译出来。如果这个译出的hash值匹配接收者刚刚计算出来的hash树，那么表明数据是完整的。不管译出来的hash数和计算出来的hash数是否匹配，对于密码签名这种认证方式都是绝对正确的，因为公钥仅仅用于解密合法的hash数，所以只有拥有私钥的拥有者可以加密这些信息。下面我们看看如何为名称是domain.com的域建立DESSEC配置。

步骤一：为 domain.com 域建立一对密钥。在 /var/named 目录下,使用命令： “/usr/local/sbin/dnssec-keygen -a DSA -b 768 -n ZONE domain.com” 这个命令产生一对长度768位DSA算法的私有密钥（Kdomain.com.+003+29462.private）和公共密钥（Kdomain.com.+003+29462.key）。其中29462称作密钥标签（ key tag）。

步骤二：使用命令：“ /usr/local/sbin/dnssec-makekeyset -t 3600 -e now+30 Kdomain.com.+003+29462“建立一个密钥集合。该命令以3,600 seconds 的生存时间（time-to-live）建立密钥集合，有效期限三十天，并且创建一个文件：domain.com.keyset。

步骤三：使用命令“ /usr/local/sbin/dnssec-signkey domain.com.keyset Kdomain.com.+003+29462 “为密钥集合签字。然后建立一个签字文件：domain.com.signedkey。

步骤四：使用命令 “/usr/local/sbin/dnssec-signzone -o domain.com domain.db command, where domain.db ”为区带文件签字。然后建立一个签字文件： domain.db.signed。

步骤五：替换 配置文件/etc/named.conf中 domain.com的区带文件部分。清单如下：
zone “domain.com” IN {
type master;
file “domain.db.signed”;
allow-update { none; }; };

从上面的配置过程我们也看到DNSSEC的一些缺点：
除了配置负责，还有标记和校验DNS数据显然会产生额外的开销，从而影响网络和服务器的性能。签名的数据量很大，这就加重了域名服务器对互联网骨干以及一些非骨干连接的负担。产生和校验签名也占用了很多中央处理器的时间。有时候，不得不把单处理器的DNS服务器换成多处理器的DNSSEC服务器。签名和密钥占用的磁盘空间和RAM容量达到它们表示的数据所占容量的10倍。同时数据库和管理系统也不得不进行相应的升级和扩容。

总结：域名系统的配置和管理是一项比较复杂和繁琐的系统管理任务，它对整个网络的运行影响极大。为了保证DNS服务器的安全运行，不仅要使用可靠的服务器软件版本，而且要对DNS服务器进行安全配置，本文介绍了TISG和DNSSEC技术有助于减少 DNS Spoofing 攻击的发生，增进网络使用者对因特网使用的信任，杜绝信息系统遭受入侵与攻击的产生。

 Cisco ip phones can support several voip protocols:
 SCCP, H.323, SIP, MGCP. 
I had upgraded one cisco ip phone 7905G from H.323 to
 SCCP to adapt CCME. 
 Note the below steps when you upgrade your ip phone.

1.Download correct version firmware to
 your TFTP root directory 
2.Add and edit the default configuration file 
XMLDefault.cnf.xml. The following file is default format:
   
      
   2000                 
  2427 
  2428 
 CP7902080001SCCP051117A 
 CP7905080001SCCP051117A 
 P00405000700  
 SCCP11.8-0-1-0S 
 CP7912080001SCCP051117A 
 cmterm_7920.4.0-02-01 
 P00503011200 
 cmterm_7936.3-3-9-0 
 P00308000100 
 SCCP41.8-0-1-0S 
 SCCP41.8-0-1-0S 
 P00308000100 
 SCCP41.8-0-1-0S 
 SCCP41.8-0-1-0S 
 SCCP70.8-0-1-0S 
 SCCP70.8-0-1-0S 
 cmterm_7985.4-0-2-0 
  
  
  
 ATA030203SCCP051201A 
  
  
  
  
  
  
  
 
About details of the default filek,Please refer to 
http://www.voip-info.org/wiki/index.php?page=Asterisk+phone+cisco+79xx
3. Reset your IP phone to download the firmware from your 
TFTP server