Dec 12, 2008

Received Signal Strength Indication(RSSI)

In telecommunications, Received Signal Strength Indication (RSSI) is a measurement of the power present in a received radio signal.

RSSI is generic radio receiver technology metric, which is usually invisible to the user of device containing the receiver, but is directly known to users of wireless networking of IEEE 802.11 protocol family.

RSSI is often done in the intermediate frequency (IF) stage before the IF amplifier. In zero-IF systems, it is done in the baseband signal chain, before the baseband amplifier. RSSI output is often a DC analog level. It can also be sampled by an internal ADC and the resulting codes available directly or via peripheral or internal processor bus.

RSSI in 802.11 implementations
In an IEEE 802.11 system RSSI is the received signal strength in a wireless environment, in arbitrary units. RSSI can be used internally in a wireless networking card to determine when the amount of radio energy in the channel is below a certain threshold at which point the network card is clear to send (CTS). Once the card is clear to send, a packet of information can be sent. The end-user will likely observe an RSSI value when measuring the signal strength of a wireless network through the use of a wireless network monitoring tool like Network Stumbler or Inssider (for Windows Vista).

RSSI measurements will vary from 0 to a maximum of 255 depending on the vendor. It consists of a one-byte integer value. A value of 1 will indicate the minimum signal strength detectable by the wireless card, while 0 indicates no signal. The value has a maximum of RSSI_Max. For example, Cisco Systems cards will return an RSSI of 0 to 100. In this case, the RSSI_Max is 100. The Cisco card can report 101 distinct power levels. Another popular Wi-Fi chipset is made by Atheros. An Atheros based card will return an RSSI value of 0 to 127 and a value of 0x80 indicates an invalid number

The subtlety of 802.11 RSSI comes from how it's sampled; RSSI is acquired during the preamble stage of receiving an 802.11 frame. To this extent 802.11 RSSI has (for the most part) been replaced with RCPI; a functional measurement covering the entire received frame with defined absolute levels of accuracy and resolution.

RSSI is stored on TX/RX descriptor and was measured by baseband and PHY for each individual packet.

Simple Object Access Protocol(SOAP)

SOAP的全名為Simple Object Access Protocol(簡易物件通訊協定),是一種以XML為基礎的通訊協定,其作用是編譯網路服務所需的要求或回應後,再將編譯後的訊息送出到網路,簡單來說就是應用程式和用戶之間傳輸資料的一種機制。

SOAP的全名為Simple Object Access Protocol(簡易物件通訊協定),是一種以XML為基礎的通訊協定,其作用是編譯網路服務所需的要求或回應後,再將編譯後的訊息送出到網路,簡單來說就是應用程式和用戶之間傳輸資料的一種機制。

SOAP是一個獨立的訊息,可以獨自運作在不同的作業系統與網路上面,例如在微軟的Windows或Linux的建構下運作,並可以使用各種不同的通訊方式來作傳輸,例如SMTP、MIME,或是HTTP等。

近來W3C對於建立網路服務的協定不遺於力,尤其W3C對於SOAP的1.2版更新工作更是已經接近完工的階段。在SOAP1.2版中,包含了一個用於簡化網路的工具包,這個工具包擁有許多1.1版未有的工具,例如可讓開發者建立管理SOAP訊息規則的「處理模型」,以及包含簡易管理大量的XML文檔功能。

不過因為SOAP還未到達完成的階段,所以W3C現今只定位SOAP1.2版為「建議性的網路服務開發工具」。

SOAP的架構為:Envelope、Header、Body,和Fault四個部份;其組織架構是與XML的語法相結合應用,換句話說SOAP是由XML語法所寫而成。

SOAP不但可以在不同的網路上運作,更可以在不同的網路間作傳輸,如圖3所示,SOAP可以透過HTTP發送訊息,再透過TCP、MSMQ,最後由SMTP收到訊息,途中可以透過四個不同的傳輸點傳達訊息。由此我們可以見到SOAP的透通性與實用性,遠比一般的通訊協定更為有彈性。

Dec 11, 2008

Cipher Block Chaining Message Authentication Code Protocol (CCMP)

Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) is an encryption protocol that forms part of the 802.11i standard for wireless local area networks (WLANs), particularly those using WiMax technology. The CCMP algorithm is based on the U.S. federal government's Advanced Encryption Standard (AES).
CCMP offers enhanced security compared with similar technologies such as Temporal Key Integrity Protocol (TKIP). CCMP employs 128-bit keys and a 48-bit initialization vector that minimizes vulnerability to replay attacks. The Counter Mode component provides data privacy. The Cipher Block Chaining Message Authentication Code component provides data integrity and authentication. The enhanced privacy and security of CCMP compared with TKIP requires additional processing power, often necessitating new or upgraded hardware.

802.11i is a standard for WLANs that provides encryption for networks that use the 802.11a, 802.11b and 802.11g standards. The AES is an encryption algorithm for securing sensitive but unclassified material by government agencies. It may eventually become the de facto encryption standard for commercial transactions in the private sector.

Proactive Key Caching(PKC)

PKC is an IEEE 802.11i extension that allows for the proactive caching (before the client roaming event) of the WPA/WPA2 PMK that is derived during a client IEEE 802.1 x/EAP authentication at the AP. If a PMK (for a given WLAN client) is already present at an AP when presented by the associating client, full IEEE 802.1X/EAP authentication is not required. Instead, the WLAN client can simply use the WPA 4-way handshake process to securely derive a new session encryption key for communication with that AP.

Note PKC is an IEEE 802.11i extension and so is supported in WPA2—not WPA.

Basic Service Set(BSS)



The Basic Service Set is a term used to describe the collection of Stations which may communicate together within an 802.11 WLAN (Wireless Local Area Network).

The BSS may or may not include AP (Access Point) which provide a connection onto a fixed distribution system such as an Ethernet network. Two types of BSS exist; IBSS (Independent Basic Service Set) and Infrastructure Basic Service Set.

EAP-TTLS(Extensible Authentication Protocol-Tunneled Transport Layer Security)

EAP-Tunneled Transport Layer Security, or EAP-TTLS is an EAP protocol that extends TLS. It was co-developed by Funk Software and Certicom. It is widely supported across platforms, although there is no native OS support for this EAP protocol in Microsoft Windows, it requires the installation of small extra programs such as SecureW2.

EAP-TTLS offers very good security. The client does not need be authenticated via a CA-signed PKI certificate to the server, but only the server to the client. This greatly simplifies the setup procedure as a certificate does not need to be installed on every client.

After the server is securely authenticated to the client via its CA certificate, the server can then use the established secure connection ("tunnel") to authenticate the client. It can use an existing and widely deployed authentication protocol and infrastructure, incorporating legacy password mechanisms and authentication databases, while the secure tunnel provides protection from eavesdropping and man-in-the-middle attack. Note that the user's name is never transmitted in unencrypted cleartext, thus improving privacy.

EAP TTLS is described in RFC 5281.

EAP-MD5(Extensible Authentication Protocol-Message Digest 5)

EAP-MD5, defined in RFC 3748, is the only IETF Standards Track based EAP method. It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise. EAP-MD5 differs from other EAP methods in that it only provides authentication of the EAP peer to the EAP server but not mutual authentication. By not providing EAP server authentication, this EAP method is vulnerable to man-in-the-middle attacks.

EAP-SIM(Extensible Authentication Protocol-Subscriber Identity Module)

Extensible Authentication Protocol Method for GSM Subscriber Identity, or EAP-SIM, is an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). EAP-SIM is described in RFC 4186.

Public Key Infrastructure(PKI)

In cryptography, a public key infrastructure (PKI) is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. The PKI role that assures this binding is called the Registration Authority (RA) . For each user, the user identity, the public key, their binding, validity conditions and other attributes are made unforgeable in public key certificates issued by the CA.

The term trusted third party (TTP) may also be used for certificate authority (CA). The term PKI is sometimes erroneously used to denote public key algorithms, which do not require the use of a CA.

Protected Access Credentials(PAC)

Protected Access Credentials (PACs) are credentials that are distributed to clients for optimized network authentication. PACs can be used to establish an authentication tunnel between the client and the authentication server (the first phase of authentication as described in the "Two-Phase Tunneled Authentication" section). A PAC consists of, at most, three components: a shared secret, an opaque element, and other information.

The shared secret component contains the pre-shared key between the client and authentication server. Called the PAC-Key, this pre-shared key establishes the tunnel in the first phase of authentication.

The opaque component is provided to the client and is presented to the authentication server when the client wants to obtain access to network resources. Called the PAC-Opaque, this component is a variable length field that is sent to the authentication server during tunnel establishment. The EAP server interprets the PAC-Opaque to obtain the required information to validate the client's identity and authentication. The PAC-Opaque includes the PAC-Key and may contain the PAC's client identity.

The PAC might contain other information. Called PAC-Info, this component is a variable length field that is used to provide, at a minimum, the authority identity of the PAC issuer (the server that created the PAC). Other useful but not mandatory information, such as the PAC-Key lifetime, can also be conveyed by the PAC-issuing server to the client during PAC provisioning or refreshment.

PACs are created and issued by a PAC authority, such as Cisco Secure ACS, and are identified by an ID. A user obtains his or her own copy of a PAC from a server, and the ID links the PAC to a profile.

Persistent PACs, such as machine PACs, are stored in the EAP-FAST registry and encrypted. These PACs are also protected with access control lists (ACLs) so only designated users (the owners of the PACs) and members of privileged user groups (for example, administrators) can access them. Machine PACs are stored globally so that all users of a machine can use the PACs.

All PACs are encrypted and tied to the host machine with Microsoft Crypto API (CryptoProtectData). PACs cannot be copied and used on other machines.

All non-persistent PACs, such as User Authorization PACs, are stored in volatile memory and do not persist after reboot or after a user has logged off.

Cisco Centralized Key Management(CCKM)

CCKM is a term used in wireless networks. It stands for Cisco Centralized Key Management, which is a form of Fast Roaming. When a wireless LAN is configured for fast reconnection, a LEAP enabled client device can roam from one access point to another without involving the main server. Using Cisco (TM) Centralized Key Management (CCKM), an access point configured to provide Wireless Domain Services (WDS) takes the place of the RADIUS server and authenticates the client without perceptible delay in voice or other time-sensitive applications.

Actually, the WDS (which can be run as a service on a Cisco Access Point or on various router modules) caches the user credentials after the initial log-on. The user must authenticate with the Radius server the first time - then he can roam between access points using cached credentials. This saves time in the roaming process, especially valuable for IP Telephones.

The current implementation of CCKM requires Cisco compatible hardware and either LEAP, EAP-Fast (CCXv3) or PEAP-GTC, PEAP-MSCHAP, EAP-TLS (CCXv4).

Dec 10, 2008

Network Access Identifier(NAI) - RFC2486

RFC2486 - The Network Access Identifier

Network Working Group B. Aboba
Request for Comments: 2486 Microsoft
Category: Standards Track M. Beadles
WorldCom Advanced Networks
January 1999

The Network Access Identifier

Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Abstract

In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users. This document proposes syntax for the Network
Access Identifier (NAI), the userID submitted by the client during
PPP authentication. It is expected that this will be of interest for
support of roaming as well as tunneling. "Roaming capability" may be
loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of where roaming capabilities
might be required include ISP "confederations" and ISP-provided
corporate network access support.

2. Introduction

Considerable interest has arisen recently in a set of features that
fit within the general category of "roaming capability" for dialup
Internet users. Interested parties have included:

Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer dialup service
over a wider area.

National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
dialup service in a group of countries or on a continent.

Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services
may include Internet access as well as secure access to
corporate intranets via a Virtual Private Network (VPN), enabled
by tunneling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel
mode.

In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users. This document proposes syntax for the Network
Access Identifier (NAI). Examples of implementations that use the
NAI, and descriptions of its semantics, can be found in [1].

2.1. Terminology

This document frequently uses the following terms:

Network Access Identifier
The Network Access Identifier (NAI) is the userID submitted
by the client during PPP authentication. In roaming, the
purpose of the NAI is to identify the user as well as to
assist in the routing of the authentication request.
Please note that the NAI may not necessarily be the same as
the user's e-mail address or the userID submitted in an
application layer authentication.

Network Access Server
The Network Access Server (NAS) is the device that clients
dial in order to get access to the network. In PPTP
terminology this is referred to as the PPTP Access
Concentrator (PAC), and in L2TP terminology, it is referred
to as the L2TP Access Concentrator (LAC).

Roaming Capability
Roaming capability can be loosely defined as the ability to
use any one of multiple Internet service providers (ISPs),
while maintaining a formal, customer-vendor relationship
with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-
provided corporate network access support.

Tunneling Service
A tunneling service is any network service enabled by
tunneling protocols such as PPTP, L2F, L2TP, and IPSEC
tunnel mode. One example of a tunneling service is secure
access to corporate intranets via a Virtual Private Network
(VPN).

2.2. Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [9].

2.3. Purpose

As described in [1], there are now a number of services implementing
dialup roaming, and the number of Internet Service Providers involved
in roaming consortia is increasing rapidly.

In order to be able to offer roaming capability, one of the
requirements is to be able to identify the user's home authentication
server. For use in roaming, this function is accomplished via the
Network Access Identifier (NAI) submitted by the user to the NAS in
the initial PPP authentication. It is also expected that NASes will
use the NAI as part of the process of opening a new tunnel, in order
to determine the tunnel endpoint.

2.4. Notes for Implementors

As proposed in this document, the Network Access Identifier is of the
form user@realm. Please note that while the user portion of the NAI
conforms to the BNF described in [5], the BNF of the realm portion
allows the realm to begin with a digit, which is not permitted by the
BNF described in [4]. This change was made to reflect current
practice; although not permitted by the BNF described in [4], FQDNs
such as 3com.com are commonly used, and accepted by current software.

Please note that NAS vendors may need to modify their devices so as
to support the NAI as described in this document. Devices handling
NAIs MUST support an NAI length of at least 72 octets.

3. Formal definition of the NAI

The grammar for the NAI is given below, described in ABNF as
documented in [7]. The grammar for the username is taken from [5],
and the grammar for the realm is an updated version of [4].

nai = username / ( username "@" realm )

username = dot-string

realm = realm "." label

label = let-dig * (ldh-str)

ldh-str = *( Alpha / Digit / "-" ) let-dig

dot-string = string / ( dot-string "." string )

string = char / ( string char )

char = c / ( "\" x )

let-dig = Alpha / Digit

Alpha = %x41-5A / %x61-7A ; A-Z / a-z

Digit = %x30-39 ;0-9

c = < any one of the 128 ASCII characters, but
not any special or SP >

x = %x00-7F
; all 127 ASCII characters, no exception

SP = %x20 ; Space character

special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
/ "," / ";" / ":" / "@" / %x22 / Ctl

Ctl = %x00-1F / %x7F
; the control characters (ASCII codes 0 through 31
; inclusive and 127)

Examples of valid Network Access Identifiers include:

fred@3com.com
fred@foo-9.com
fred_smith@big-co.com
fred=?#$&*+-/^smith@bigco.com
fred@bigco.com
nancy@eng.bigu.edu
eng!nancy@bigu.edu
eng%nancy@bigu.edu

Examples of invalid Network Access Identifiers include:

fred@foo
fred@foo_9.com
@howard.edu
fred@bigco.com@smallco.com
eng:nancy@bigu.edu
eng;nancy@bigu.edu
@bigu.edu

4. References

[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.

[2] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.

[3] Rigney C., "RADIUS Accounting", RFC 2139, April 1997.

[4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.

[5] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.

[6] Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.

[7] Crocker, D. and P. Overrell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[8] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.

[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

5. Security Considerations

Since an NAI reveals the home affiliation of a user, it may assist an
attacker in further probing the username space. Typically this
problem is of most concern in protocols which transmit the user name
in clear-text across the Internet, such as in RADIUS, described in
[2] and [3]. In order to prevent snooping of the user name,
protocols may use confidentiality services provided by IPSEC,
described in [8].

6. IANA Considerations

This document defines a new namespace that will need to be
administered, namely the NAI realm namespace. In order to to avoid
creating any new administrative procedures, administration of the NAI
realm namespace will piggyback on the administration of the DNS
namespace.

NAI realm names are required to be unique and the rights to use a
given NAI realm for roaming purposes are obtained coincident with
acquiring the rights to use a particular fully qualified domain name
(FQDN). Those wishing to use an NAI realm name should first acquire
the rights to use the corresponding FQDN. Using an NAI realm without
ownership of the corresponding FQDN creates the possibility of
conflict and therefore is to be discouraged.

Note that the use of an FQDN as the realm name does not imply use of
the DNS for location of the authentication server or for
authentication routing. Since to date roaming has been implemented
on a relatively small scale, existing implementations typically
handle location of authentication servers within a domain and perform
authentication routing based on local knowledge expressed in proxy
configuration files. The implementations described in [1] have not
found a need for use of DNS for location of the authentication server
within a domain, although this can be accomplished via use of the DNS
SRV record, described in [6]. Similarly, existing implementations
have not found a need for dynamic routing protocols, or propagation
of global routing information. Note also that there is no
requirement that the NAI represent a valid email address.

7. Acknowledgements

Thanks to Glen Zorn of Microsoft for many useful discussions of
this problem space.

8. Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-936-6605
EMail: bernarda@microsoft.com

Mark A. Beadles
WorldCom Advanced Networks
5000 Britton Rd.
Hilliard, OH 43026

Phone: 614-723-1941
EMail: mbeadles@wcom.net

9. Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

070網路電話的牛肉在哪?!


蔡宜秀 2008/12/09 06:00:00
歷經多年延宕,強調可與公眾電信網路(PSTN)互通的070網路電話(VoIP)終於上個月(11月)由遠傳電信率先開通。


別於Skype及IPOX 070等網路電話,由國家傳播委員會(NCC)審議通過的070網路電話除有11個號碼(指070-BCDE-FGHI)外,由於070網路電話是走國際電信聯盟(ITU)的E.164通信編碼格式,因此可與同走E.164格式的公眾電信網路(PSTN)互通,如市話等。


070網路電話之於企業,究竟有何意義?可讓企業大幅降低通訊成本,抑或是其他?答案是,若070網路電話可與企業既有的網路電話(VoIP)互通,確實有助於企業降低通話費,畢竟,企業已部署的網路電話只能撥出(Out-bound)無法撥入(In-bound),而070網路電話則無此問題。


但若070網路電話業者欲以有助降低通訊成本一點吸引企業轉使用070網路電話,有其困難性,理由是,企業除得先整合070網路電話與企業內的VoIP PBX等外,還必需進一步向員工宣導與改變其使用習慣等,在這樣的狀況下,建議取得070網路電話執照的業者在祭出各項優惠通話費率之外,如070網路電話使用者可以極低費用撥接行動電話等,亦需要提供更多元的加值服務。


加值服務最為關鍵
為何加值服務對於070網路電話業者來說,極為重要?我想,這可從以下兩個層面來看:

第一,費率競爭將日趨激烈。為吸引企業客戶青睞,遠傳在推出070網路電話之後,即祭出可整合ADSL與MVPN行動服務、免費贈送遠傳070軟體電話,以及享網路閘道器(IP Gateway)免租金、免設定及安裝費等優惠的「遠傳070企業方案」,由這,不難預測,是方通訊等070網路電話業者為弭補晚入070網路電話市場一事,即可能提供更優惠的費資方案,如可與非E.164網路電話互通等。


第二,市場趨勢使然。從美國、日本、南韓、新加坡與香港等地的070網路電話(非每個國家都是以070為網路電話號碼的前綴碼,如下述的Yahoo!BB網路電話的前綴碼即為050)推動狀況來看,加值服務已成為E.164網路電話業者擴大業務範疇的關鍵作法,如日本的第一大網路電話業者Yahoo!BB為擴大事業版圖,繼推出隨選視訊(MOD)─BBTV後,還與微軟及日本電信(Japan Telecom)合作推出整合網路電話、電子郵件(E-mail)與即時通訊(IM)的整合通訊服務(UC)。


從上述兩件事情來看,雖然台灣的070網路電話才剛起步,但如欲以其他通訊業者做出市場區隔、提升市場佔有率,如Skype等,尤其是企業市場這塊,建議070網路電話業者加緊腳步規劃出夠誘人的加值服務包。


導入070網路電話前的兩三事
心動不如馬上行動?對070網路電話業者提出的通話費率方案心動的企業在行動前,得先仔細評估以下兩件事情:


第一,企業頻寬是否足夠承載員工接撥070網路電話。由於070網路電話可以支援撥出與撥入,為避免員工以070網路電話接聽客戶來電時因網路不穩而導致斷線等窘境發生,企業資訊人員得先確認既有網際網路頻寬可以支援。


第二,070網路電話業者的服務動能。雖然企業早就開始透過部署網路電話等方式進行通話節費,但因各企業所部署的網路電話等網通架構不一,因此,無論070網路電話業者提出多優惠的通話費率與加值服務方案,若是其無法提供專屬企業的技術支援服務,那麼,企業怎確定070網路電話可與既有的網通架構無礙介接。
舉例來說,雖然有不少業者提出,070網路電話就像是1條SIP Trunk,只要企業的IP交換機(IP PBX)、VoIP Gateway可支援SIP Trunk,即可向業者申請1個070號碼,將該號碼註冊到IP PBX上,即可完成互通與轉接整合......但誰都不曉得,事情是否真如業者所言,不會有任何「萬一」發生。


第三,回撥070網路電話的資費較高。在070網路電話業者所提出的眾多資費方案中,是以網內互打免費這點最吸引人,不過,對早已部署網路電話或即時通訊(IM)軟體的企業來說,網內互打免費的吸引力略顯不足,理由是,企業不可能要求上下游合作夥伴與客戶申請、使用同一家070網路電話,對以歐美等地為主要銷售市場的企業來說,尤甚如此,再加上以市話或行動回撥070網路電話的資費較高(雖然國家通訊傳播委員會已要求中華電信調降資費),即可能導致台灣的合作夥伴或客戶拒絕回撥070網路電話,若是這樣,企業又何必申請使用070網路電話。