馬正先

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

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

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

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

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

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

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

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

2 XML指令文件簡(jiǎn)介

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

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

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

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

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

3 故障分析與處理

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

3.1 海報(bào)圖片傳輸故障分析與處理

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

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

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

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

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

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

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

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

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

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

4 小結(jié)

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

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

：

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

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

[3]張一鳴，安春花，王偉民.XML搜索引擎技術(shù)在臺(tái)網(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.