Jan 2, 2009

WiMAX商用服務來了! 強打影音線上互動

記者蘇湘雲/台北報導

雖然國內WiMAX最快將在明年中以後才開台,但是同樣也適用在3.5G的WiMAX商業應用服務已在12月30日正式起跑。此案負責國內外應用平台資源整合的惠普(HP)正在和北區全球一動及南區大同電信洽談合作,將此商轉應用成果以WiMAX加值服務面貌配合WiMAX開台面市。

HP、年代數位媒體和三軍總醫院30日共同對外發表行動商城「M-Life全視界生活網」以及行動遠距醫療「M-Care全民行動照護網」等兩大參與參與M-Taiwan計劃的階段成果。

HP指出,此新應用服務中如個人化網路直播、隨選影片、行動影音部落格、GPS定位、與二維條碼等也可適用在現行既有的固定網路和無線網路;在終端裝置方面,凡是支援微軟Windows作業系統的硬體設備都可支援,包括Windows Mobile高階智慧型手機和Windows電腦。

雖然這表示目前這些應用目前都可以做,而並不是WiMAX獨有創新應用,但是HP企業系統服務事業群顧問暨系統整合事業處資深協理王克恭認為,WiMAX的高速頻寬優勢可以有更順暢的網路影音傳輸效果,現在最重要的是要突顯此一優勢,希望把WiMAX應用風潮帶動起來。

對於WiMAX影音應用服務的商機,業者正在評估是否可採會員收費制,提供免費空間供用戶打造個人影音空間,開個人化電視台,或是從事廣告活動等。

此外,「M-Care全民行動照護網」的內容則是提供探病預約、病人病史資料顯示、健康檢查結果傳遞等功能。例如:透過保險公司收取保費,台商因為在中國大陸就醫花費的身體檢查金額遠高於治療費用,如果需要就診,即可遠端調閱病歷,享有此遠距醫療服務;而若經過病人同意,醫生可在畫面順暢不延遲停格的影音視訊中進行遠距指導開刀。而未來可能的商業模式則是類似讓獸醫院提供寵物出生的影像給飼主的B2B或一般的B2C個人用戶。

目前WiMAX各家業者的商用服務都已有了雛型,取得南區營運執照的遠傳電信目前籌備客運營運服務系統、數位託播系統和行動無線上網等三大項目;而大同電信則是推動VoIP行動辦公室、M-Care遠距居家照顧關懷和M-Portal城市觀光導覽。

Dec 31, 2008

Intra-Cluster Communication Signaling (ICCS)

Intra-Cluster Communication Signaling (ICCS), which provides the communications with the Cisco CallManager Service process that is at the heart of the call processing in each server or node within the cluster.

The intra-cluster traffic between the servers consists of the following:
  • Database traffic from the IBM Informix Dynamic Server (IDS) database that provides the main configuration information. The IDS database is replicated from the publisher server to all other servers in the cluster using best-effort. The IDS traffic may be re-prioritized in line with Cisco QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs). An example of this is extensive use of Extension Mobility, which relies on IDS database configuration.

  • Firewall management traffic, which is used to authenticate the subscribers to the publisher to access the publisher's database. The management traffic flows between all servers in a cluster. The management traffic may be prioritized in line with Cisco QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs).

  • ICCS real-time traffic, which consists of signaling, call admission control, and other information regarding calls as they are initiated and completed. ICCS uses a Transmission Control Protocol (TCP) connection between all servers that have the Cisco CallManager Service enabled. The connections are a full mesh between these servers. Because only eight servers may have the Cisco CallManager Service enabled in a cluster, there may be up to seven connections on each server. This traffic is priority ICCS traffic and is marked dependant on release and service parameter configuration.

  • CTI Manager real-time traffic is used for CTI devices involved in calls or for controlling or monitoring other third-party devices on the Unified CM servers. This traffic is marked as priority ICCS traffic and exists between the Unified CM server with the CTI Manager and the Unified CM server with the CTI device.

Shared Line Appearance(SLA) vs Bridged Line Appearance(BLA)

  • Shared Line Appearances:
    SLAs allow you to place a call on hold at one set and pick it up easily at another set. SLA is also known as SCA: Shared Call Appearance. You can join an existing conversation be pressing the corresponding line button. Typically the phones will have dedicated buttons with LEDs for each of the shared lines.

  • Bridged Line Appearance:
    BLA allows multiple devices to share a single directory number.

Facebook使用人數持續擴增(活躍使用者帳戶已達到1.4億個)

自從我接觸了Facebook之後,我就把Plaxo, Linkist, LinkedIn等社群網站冷落了,因為我觀察出來我的朋友對於Facebook接受程度遠大於其他社群網站,我認為其中有一個很大的原因,那就是Facebook的localize程度相當完整,完整到讓人以為Facebook是來自於local language的網站。以我周遭的朋友為例,我以往利用plaxo來維持人際關係,希望可以利用plaxo來隨時追蹤朋友的聯繫資料(與outlook 聯絡人同步),但是通常發出的邀請大約只有2/5會有回應,大約只有不到1/10的人會真的註冊到plaxo上。很多人跟我說他們看到英文信就砍了根本連內容都沒看...(沒錯,這是部份台灣人或是部份非西方語系國家的悲哀,他們拒絕接受英文相關資訊,因為有的人是看不懂有的人是懶得去翻譯)。

反觀Facebook,它不但中文化程度相當完整(唯一的缺點,雖然都是繁體中文,但是香港中文用語跟台灣中文用語有所差異…有時真的有看沒有懂,甚至不知道怎麼唸),它有著其他社群網站不同的特色,內建IM(這可以取代MSN/Yahoo Messenger)及web online game(有愈來愈多人從web online game找到朋友,而不用再去買online game軟體、買點數、安裝軟體等),讓許多人之間透過另一個朋友漸漸地認識到另外一群人或是N群人,只是因為某人在Facebook上發文或是進行其他的動作,造成了更多人的互動,這是以往IM及其他社群網站所沒有作到的(不過也有一些類似的社群網站出現,像是plurk or twitter,可惜他們不如Facebook收容這麼豐富的應用(也可以import許多其他社群資訊,甚至是提供無限量的照片上傳空間,因此Facebook社群會造成一種吸引力,讓你用了Facebook 之後就離不開它)。

不過Facebook也有缺點,那就是主頁介面過於複雜不容易上手,尤其是對於年紀稍長的35歲以上的網路使用者,很容易因為不知該如何使用Facebook或是來自太多方面的訊息flooding而放棄Facebook。但是相對地對於出生於網際網路世代的年輕人來說,Facebook是一個很方便的工具,隨時可以接收到各方的訊息,因為他們自小就已習慣數位訊息接收,所以相對地很容易接受新科技玩意,這也是Facebook上的年紀層遠低於LinkedIn平均年齡的原因。

=================================================================

ZDNet新聞專區:Caroline McCarthy
2008/12/19 14:07:02 

社群網站Facebook仍像野火燎原般快速擴張,據稱活躍使用者帳戶已達到1.4億個。

「Inside Facebook」部落客Justin Smith指出,拿來跟Facebook會員數達到1.3億人的日期相比,可估算出Facebook的使用者人數必定以每天增加六、七十萬人的速度持續遞增。

今年稍早,Facebook估計該公司的網路平均每天增加25萬名使用者。 

統計公司如Nielsen、ComScore和Compete.com等,都發現Facebook的美國使用者人數大概介於4,700萬與5,000萬之間--仍比MySpace的6,000多萬美國訪客來得少。不過,現在 Facebook的成長大致來自美國境外,國際使用者人數增加才是推升Facebook會員數目扶搖直上的主力。

但Facebook的營收能不能跟上這麼高速的成長?

特別是在海外,伺服器效能所費不貲。Facebook已募集可觀的創業資本,據說還在募資中,自稱財務狀況良好。然而,這令人質疑,Facebook擴張的速度是不是超出自己的意料之外。
(唐慧文/譯)

Wireless AP SSID Cloaking

Remember in Star Trek when the Enterprise was "cloaked" but somehow the Klingons found the ship anyway? Well there is a way to "cloak" your wireless network.

Your SOHO wireless device should have a setting called "Closed Network" or "Broadcast SSID". By either enabling a closed network or disabling the broadcast SSID feature you can hide or cloak your network. The SSID (network name) is transmitted in the air by your device in a broadcast called a "Beacon". Also, many wireless cards client utilities transmit empty "Probe Requests" looking for your device.

There is a very popular and freely available software program called Network Stumbler that is used by individuals to discover wireless networks. Network Stumbler also sends out blank Probe Requests looking for wireless access points.

When you implement a closed network, the SSID is no longer in the BEACON and your wireless gateway will not respond to blank Probe Requests. Effectively, your wireless network is temporarily invisible.

It should be noted that more professional tools can still discover your network because there are other transmissions from your home device that will eventually expose your SSID.

Cloaking is a great way to hide your network, but any experienced hacker will still find the SSID.

IEEE 802.11b 封包的種類

1. Beacon 封包
一般的無線 AP, 都會不斷的傳輸 Beacon 封包, Beacon 封包內會包含
SSID 訊息, 支援的傳輸速率, 此無線 AP 的 MAC 位址.
一般的 Beacon 封包速率是在 6~10 Beacon packets/sec.

為了安全性, 現在無線 AP 也提供了不包含 SSID 值的 Beacon 功能,
這種 SSID cloaking 的立意在於: 用戶端除非事先知道所使用 SSID,
否則無法使用這個無線 AP. 但是聰明的讀者一定想到了, 等到有用戶
要連接時, 就算有 WEP, 還是可以聽到所使用的 SSID :)
(ref: dedicated sniffing)

*另外也可以利用強波干擾 802.11b 的 2.4GHz 頻率(請參考 FCC
規範),當干擾強到無線 AP 或無線網卡需要重新 re-join, 此時就
可以主動聽到 SSID;這種方法造成的斷線情形,對用戶而言也可當
作是可能被探測的警訊 :)


2. Probe response 封包
當用戶端想要連上網路時,他會依據收到的 Beacon 封包,送出 probe
response 封包,其中會包含: 所要加入網域的 SSID、所使用的傳輸
速率。

3. Data 封包
通常是封裝在 802.11b frames 中的 TCP/IP 封包

4. Ad hoc 封包
和 Data 封包相同, 但屬於網卡對網卡傳輸不需繞經無線 AP.

BSSID: mac address of the BSS
SSID: 辨示該 BSS 的 32 bytes 字串
DATA RATE: 包括 1Mbps 2Mbps 5.5Mbps 11Mbps
HR/DSSS: High Rate Direct Sequence Spread Spectrum

Dec 30, 2008

威邁思延攬周勝鄰 明年第二季開台

威邁思延攬周勝鄰 明年第二季開台

WiMAX北區業者威邁思,延攬前工研院資通所副所長周勝鄰為技術長,瞄準明年第一季要完成200個基地台的建設,以期在明年第二季開台,目前測試中的USB有友訊、華碩、三星與中興,同時明基與技嘉的手持式裝置(MID)也列為下波測試的產品。

威邁思的技術長彭集友離職後,初期網路建置是重頭戲,因此公司延攬周勝鄰為技術長,周勝鄰擅長於寬頻網路與網路電話,之前曾在東元集團擔任顧問,頗獲肯定,此次則是投入WiMAX 的領域,為威邁思籌建網路,威邁思的股東有東元、東訊、威寶與英特爾。

威邁思已經決定設備採購商,將由韓國三星與以色列奧維通兩家業者,拿下基地台等設備採購商機,三星已經完成簽約,奧維通還在洽談細節,三星之前已經為威寶建設基地台,已有合作基礎,奧維通則是之前曾下單東訊,更加深合作關係。這兩家業者都有和東訊簽訂WiMAX無線基地台製造合作意向書。三星也是Sprint-Nextel、日本UQ等業者的設備商。

威邁思初期將建設台北市200座基地台,由於北市既有3.5G網路覆蓋率完整,也促使威邁思必須強化網路建設,才能一別苗頭。

在終端設備上,目前測試中的USB有友訊、華碩、大陸的中興與三星,下一波也將導入MID產品,例如明基與技嘉。

目前取得WiMAX執照的業者紛紛延後開台時程,遠傳開台日期延後到明年底前,威邁思計畫在明年第二季,威達延到明年6月開台,全球一動在明年第三季開台,業者評估,WiMAX終端設備至今互通性仍有問題,價錢又太貴,再加上政府對於通訊監察的規範遲未出爐,讓WiMAX開台時程受到阻礙。

Dec 29, 2008

為什麼Traceroute時沒有發生packet lost但是總會出現 * 呢?

說實話,關於這個問題我自己也常常覺得很納悶,剛好最近PacketLife.net(我真的愈來愈喜歡這個網站了,只要上過我課程的學生應該不陌生,給各位同學的cheatsheet都是從PacketLife上抓下來的)把這個issue提出來並且作了一份packet analyze報告,請參考!

Traceroute timeouts

Posted by stretch in Networking on Monday, 29 Dec 2008 at 2:26 a.m. GMT

If you spend a lot of time performing traceroutes to Cisco routers you've probably noticed that they usually end like this:


R1# traceroute 10.0.34.4
Type escape sequence to abort.
Tracing the route to 10.0.34.4
1 10.0.12.2 16 msec 8 msec 12 msec
2 10.0.23.3 16 msec 16 msec 16 msec
3 10.0.34.4 16 msec * 20 msec

Notice that the second reply from the last hop has timed out. This is easily repeated with subsequent traceroutes, and it is always the second attempt which times out. Strange, eh?

The reason for this is IOS' default ICMP rate limiting. Back in May I wrote an article explaining the common "U.U.U" response that results from pinging an unreachable destination, and the same logic is at work here. Inspecting the default ICMP rate limits reveals that ICMP unreachable messages are only sent every 500ms:


R4# show ip icmp rate-limit
DF bit unreachables All other nreachables
Interval (millisecond) 500 500

Interface # DF bit unreachables # All other unreachables
--------- --------------------- ------------------------
FastEthernet0/1 0 3

Greatest number of unreachables on FastEthernet0/1

This rate limiting configuration effectively ignores every other traceroute packet (see the timeline illustration in the previous article). Makes sense, but why do all the requests to routers prior to the last hop receive replies without this problem?

Those replies are of a different ICMP type, namely the "TTL exceeded" type. Remember that traceroute works by sequentially incrementing the TTL of UDP (or ICMP on Windows) packets destined for a host and recording the replies received from intermediate routers. All hops except the last one will (or should) return a "TTL exceeded in transit" message, whereas the last hop should return a "destination unreachable/port unreachable" message indicating that it cannot handle the received traffic (UDP traceroute packets are typically addressed to a pseudorandom high port on which the end host is not likely to be listening).

Traceroute flow

The packet capture attached at the end of this article includes the traffic from the traceroute demonstrated above.

Interestingly, we can remove the ICMP rate limit with no ip icmp rate-limit:


R4(config)# no ip icmp rate-limit unreachable
R4(config)# ^Z
R4# show ip icmp rate-limit

Now our traceroute from R1 completes fully:
R1# traceroute 10.0.34.4
Type escape sequence to abort.
Tracing the route to 10.0.34.4
1 10.0.12.2 32 msec 12 msec 20 msec
2 10.0.23.3 60 msec 56 msec 24 msec
3 10.0.34.4 32 msec 44 msec 36 msec

However, removing the ICMP rate-limit may open an avenue for denial of service attacks on your routers, so in practice you probably want to leave it applied.

安全傳輸協定(Security Transport Protocols, SRTP)

安全傳輸協定(Security Transport Protocols)除了可應用在金融交易資料外,亦可應用於網路瀏覽所涉及之相關機密資料。在數位多媒體內容保護技術中,目前有數種安全協定可供使用在資料流(Data Traffic)的保護上,如作用在網路層(Network Level)的IP保護安全協議標準(Internet Protocol Security, IPSec);作用在傳送層(Transport Level)的安全傳輸層(Transport Layer Security)安全協定(Security Protocols)。但上述安全協定不一定適用各種型態的資料流。為了滿足異質環境(Heterogeneous Environment)及即時應用(Real-time Applications)上之需求,應用層(Application Level)上的安全協定運作更是當務之急。

數位多媒體在傳送的需求大致如上所述,但能應用一般資料安全傳送協定的媒體種類有限,如靜態圖檔或一般媒體檔案利用HTTP方式下載。但是對於如使用RTSP傳送協定的即時串流媒體而言,這些現有的資料安全傳送協定不見得適用。因為即時串流媒體對頻寬(Bandwidth)限制、傳送錯誤敏感性(Transmission-error Sensitivity)、延遲(Delay)與行動終端的運算複雜度等問題,皆異常敏感且容忍性低。也是即時串流媒體在是目前異質環境與即時應用上面對的四個主要問題。

目前關於上述問題的相關IP解決方案,均非針對異質性環境的需求所設計,尤其較少關注到頻寬的消耗與訊號傳遞的來回次數問題。這問題在無線3G網路上會更突顯,因為無線網路的資源有限且頻寬稀有,若使用目前標準IP上的安全協定,可能增加系統營運成本外,還可能無法達到預期的效果。換句話說,以標準IP傳送方式來傳送語音資料(Audio data),在一個典型的即時傳輸協定(Realtime Transport Protocol, RTP)語音費用負載約為33位元組的情況下,在頻寬使用上是缺乏效率的。

SRTP高彈性擴充解決適用性問題

SRTP的設計架構保留彈性的擴充功能以延長協定可使用的壽命,因此SRTP一開始設計時並非定位為單一產品,其乃以基礎建設骨架(Framework)的方式進行設計。所以在SRTP架構中可以獨立分開實作編碼部分與整合性保護部分,因為在SRTP中並未編碼保護RTP,因此對RTP標頭進行壓縮運作以保留頻寬。另外,在SRTP預定義轉換(Predefined Transforms)中亦提供加密套件,以因應不同異質性環境或即時應用的需求,藉此改善加密套件之間的互通(Interoperability)。

SRTP定義兩種編碼轉換(Encryption Transforms),一是H. Lipmaa、D. Wagner與P. Rogaway所提議的Counter模式;另一為f8模式。這兩種編碼轉換是基於AES的串流加密器(Stream Ciphers)之區塊式編碼器,避免位元錯誤而波及其他傳送位元。而其預定義的驗證轉換(Authentication Transforms)為HMAC/SHA-1,這兩種驗證方法是經過多重考驗的成熟雜湊架構(Hash-based)函數。

但對於群播(Multicast)用戶而言,其屬性與僅傳送單一用戶者不同。若在群播裡提供原始資料驗證,將花費高成本,目前此方面有效的驗證方法尚未健全。所以SRTP在群組(Groups)應用上,並未提供原始資料驗證的功能選項。群播問題屬較複雜的管理環節,若資料串流又加上編碼或驗證等工作,無疑加重既有系統的負擔。因為每個安全協定都需要「密鑰管理協定(Key Management Protocol, KMP)」以確保未來密鑰交換的安全及規範成員間的安全參數(Security Parameters),不同的媒體遞送方式,其使用的KMP技術可能存在彼此適用問題。

在群播的管理安全問題上,核心環繞在群組鑰匙管理的機制面。造成該問題複雜化的因素,在於群組內的會員變動率大且架構傾向浮動所致。因此群播(Multicast)中的群組鑰匙管理問題,是目前DRM系統或是媒體本身編碼、驗證機制所共同面對的難題。

在一群播基礎架構裡,每一個遞送資料的通訊區段(Session)安全主要由兩個元件所控制,一個是鑰匙伺服器(Key Server, KS),另一為群組控制者(Group Controller, GC)」。KS負責維護、散播群組所需要編碼/驗證的密鑰;GC則負責群播會員的驗證、認證與存取控制。KS與GC的功能可實作在同一台實體裝置,亦可分開實作。

在群播腳本裡,為確保群播通訊區段的機密性,傳送者(Source)會與合法會員分享一對稱式密鑰(Symmetric Key),此對稱式加密系統的密鑰便是流量編碼鑰匙(Traffic Encryption Key, TEK),此鑰匙可解開編碼後的群播流量資訊。因此,傳送者會先用TEK將訊息編碼後才進行機密傳送。

因群播會員具有較大流動性,為確保離開的會員不得再觀看機密訊息,KS會重新產生一個新的TEK並遞送給現存會員,往後的機密訊息就以新TEK進行編碼與解碼,此過程即所謂「重發鑰匙(Re-keying)」過程。整個群組密鑰的重新更新與編碼管理過程,稱為「群組密鑰管理(Group Key Management, GKM)」。群組密鑰的管理會隨著會員的增加而趨於複雜,換句話說,會員越大,群組的密鑰更新成本隨之增高。

一個有效的群組密鑰管理需求可分成四大主要類別,分別是鑰匙伺服器需求、安全需求、服務品質(Quality of Service, QoS)需求及群組成員需求。每一個類別下另各有其次要需求,依據Y. Challal及H. Seba看法,這些次要需求可歸納如表1。

對群組鑰匙管理協定(Group Key Management Protocol, GKMP)的描述,在目前常用的集中化、去集中化與分散式三種不同的群組鑰匙管理技術中,哪一個群組鑰匙管理協定才適用?事實上並無一定標準,不過可參考Y. Challal及H. Seba所提的四項需求中,何者能滿足最多次需求者即是。
為使SRTP更加完備,其KMP須滿足SRTP所支援的各種應用需求。但在許多即時應用(Real-time Applications)裡面易存在延遲問題,尤其在無線應用環境裡面,因其環境運算資源(Computational Resources)有限,一旦這些安全協定技術被應用進去,不管協定多有效率,都將會額外耗損端點運算資源或網路頻寬等系統資源,因此若要在無線應用環境裡面運用,其程式大小與運算成本須獲得適當控制。

在系統與端點(End Points)的密鑰常見的協調方式有兩種,一種是以用戶端對用戶端(P2P)的協調方式;另一種是利用KMP方式來發送密鑰及安全參數。前者提供點對點式的便利,但其缺點在設定與運作上會較複雜;後者提供較一致的整體安全控制,不過缺點則是整個系統的運作成本會比前者高。適用哪一種密鑰協調方式,端視應用種類、目的與商業價值而定。因此一個安全協定,意味著高運算資源的消耗,在發展SRTP時,高通透量(High Throughput)與異質環境的滿足是其主要設計核心原則。不過在設計STP的同時,也要設計安全實時控制協定(Secure Real-Time Control Protocol, SRTCP),RTCP為RTP的控制協定,在設計SRTCP時其所遵循的標準亦比照SRTP的設計標準進行。

基於上述限制,難以將已發展成熟的一般IP安全協定直接套用在無線終端設備,如要在這些行動裝置上面執行公鑰編碼鑰匙(Public Key)運算,將犧牲龐大運算成本,因此在多數情況下對加密系統的選用上,「對稱式編碼(Symmetric Encryption)」方法仍是首選。

串流加密器簡化錯誤位元處理

欲將加密系統用在無線環境,另需注意位元錯誤發生的問題。在某些應用型態,如音訊裡面,錯誤可合理被處理。但若該訊息是被驗證的,即使是一個位元的錯誤也會導致整個封包的丟棄,這對接受端來說,將導致整體感官品質(Perceived Quality)下降。不過即使訊息未經驗證要求,在密碼系統層級上,尤其在加密層面(Decryption Phase)也可能出現位元錯誤問題。因此,接受端的傳播錯誤控制(Propagate Errors Control)是一關鍵的控制技術。

至於一個訊息的錯誤傳播與錯誤位元的發生位置,須看當時所選擇的解碼器種類而定,基於上述理由,串流加密器(Stream Cipher)或許是即時串流應用中較佳選擇,因為這種串流加密器不會像DES和AES區塊加密器一樣,以整批的方式處理傳播錯誤的問題。一個區塊式加密系統與串流式加密系統的運作示意圖如圖2。

SRTP設計優先考量頻寬

因為封包加密/驗證的需求,往往會無形之中增加頻寬的消耗,因此在SRTP的設計理念裡面,頻寬的保留(Bandwidth Preservation)是主要的核心任務之。而頻寬保留的常見作法,通常是使用「封包序號(Package Sequence Number, Packet SN)」來同步化安全演算法(Security Algorithms)。RTP的序號通常位於封包的標頭位置,當系統陸續送出封包時,序號會以單調遞增的方式,如同排隊抽號碼牌的情形一般。陸續增加號碼。SRTP使用的是RTP原有的序號,因此它在同步化(Synchronization)上面並不需要其他額外的欄位。不過遺憾的是RTP序號只有16位元大小,因此當此大小容量被填滿時,RTP序號就會被迫重新計算,如此一來,SRTP所使用的密鑰也要重新加以改變。對應重新計數的SN之密鑰,或許就須要重新執行一次密鑰管理協定(Key Management Protocol, KMP),這過程就是所謂的「重發行密鑰(Re-keying)」。

在SRTP的基本架構內,一般情況下並不會於RTP封包內加入任何額外的位元,不過在「重發行密鑰」時,除了整合保護所需要的驗證標籤(Authentication Tag)外,還需要一個「主密鑰識別器(Master Key Identifier, MKI)」加入RTP封包,不過此欄位是一選擇性的可變長度欄位(Variable Length Field)。為了頻寬保留,封包的驗證標籤會被切為四位元組大,此作法雖會犧牲一些安全性,但在即時應用上可被接受。

SRTP與實際的密鑰管理協定(KMP)兩者互為獨立運作, SRTP為提供足夠安全功能,其所需要的密鑰數目須依據其所提供的安全功能數目而定。另外,SRTP亦使用主要密鑰(Master Key)與通訊區段密鑰(Session Key)的觀念,由密鑰管理系統負責交換主要密鑰,但通訊區段密鑰則衍生自主要密鑰,亦為實際用於編碼或驗證的密鑰。

為保持SRTP的安全強度,SRTP提供「密鑰更新(Key Refresh)」功能。若此選項一旦啟動,會依據主要密鑰定期產生新的通訊區段密鑰,因為新的通訊區段密鑰乃依據原有主要密鑰而產生,所以啟動此功能並不造成密鑰管理系統的負擔增加。所以一個主要密鑰可能為多個SRTP串流所共享,其並儲存在多媒體通訊區段內以降低密鑰交換數目。

為達共享的目的,應注意避免重複使用密鑰串流。避免重複使用密鑰串流,SRTP提供不同且唯一的起始向量(Initialization Vector, IV)到每一個串流加密器,若無法提供不同且唯一的起始向量至不同加密器,就應使用不同的主要密鑰。另外一種關於有限RTP序號的解決方法,是直接利用RTP的序號來重發行密鑰,但這種方法欠缺前者具備的彈性。此外,執行重發行密鑰過程時會大量消耗系統資源,因此避免一個長時間的通訊區段不斷發出重發行密鑰的要求,所以SRTP在局部使用了一個三十二位元的紀錄器,稱為「反覆計數器(Rollover Counter)」,用以加大原本RTP序號使用的序號數量空間。

商業周刊:傳統即時通訊軟件的沒落

《商業周刊》網站日前發表分析文章稱,傳統即時通訊(以下簡稱『IM』)正在走向沒落。曾經在電腦桌面上風光無限的IM視窗正在讓位於一種使用更方便的即時聊天工具,互聯網公司希望借這種工具提高網站的粘性。

  微軟11月13日宣布將更緊密地集成IM、Windows Live電子郵件和社交網站,就是這一趨勢的一個例証。在使用Hotmail時,用戶無需打開一個新視窗,下載客戶端軟件,就可以與其他用戶即時聊天了。

  微軟是根據消費者需求的變化採取這一舉措的:用戶對獨立IM工具的興趣在日益減退,希望喜歡的站點集成有聊天功能。與電子郵件、遊戲和其他類型軟件一樣,IM也在向Web靠攏,用戶可以在任何電腦上使用網頁IM,而又不會占用硬盤空間。

  嵌入式IM

  據美國市場研究公司comScore稱,截至2008年9月份的一年中,AOL旗下AIM軟件獨立訪問用戶數量下滑了4%。同期內AOL旗下另外一款IM軟件ICQ和騰訊QQ的用戶使用時間也出現了滑坡。

  互聯網用戶對傳統IM聊天視窗已經失去了興趣,紛紛『湧向』Facebook和Gmail等站點,這些站點的一個共同特徵是都集成有IM功能。對於互聯網公司而言,嵌入式IM增加了用戶訪問站點的時間,對廣告客戶也更有吸引力。

  AOL People Networks高級副總裁大衛‧劉(David Liu)表示,大多數20歲以上網民最早使用的是AOL的IM軟件,但其他IM軟件削弱了AOL旗下IM軟件的競爭力,『AIM的用戶數量在下滑,因此我們需要增強AIM的社交特性。』AOL的舉措之一是將AIM與該公司旗下社交網站Bebo結合起來。AOL計劃2009年初在Bebo上發布一款IM面板,賣點就是AIM的3000萬用戶可以方便地訪問好友的Bebo網頁。

  Facebook聊天工具條

  Facebook也考慮到了IM。Facebook今年早些時候發布了一款工具條,用戶在瀏覽Facebook時可與其他用戶進行一對一的聊天。據Facebook產品經理彼得‧鄧(Peter Deng)表示,約7500萬人試用了這款工具條,相當於逾60%的Facebook活躍用戶。鄧說,『我們認為讓用戶進行一對一的聊天是非常必要的,這為朋友之間保持聯繫提供了一種渠道。』

  一些小型社交網站也意識到了聊天的吸引力。電影粉絲社交網站Flixster CEO喬‧格林斯坦(Joe Greenstein)今年早些時候指出,用戶更喜歡彼此之間uH即時方式討論和推薦電影,而不是先發帖子然後再等待其他用戶跟帖。Flixster 10月份發布了一款網頁IM工具條,用戶可以查看哪些好友在線,並與他們進行一對一的聊天。

  嵌入式廣告

  Flixster的工具條是由硅谷創業公司Meebo開發的。Meebo計劃未來6個月內為19個其他網站開發類似的網頁IM工具條。Meebo CEO塞斯‧斯特恩伯格(Seth Sternberg)表示,網頁IM提高了網站粘性,『如果用戶原來在一個網站上停留3分鐘,我們就能夠讓用戶停留6分鐘。』

  Flixster和Meebo的其他合作伙伴最終將在IM工具條,甚至用戶聊天過程中嵌入廣告。斯特恩伯格說,這將是在IM中發布廣告的一個新機遇。例如,用戶可以在聊天視窗中觀看電影預告片的同時與好友討論正在觀看的預告片。

  交互式營銷機構Deep Focus媒體副總裁埃里克‧唐肯米勒(Eric Druckenmiller)表示,互聯網公司需要給IM注入新的活力了。他說,與IM相比,許多其他網路廣告發布渠道規模就相形見絀了,但自1990年代末以來,IM沒有受到足夠的重視。Deep Focus在Meebo的IM站點上進行的一項試驗表明,IM的廣告潛力很大。

  谷歌和雅虎在網頁IM領域已經走在了微軟前邊。在過去的兩年來,為了將自己打造為一站式網路通訊站點,谷歌和雅虎在網站上集成了IM工具,目的是提高內容和服務的粘性。

  雅虎在IM廣告領域的大膽探索

  谷歌在Google Talk桌面軟件、Gmail Chat、Google Docs和widget中提供了聊天功能。Google Talk產品經理塞斯‧德姆賽(Seth Demsey)說,『我們希望用戶能夠在需要的地方與其他用戶聊天。』

  雅虎的獨立IM軟件擁有1.16億名用戶,遠遠超過了Google Talk的600萬。雅虎在通過IM發布廣告方面進行了大膽的探索,例如展示廣告、關聯廣告,甚至在IM視窗中集成了一款迷你可口可樂足球遊戲。

  有業界人士預測,IM用戶越來越希望拆除各種平台間的圍牆,在一個地方看到自己的所有好友,這個地方可能是工具條、電子郵件服務或者是桌面軟件。(清泉)