IPTV平臺間內容傳輸故障分析與處理

馬正先

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

我國IPTV集成播控平臺采用中央和省兩級架構，中央級總平臺負責全國性IPTV內容平臺的接入，省級分平臺負責本地IPTV內容平臺的接入，總平臺將全國性IPTV內容傳輸到分平臺，由分平臺發布到電信IPTV傳輸網絡。節目內容是IPTV各種業務形態的基礎，每天都有大量的節目內容通過接口按照統一的技術規范由總平臺傳輸到分平臺。在分平臺建設和運行過程中，往往由于各種原因導致內容傳輸失敗，影響總平臺內容正常發布。因此，作為IPTV集成播控平臺技術系統開發和維護人員，有必要了解總分平臺間內容傳輸機理，通過對故障現象的分析研究，及時準確地判斷處理內容傳輸問題。

1 內容下發機制

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

1）總平臺向分平臺發送執行指令請求消息，消息中包含XML指令文件的URL，分平臺收到SOAP消息后返回執行指令響應；

圖1 內容下發接口流程圖

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

3）分平臺執行指令后，向總平臺發送結果通知請求，總平臺收到結果通知請求后返回結果通知響應。

2 XML指令文件簡介

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

應用程序時不存在兼容性問題。另一方面，業務的不斷發展帶來新的數據傳遞需求，由于XML可以自定義標記和文檔結構，用戶可以根據需要靈活擴展接口定義，因此XML具有很好的擴展性。

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

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

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

3 故障分析與處理

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

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

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

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

3.2 連續劇傳輸失敗故障分析與處理

連續劇內容傳輸涉及連續劇下的劇集，通常總平臺先新增一個連續劇（Series），然后下發劇集（Pro?gram），并將劇集與連續劇進行映射，最后再將連續劇映射到相應的欄目（Category）下，完成連續劇及其劇集的下發過程。實際應用中出現部分劇集已經下發到分平臺，但這些劇集在分平臺CMS處于下架狀態不能發布到電信平臺問題，進一步檢查發現這些未能發布的劇集都是在總平臺下發連續劇與欄目的映射關系之后下發的劇集。

圖3 海報圖片文件下發流程圖

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

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

圖4 優化后的分平臺內容管理系統（截圖）

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

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

4 小結

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

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

：

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

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

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

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