IPTV平臺間內(nèi)容傳輸故障分析與處理

馬正先

（廣東南方廣播影視傳媒集團 技術(shù)部，廣東 廣州 510012）

我國IPTV集成播控平臺采用中央和省兩級架構(gòu)，中央級總平臺負責全國性IPTV內(nèi)容平臺的接入，省級分平臺負責本地IPTV內(nèi)容平臺的接入，總平臺將全國性IPTV內(nèi)容傳輸?shù)椒制脚_，由分平臺發(fā)布到電信IPTV傳輸網(wǎng)絡(luò)。節(jié)目內(nèi)容是IPTV各種業(yè)務(wù)形態(tài)的基礎(chǔ)，每天都有大量的節(jié)目內(nèi)容通過接口按照統(tǒng)一的技術(shù)規(guī)范由總平臺傳輸?shù)椒制脚_。在分平臺建設(shè)和運行過程中，往往由于各種原因?qū)е聝?nèi)容傳輸失敗，影響總平臺內(nèi)容正常發(fā)布。因此，作為IPTV集成播控平臺技術(shù)系統(tǒng)開發(fā)和維護人員，有必要了解總分平臺間內(nèi)容傳輸機理，通過對故障現(xiàn)象的分析研究，及時準確地判斷處理內(nèi)容傳輸問題。

1 內(nèi)容下發(fā)機制

IPTV總平臺與分平臺之間、分平臺與電信IPTV平臺之間內(nèi)容傳輸均遵循統(tǒng)一的內(nèi)容發(fā)布接口規(guī)范，接口采用SOAP協(xié)議+XML指令文件的方式[1]。簡單對象訪問協(xié)議（Simple Object Access Protocol，SOAP）是以廣泛使用的傳輸層和網(wǎng)絡(luò)層標準（通常選用HTTP）作為底層通信協(xié)議，以XML作為數(shù)據(jù)傳送格式，在分布式環(huán)境下實現(xiàn)信息交換和遠程過程調(diào)用的協(xié)議。SOAP提供了一種標準的方法，使得運行在不同的操作系統(tǒng)并使用不同技術(shù)和編程語言的應(yīng)用程序，通過通用的底層通信協(xié)議互相進行通信[2]。IPTV平臺間內(nèi)容傳輸接口規(guī)范將交互信令和XML指令文件（工單）分兩次進行傳遞，SOAP只作為信令的交互，僅用來表達命令的請求和響應(yīng)，告訴對方有一個XML指令文件需要進行傳遞，具體的指令和參數(shù)是由獨立的XML文件來描述，XML文件通過FTP進行異步傳遞。這樣做主要有兩方面的考慮：一是提高可靠性，SOAP交互只是包含了通信雙方的收發(fā)地址、XML文件的URL地址等信息，屬于短消息，一次交互就能完成，可最大限度減少信令傳遞出錯率，如果將SOAP交互信息和XML文件一起傳送，由于XML文件往往比較大，很難通過一次交互來完成，傳遞出錯的幾率將隨之增大。二是提高效率，對于簡短的SOAP消息，發(fā)送方能很快收到接收方接收信令狀況的反饋信息，發(fā)送方一旦確認接收方收到信令，即可開始下一個操作，無需等待接收方將XML文件里的指令全部執(zhí)行完，這樣可大大提高系統(tǒng)的工作效率。內(nèi)容下發(fā)接口流程如圖1所示。

1）總平臺向分平臺發(fā)送執(zhí)行指令請求消息，消息中包含XML指令文件的URL，分平臺收到SOAP消息后返回執(zhí)行指令響應(yīng)；

圖1 內(nèi)容下發(fā)接口流程圖

2）分平臺根據(jù)SOAP消息中指令文件的URL，通過FTP協(xié)議下載XML指令文件，解析后執(zhí)行指令，執(zhí)行指令過程中可能還涉及到從總平臺下載圖片和媒體文件；

3）分平臺執(zhí)行指令后，向總平臺發(fā)送結(jié)果通知請求，總平臺收到結(jié)果通知請求后返回結(jié)果通知響應(yīng)。

2 XML指令文件簡介

可擴展標記語言（Extensible Markup Language，XML）是一種元標記語言，用戶可以根據(jù)自己的需要定義任何有意義的標記，這些標記將文檔分成許多部件，用以描述結(jié)構(gòu)化的數(shù)據(jù)，XML的主要設(shè)計目標就是用來存儲和傳輸這些結(jié)構(gòu)化的數(shù)據(jù)。由于XML采用簡單易懂的純文本的數(shù)據(jù)描述，使得它很容易實現(xiàn)通信并支持廣泛、多樣化的應(yīng)用程序，當跨越不同的操作系統(tǒng)和

應(yīng)用程序時不存在兼容性問題。另一方面，業(yè)務(wù)的不斷發(fā)展帶來新的數(shù)據(jù)傳遞需求，由于XML可以自定義標記和文檔結(jié)構(gòu)，用戶可以根據(jù)需要靈活擴展接口定義，因此XML具有很好的擴展性。

圖2 XML指令文件示例（截圖）

用XML來表示大量的結(jié)構(gòu)化或半結(jié)構(gòu)化信息是行之有效的方法[3]，XML作為Web的通用語言，不僅支持一般的文本交流，也可以攜帶各種復(fù)雜的數(shù)據(jù)和文件[4]。IPTV平臺間內(nèi)容傳輸所涉及的參數(shù)和指令都是由XML文件來描述的。ADI/Objects/Mappings是XML指令文件的通用基礎(chǔ)框架，基于該通用框架定義不同的Ob?ject.ElementType和不同的Property.Name，滿足對不同對象的定義需求。圖2是一個XML指令文件示例，其中ADI是根元素，Objects及其子元素Object表示操作對象，Mappings及其子元素Mapping表示映射對象。子元素Object包含ElementType，ID，Action，Code等4個屬性，ElementType屬性定義了對象的類型，可以是Pro?gram（點播節(jié)目）、Movie（媒體內(nèi)容）、Picture（圖片）、Se?ries（連續(xù)劇）、Category（欄目）等。ElementType與ID兩者結(jié)合在接口中唯一定位一個對象實例，它們是一個接口中針對對象進行任何操作的唯一索引。Action屬性定義了對象的3種操作類型：REGIST（新增）、UP?DATE（修改）、DELETE（刪除）。Code屬性在跨系統(tǒng)時作為全局唯一標識。子元素Mapping包含Action、Ele?mentType、ElementID、ElementCode、ParentType、Paren?tID、ParentCode等屬性，其中Action屬性定義關(guān)系映射的3種操作類型，后面6個屬性分別表示關(guān)系映射時元素和父元素的對象類型、ID和Code。Object和Mapping可包含子元素Property，通過Property.Name定義字段來描述各種對象及映射關(guān)系的詳細信息。

以圖2為例，①表示新增一個ID為101的欄目，以及欄目的名稱等。②表示新增一部ID為201的連續(xù)劇，以及連續(xù)劇的名稱、簡介、集數(shù)等信息，狀態(tài)標志Status為1，表示生效，該連續(xù)劇為上架。③表示新增一張ID為202的圖片，以及圖片文件的URL，分平臺將根據(jù)該URL獲取圖片文件。④表示新增一個ID為301的節(jié)目（劇集），以及節(jié)目的名稱、簡介等信息。⑤表示新增一個ID為401的媒體內(nèi)容，以及該媒體內(nèi)容文件的名稱、URL等信息，類型標志Type為1，表示該媒體內(nèi)容為正片（2為預(yù)覽片）。⑥，⑦，⑧，⑨為映射關(guān)系，分別表示將上述連續(xù)劇與圖片、媒體內(nèi)容與節(jié)目、節(jié)目與連續(xù)劇、連續(xù)劇與欄目進行關(guān)系映射（綁定），⑥中Type為1，表示映射時的圖片類型為海報，⑧中序號Se?quence為16表示節(jié)目在連續(xù)劇中排序16。

3 故障分析與處理

了解IPTV平臺間內(nèi)容傳輸機制和XML指令文件細節(jié)可幫助平臺系統(tǒng)開發(fā)和維護人員準確定位并解決故障。這里列舉在分平臺系統(tǒng)開發(fā)過程中遇到的幾個問題，對照前面所述的內(nèi)容下發(fā)機理，詳細介紹故障的定位分析以及解決辦法。

3.1 海報圖片傳輸故障分析與處理

總平臺下發(fā)的海報圖片有的在機頂盒上顯示不完全。按照內(nèi)容下發(fā)機理，ElementType=”Picture”時，分平臺會根據(jù)FileURL字段定義的地址去總平臺下載圖片，存放在分平臺內(nèi)容管理系統(tǒng)（CMS）中，并將海報圖片與節(jié)目（或連續(xù)劇）進行關(guān)系映射。查看XML指令文件，圖片文件的URL和映射關(guān)系全部正確，如圖2中③，⑥所示。根據(jù)以往經(jīng)驗，圖片顯示不全很可能是分平臺沒有完全下載圖片文件，導(dǎo)致這一問題的原因往往是下載圖片文件時，網(wǎng)絡(luò)出現(xiàn)故障，或者是總平臺還沒有全部上傳完圖片文件時，分平臺已經(jīng)開始下載圖片文件。

為此，本文調(diào)整了圖片文件的獲取流程，在原來的圖片下載流程中增加文件大小比對環(huán)節(jié)，如圖3所示。在圖片文件下載到本地后，將其與總平臺FTP服務(wù)器上源圖片文件進行大小的比對，若一致，說明已正確地下載了圖片文件，否則重新下載該圖片文件。

3.2 連續(xù)劇傳輸失敗故障分析與處理

連續(xù)劇內(nèi)容傳輸涉及連續(xù)劇下的劇集，通?？偲脚_先新增一個連續(xù)?。⊿eries），然后下發(fā)劇集（Pro?gram），并將劇集與連續(xù)劇進行映射，最后再將連續(xù)劇映射到相應(yīng)的欄目（Category）下，完成連續(xù)劇及其劇集的下發(fā)過程。實際應(yīng)用中出現(xiàn)部分劇集已經(jīng)下發(fā)到分平臺，但這些劇集在分平臺CMS處于下架狀態(tài)不能發(fā)布到電信平臺問題，進一步檢查發(fā)現(xiàn)這些未能發(fā)布的劇集都是在總平臺下發(fā)連續(xù)劇與欄目的映射關(guān)系之后下發(fā)的劇集。

圖3 海報圖片文件下發(fā)流程圖

調(diào)取總平臺XML指令文件顯示，這些新增劇集狀態(tài)標志Status字段為1，如圖2中④所示，表示該劇集應(yīng)為上架，說明這些劇集的發(fā)布狀態(tài)是正常的，因此很可能是分平臺處理問題。仔細分析分平臺的處理流程，發(fā)現(xiàn)分平臺對于所有下發(fā)的新增內(nèi)容，都將其掛載到默認欄目下，并強制將其改為下架狀態(tài)，等到總平臺下發(fā)與欄目的映射關(guān)系指令后，才將新增內(nèi)容變成上架狀態(tài)，隨后系統(tǒng)將內(nèi)容及其與默認欄目的映射關(guān)系自動發(fā)布到電信平臺。這樣的處理流程就有可能導(dǎo)致前面出現(xiàn)的問題，即總平臺在下發(fā)與欄目的映射關(guān)系之前下發(fā)的劇集是能正常發(fā)布，之后的劇集則不能正常發(fā)布。這是因為分平臺收到映射關(guān)系指令后，把連續(xù)劇和先期下發(fā)的劇集變成上架狀態(tài)發(fā)布到電信，后面下發(fā)的劇集由于沒有再收到連續(xù)劇與欄目的映射指令，一直處于下架狀態(tài)，使得后期下發(fā)的劇集未能發(fā)布到電信平臺。

為此，重新制定了處理流程，對于總平臺下發(fā)的內(nèi)容，分平臺CMS完全按照狀態(tài)標志Status字段設(shè)置成上架或下架，如果內(nèi)容上架，分平臺只向電信平臺發(fā)布內(nèi)容，不發(fā)映射關(guān)系，當分平臺收到總平臺下發(fā)劇集（或節(jié)目）與欄目的映射關(guān)系后才自動向電信平臺發(fā)布映射關(guān)系，電信平臺只有接收到映射關(guān)系后該劇集（或節(jié)目）才正式播出，如圖4所示。

圖4 優(yōu)化后的分平臺內(nèi)容管理系統(tǒng)（截圖）

3.3 電視時刻表信息傳輸失敗故障分析與處理

電視時刻表是指電視頻道節(jié)目與播放時間的對應(yīng)關(guān)系。分平臺試運行之初，央視一套的電視時刻表信息是由分平臺手工導(dǎo)入，并發(fā)布到電信平臺，然后央視一套的電視時刻表信息改由總平臺通過接口進行發(fā)布，此時出現(xiàn)了總平臺下發(fā)央視一套的電視時刻表信息失敗問題。調(diào)取總平臺下發(fā)的XML指令文件，如圖5所示，其中ElementType=”Schedule”表示電視時刻表信息，根據(jù)接口規(guī)范，分平臺應(yīng)在數(shù)據(jù)庫中查找Chan?nelCode（頻道代碼），并將電視時刻表信息錄入到對應(yīng)的頻道中。經(jīng)過分析，之所以出現(xiàn)上述問題是因為央視一套電視頻道是在分平臺手工創(chuàng)建的，其在分平臺數(shù)據(jù)庫中的ChannelCode與總平臺下發(fā)的XML指令文件中的ChannelCode不一致，導(dǎo)致根據(jù)XML指令文件中的ChannelCode在分平臺數(shù)據(jù)庫中找不到該頻道，從而使電視時刻表信息錄入到該頻道出現(xiàn)失敗。解決方法是分平臺在解析XML指令文件后，在數(shù)據(jù)庫中查找XML指令文件里的ChannelCode，如果數(shù)據(jù)庫中有對應(yīng)的ChannelCode，則將電視時刻表信息錄入到該頻道中，如果數(shù)據(jù)庫中沒有對應(yīng)的ChannelCode，向總平臺返回處理失敗，由總平臺重新下發(fā)電視頻道信息指令文件（ElementType=“Channel”）。

4 小結(jié)

以上是本文在分平臺建設(shè)初期發(fā)現(xiàn)的平臺間內(nèi)容傳輸故障案例及其解決方法，鑒于對故障現(xiàn)象的細致分析和問題的準確定位，內(nèi)容傳輸故障都得到及時有效的解決。分平臺正式運行后，隨著網(wǎng)絡(luò)環(huán)境、傳輸方式等各種影響內(nèi)容傳輸因素的變化，不可避免地仍會發(fā)生內(nèi)容傳輸故障。作為平臺系統(tǒng)維護人員也需要掌握平臺間內(nèi)容傳輸機理，通過對XML指令文件和內(nèi)容傳輸處理流程的分析，準確定位及時解決內(nèi)容傳輸故障。

圖5 電視時刻表信息指令文件（截圖）

：

[1]刁仁宏，方睿.利用Web Service實現(xiàn)IPTV平臺數(shù)據(jù)的交換[J].微計算機信息，2009（18）：278-279.

[2]范寶鋒，方勇，湯云革，等.基于SOAP的Web服務(wù)的互操作性問題分析[J].成都電信工程學(xué)院學(xué)報，2005，20（2）：142-146.

[3]張一鳴，安春花，王偉民.XML搜索引擎技術(shù)在臺網(wǎng)系統(tǒng)中的應(yīng)用及分析[J].電視技術(shù)，2009，33（2）：58-59.

[4]袁永躍，顧亞平，張俊.基于XMPP的數(shù)字內(nèi)容推送系統(tǒng)通信方案的研究[J].電視技術(shù)，2013，37（6）：82-84.