MRCP協(xié)議學(xué)習筆記-MRCP概要

　　1、準確地說(shuō)，MRCP是一種框架，也是一種協(xié)議。MRCP的框架定義了各種網(wǎng)絡(luò )要素和它們之間的關(guān)系，并且也設定了在MRCP中其他協(xié)議之間的之間的會(huì )話(huà)管理和媒體處理等關(guān)系（例如SIP和RTP）。MRCP協(xié)議本身也提供了對媒體源的控制機制，例如控制語(yǔ)音識別和語(yǔ)音合成等。所以，通常環(huán)境下，我們?yōu)榱朔奖悖�稱(chēng)之為MRCP協(xié)議。當然，讀者也可以稱(chēng)之為MRCP框架。

　　MRCP的設計目的是支持客戶(hù)端對服務(wù)器端發(fā)起一個(gè)請求，設定一個(gè)在網(wǎng)絡(luò )中部署的媒體資源。MRCP的主要目的在于語(yǔ)音處理資源的處理，這些語(yǔ)音處理資源包括：語(yǔ)音識別，語(yǔ)音合成，語(yǔ)音錄音和講話(huà)人的認證和確認。MRCP借用了SIP協(xié)議來(lái)支持MRCP的處理流程。SIP可以使用SIP URL通過(guò)網(wǎng)絡(luò )來(lái)支持MRCP客戶(hù)端來(lái)獲取媒體資源，并且可以查詢(xún)獲取到媒體類(lèi)型和其支持能力。它一旦獲取到正確的媒體資源服務(wù)器信息，SIP將會(huì )創(chuàng )建兩個(gè)通信管道，一個(gè)是用來(lái)支持媒體會(huì )話(huà)，它支持發(fā)送或接收語(yǔ)音數據。這些數據可能是從媒體資源服務(wù)器發(fā)出也可能是來(lái)自于媒體資源服務(wù)器。另外一個(gè)管道是控制會(huì )話(huà)，它用來(lái)支持MRCP客戶(hù)端和媒體資源服務(wù)器之間的請求通信，從服務(wù)器端返回響應消息和事件。這里，MRCP協(xié)議是運行在控制會(huì )話(huà)之上。以下圖例表示了一個(gè)基本的MRCP框架。

　　在MRCP 客戶(hù)端包括了SIP協(xié)議棧和MRCP協(xié)議棧。后者扮演的就是一個(gè)MRCP客戶(hù)端角色。當應用層的程序請求一個(gè)媒體資源的時(shí)候，它會(huì )調用媒體資源的API接口。此API接口通過(guò)SIP協(xié)議棧會(huì )創(chuàng )建一個(gè)SIP dialog 并且攜帶媒體資源服務(wù)器信息。SIP協(xié)議棧會(huì )通過(guò)RTP對媒體服務(wù)器資源初始化一個(gè)媒體會(huì )話(huà)，并且通過(guò)MRCP對媒體資源服務(wù)器創(chuàng )建一個(gè)控制會(huì )話(huà)。

　　在會(huì )話(huà)初始化過(guò)程也可以包括一些服務(wù)器端可預設的專(zhuān)用媒體資源。接下來(lái)，MRCP客戶(hù)端可以通過(guò)會(huì )話(huà)控制直接調用這些專(zhuān)有的媒體資源。MRCP客戶(hù)端可以在同樣的終端設備或作為其他實(shí)體的一個(gè)部分包含媒體資源。客戶(hù)端的SIP協(xié)議則可以充分利用信令和媒體分離的方式，它們分別通過(guò)不同的路徑來(lái)處理。

　　媒體資源服務(wù)器端的也同樣包括了MRCP協(xié)議棧和SIP協(xié)議棧。服務(wù)器端的MRCP執行的是服務(wù)器端的MRCP協(xié)議棧，并且對MRCP客戶(hù)端的請求做出響應，生成事件。如上圖所示，服務(wù)器端包括了各種媒體資源，例如語(yǔ)音識別，合成等引擎。當客戶(hù)端請求多個(gè)資源時(shí)，這些資源可以共享同一媒體會(huì )話(huà)或支持針對每個(gè)媒體資源的專(zhuān)有會(huì )話(huà)。以下圖例比較清晰地解釋了上面的架構示例，方便用戶(hù)做進(jìn)一步的理解MRCP的架構。

　　MRCP充分地利用了SIP協(xié)議的優(yōu)勢，非常完美地解決了管理媒體和控制會(huì )話(huà)的問(wèn)題。從SIP協(xié)議的角度來(lái)看，它管理的話(huà)會(huì )話(huà)屬性本身不是最重要的，它更側重于對媒體資源的定位，提供一個(gè)整合功能。因為SIP協(xié)議提供的媒體資源服務(wù)器查詢(xún)服務(wù)，MRCP客戶(hù)端可以獲得關(guān)于媒體資源的支持能力。

　　2、在上面的章節中我們討論了MRCP的基本架構，其中，在服務(wù)器端支持了很多媒體資源。媒體資源則包括了各種媒體類(lèi)型。MRCP定義了六種媒體資源類(lèi)型，它們分別是：

　　Speech synthesisers（語(yǔ)音合成）支持了兩種語(yǔ)音合成方式。一種是基本的語(yǔ)音合成。基本語(yǔ)音合成把語(yǔ)音文件簡(jiǎn)單進(jìn)行合成，僅支持有限的部分SSML標準，它必須支持的基本語(yǔ)法包括：，

　　dtmfrecog和speechrecog都是媒體資源，都支持語(yǔ)音識別。dtmfrecog僅對DTMF進(jìn)行識別。speechrecog則是我們通常所說(shuō)的語(yǔ)音識別。兩種媒體識別都借用了W3C 的Speech Recognition Grammar Specification （SRGS）設定了單詞，短語(yǔ)（包括DTMF）來(lái)作為語(yǔ)音識別的輸入。語(yǔ)音識別媒體資源通常還包括對通過(guò)語(yǔ)音識別對自然語(yǔ)言結合語(yǔ)法等進(jìn)行處理識別的能力。

　　speech recorder則提供對語(yǔ)音進(jìn)行錄音，然后保存到一個(gè)指定的URL，另外，它同時(shí)也對終端提供一種語(yǔ)音靜音處理作用。當用戶(hù)在某一段設定時(shí)間后已經(jīng)停止講話(huà)，用戶(hù)錄音應該會(huì )去除靜音時(shí)間。

　　Speakverify 媒體資源主要的作用利用聲學(xué)技術(shù)，通過(guò)對講話(huà)者的語(yǔ)音和已保存的聲紋進(jìn)行匹配，確認其身份和簽權認證。

　　3、媒體資源服務(wù)通過(guò)MRCP支持了很多應用場(chǎng)景。現在我們簡(jiǎn)單介紹幾個(gè)具體的應用場(chǎng)景，讓用戶(hù)理解如何通過(guò)MRCP結合語(yǔ)音電話(huà)系統來(lái)實(shí)現分布式語(yǔ)音媒體處理。

　　首先，我們介紹一個(gè)VoiceXML IVR 場(chǎng)景。這里的VoiceXML相當于一個(gè)MRCP的客戶(hù)端，支持了SIP協(xié)議棧，VoiceXML 解析器和MRCP客戶(hù)端。同時(shí)，它也支持了PSTN的接入，通過(guò)SIP 協(xié)議對接MRCP客戶(hù)端SIP。媒體資源服務(wù)器端包括了語(yǔ)音識別，合成，錄音和DTMF識別處理引擎。這樣的應用場(chǎng)景可以運用在呼叫中心等相關(guān)的行業(yè)。當然，目前的很多呼叫中心智能機器人也基本上和以下示例相似。客戶(hù)端可以支持Asterisk或者FreeSWITCH，通過(guò)uniMRCP實(shí)現和媒體資源引擎的交互。

　　早期智能化的IPPBX語(yǔ)音郵箱也是一個(gè)經(jīng)典的應用場(chǎng)景。首先，這里我們說(shuō)明，這是一個(gè)早期的語(yǔ)音郵箱的服務(wù)示例。當然無(wú)論從功能的豐富性，成本優(yōu)勢或其他集成能力，目前的IPPBX或者軟交換的語(yǔ)音郵箱系統本身已經(jīng)非常靈活強大。目前，開(kāi)源的融合通信平臺，例如Asterisk，FreeSWITCH都支持了非常強大的語(yǔ)音留言功能，可以輕松實(shí)現標準化的語(yǔ)音郵箱的語(yǔ)音提示。特別是基于A(yíng)sterisk平臺開(kāi)發(fā)的開(kāi)源免費IPPBX-FreePBX，它支持了豐富的界面管理，用戶(hù)可以通過(guò)界面輕松配置語(yǔ)音郵箱。但是這些不是我們今天討論的范圍。今天，我們重點(diǎn)討論的是基于MRCP集成的IPPBX 語(yǔ)音郵箱。基于MRCP的語(yǔ)音郵箱系統可以通過(guò)MRCP對呼叫方進(jìn)行錄音，合成和語(yǔ)音識別，實(shí)現對用戶(hù)電話(huà)留言進(jìn)行管理，包括語(yǔ)音文件內容，日期，呼叫方名稱(chēng)等。這些數據都可以通過(guò)語(yǔ)音資源引擎進(jìn)行處理，方便儲存。這是以前基于MRCP開(kāi)發(fā)的一種語(yǔ)音郵箱服務(wù)，具體市場(chǎng)用戶(hù)的認可度有多高，我們也不得而知，畢竟語(yǔ)音資源引擎的部署成本和準確率是一個(gè)非常大的挑戰。這里，我們僅作為一個(gè)演示的示例。但是，筆者認為，如果對于IPPBX來(lái)說(shuō)，如果呼叫方（例如，殘障人士，老人，或者病人等）直接對IPPBX系統說(shuō)一個(gè)公司員工的名稱(chēng)就可以自動(dòng)實(shí)現呼叫此員工分機，呼叫方不需要再通過(guò)摁DTMF 按鍵來(lái)?yè)芴枺�這也許也是一個(gè)可行的需求。

　　最后，我們再介紹一個(gè)高級媒體網(wǎng)關(guān)，智能終端或軟交換的應用場(chǎng)景。其實(shí)，這里的媒體網(wǎng)關(guān)應用場(chǎng)景和上面所說(shuō)的IPPBX結合MRCP的應用場(chǎng)景非常相似。這里的高級媒體網(wǎng)關(guān)仍然是MRCP的客戶(hù)端，通過(guò)不同的SIP終端（例如，PJSIP 等終端），物理話(huà)機對媒體網(wǎng)關(guān)發(fā)起一個(gè)請求，通過(guò)媒體網(wǎng)關(guān)的MRCP模塊和媒體資源服務(wù)器端的語(yǔ)音資源引擎進(jìn)行處理。這樣的應用場(chǎng)景和以上我們討論的兩個(gè)場(chǎng)景都有相似之處。所不同的是，如果通過(guò)開(kāi)源SIP終端，結合軟交換或媒體網(wǎng)關(guān)可以實(shí)現更多的應用場(chǎng)景，不僅僅局限于語(yǔ)音呼叫業(yè)務(wù)本身。例如，用戶(hù)可以通過(guò)PJSIP 終端，可以開(kāi)發(fā)手機APP終端，也可以通過(guò)PJSIP嵌入式終端方式實(shí)現智能物聯(lián)網(wǎng)等需求。

　　4、我們在上面的篇幅中分別介紹了MRCP的技術(shù)架構示例，媒體資源類(lèi)型和網(wǎng)絡(luò )應用場(chǎng)景。為了進(jìn)一步了解SIP協(xié)議和MRCP協(xié)議，我們花一點(diǎn)時(shí)間介紹一下SIP協(xié)議和MRCP的工作流程。

　　首先讓我們簡(jiǎn)單了解一下如何創(chuàng )建通信的通道。筆者在前面的介紹中已多次討論過(guò)，MRCP借助SIP協(xié)議完美地解決了通信的控制問(wèn)題。MRCP本身沒(méi)有定義自己的查詢(xún)媒體資源能力和會(huì )話(huà)創(chuàng )建機制。它借助于SIP協(xié)議來(lái)完成。大家知道，在IP通信中，SIP可以在兩個(gè)終端之間創(chuàng )建媒體會(huì )話(huà)。而媒體的傳輸則是獨立于SIP協(xié)議之外的RTP協(xié)議來(lái)完成。在創(chuàng )建會(huì )話(huà)過(guò)程中或者呼叫中的交互中，SIP協(xié)議使用了SDP協(xié)議來(lái)協(xié)助描述和協(xié)商媒體會(huì )話(huà)。以下是一個(gè)簡(jiǎn)單的呼叫創(chuàng )建流程，這里不再介紹SIP呼叫的創(chuàng )建過(guò)程。讀者可以參考其他材料做進(jìn)一步的了解和學(xué)習，讀者也可以查閱本公眾號的歷史文檔有非常詳細的介紹。

　　在簡(jiǎn)單的應用環(huán)境中，一次從媒體資源服務(wù)器調用一種單個(gè)的媒體資源類(lèi)型，媒體會(huì )話(huà)也是單向的。如果同一時(shí)間使用多個(gè)媒體資源類(lèi)型時(shí)則創(chuàng )建雙向的媒體資源流。MRCP和我們常見(jiàn)的IP通信不同，它可以對媒體會(huì )話(huà)包含一個(gè)控制會(huì )話(huà)連接。此控制會(huì )話(huà)是通過(guò)在SDP描述中添加更多消息，例如包括MRCP客戶(hù)端請求的媒體資源類(lèi)型等。這里，媒體會(huì )話(huà)的傳輸是使用RTP通過(guò)UDP端口來(lái)傳輸；而控制會(huì )話(huà)則是通過(guò)MRCP通過(guò)TCP或者SCTP傳輸。以下示例是一個(gè)MRCP客戶(hù)端連接媒體資源服務(wù)器的流程。這里，不要求支持180 響應，但是創(chuàng )建了一個(gè)媒體會(huì )話(huà)和一個(gè)控制會(huì )話(huà)。

　　以上流程中，創(chuàng )建了會(huì )話(huà)以后，MRCP需要控制媒體資源。MRCP協(xié)議消息格式類(lèi)似于HTTP的消息格式，也是一種外部格式。MRCP消息格式包括三種格式：請求消息，響應消息和事件。請求消息是從MRCP客戶(hù)端發(fā)到媒體資源服務(wù)器端，而響應消息則是由媒體資源服務(wù)器端，根據客戶(hù)端的請求返回的響應消息，并且響應消息中包含了一個(gè)三位數的狀態(tài)碼。另外，響應消息中包含了當前的請求狀態(tài)，當前請求狀態(tài)包括：PENDING，IN-PROGRESS 或 COMPLETE的其中一種。

　　PENDING 狀態(tài)表示當前的請求在等待處理的隊列中，等待進(jìn)行處理，處理方式為先進(jìn)先出的方式。IN-PROGRESS狀態(tài)表示當前請求正在被處理。COMPLETE響應則表示完成請求處理，在當前的連接中無(wú)更多消息。在以上三種狀態(tài)中，PENDING和IN-PROGRESS都表示請求未完成處理，需要更多的事件消息。事件消息允許媒體資源服務(wù)器端和客戶(hù)端對某些狀態(tài)的改變或對客戶(hù)端發(fā)生一個(gè)事件來(lái)進(jìn)行通信。事件消息中包括事件名稱(chēng)和請求狀態(tài)。

　　5、以上章節介紹了MRCP如何通過(guò)各種消息來(lái)控制媒體資源。為了讓讀者更加清晰地了解整個(gè)流程的處理方式，我們通過(guò)兩個(gè)完整的示例來(lái)說(shuō)明MRCP協(xié)議對媒體的控制和消息格式。

　　第一個(gè)關(guān)于MRCP協(xié)議的流程示例是語(yǔ)音合成（speech synthesiser）的示例。這里，我們假設媒體會(huì )話(huà)和控制會(huì )話(huà)通過(guò)SIP響應已經(jīng)創(chuàng )建成功，語(yǔ)音流正在傳輸。MRCP客戶(hù)端對服務(wù)器端發(fā)起了一個(gè)SPEAK的請求，開(kāi)始處理此請求，并且要求通過(guò)媒體資源服務(wù)器合成一個(gè)文本。

　　具體的請求消息格式如下：

　　MRCP/2.0 380 SPEAK 14321

　　Channel-Identifier: 43b9ae17@speechsynth

　　Content-Type: application/ssml+xml

　　Content-Length: 253

　　

　　

　　Good afternoon Anne.

　　You have one voice message, two e-mails, and three faxes

　　waiting for you.

　　

　　接下來(lái)的響應的消息格式為：

　　MRCP/2.0 119 14321 200 IN-PROGRESS

　　// ID是14321，200 表示成功，正在處理中，119消息長(cháng)度是119 bytes。

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=857206027059 // 這里是NTP時(shí)間

　　MRCP的狀態(tài)碼包括：200–299（Success）， 400–499（ Client error）和500–599（Server error）。這些狀態(tài)碼和SIP的狀態(tài)碼基本類(lèi)似。

　　讀者已經(jīng)看到，我們的請求的狀態(tài)是IN-PROGRESS ，表示正在被媒體資源處理，大部分情況下，媒體數據可能已經(jīng)返回到MRCP終端。

　　接下來(lái)，媒體資源服務(wù)器端生成一個(gè)SPEAK-COMPLETE事件，表示此請求已經(jīng)完成，對于此請求來(lái)說(shuō)，沒(méi)有更多的事件進(jìn)行處理。

　　MRCP/2.0 157 SPEAK-COMPLETE 14321 COMPLETE

　　Channel-Identifier: 43b9ae17@speechsynth

　　Speech-Marker: timestamp=861500994355

　　Completion-Cause: 000 normal // 表示SPEAK請求的正常處理結束。

　　通過(guò)以上幾個(gè)步驟和響應消息處理，我們可以清晰地看到語(yǔ)音合成的基本處理流程和其相應的返回碼。

　　以上是一個(gè)語(yǔ)音合成的MRCP處理流程，我們再介紹一個(gè)語(yǔ)音識別的MRCP處理流程。這里，我們仍然假設通過(guò)SIP協(xié)議，會(huì )話(huà)控制和媒體控制已經(jīng)創(chuàng )建成功。以下是一個(gè)MRCP客戶(hù)端發(fā)出的請求消息，它要求媒體資源服務(wù)器對語(yǔ)音進(jìn)行識別。注意，這里的請求是RECOGNIZE 請求，而不是剛才我們在語(yǔ)音合成時(shí)的SPEAK請求。

　　RECOGNIZE請求消息如下：

　　MRCP/2.0 461 RECOGNIZE 32121

　　Channel-Identifier: 23af1e13@speechrecog

　　Content-ID:

　　Content-Type: application/srgs+xml

　　Content-Length: 289

　　

　　

　　xml:lang="en-GB">

　　

　　

　　yes

　　no

　　

　　

　　

　　以上消息格式和SPEAK請求格式非常相似，這里的通道是使用的是speechrecog 媒體資源。這里需要識別的是兩個(gè)選項（Yes/No）。同樣，媒體資源服務(wù)器對客戶(hù)端返回一個(gè)正在處理的狀態(tài)消息：

　　MRCP/2.0 79 32121 200 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

　　此消息表示媒體資源服務(wù)器正在處理客戶(hù)端請求，也可能語(yǔ)音識別引擎正在采集媒體流數據，馬上生成一個(gè)識別的語(yǔ)音。當語(yǔ)音識別引擎檢測到語(yǔ)音時(shí)，它會(huì )生成一個(gè)START-OF-INPUT消息。

　　MRCP/2.0 111 START-OF-INPUT 32121 IN-PROGRESS

　　Channel-Identifier: 23af1e13@speechrecog

　　Input-Type: speech

　　這里，客戶(hù)端也可以結束或打斷此語(yǔ)音合成。如果正常處理的話(huà)，語(yǔ)音識別引擎會(huì )生成一個(gè)RECOGNITION-COMPLETE事件消息，并且在消息中包含生成的結果。

　　MRCP/2.0 472 RECOGNITION-COMPLETE 32121 COMPLETE

　　Channel-Identifier: 23af1e13@speechrecog

　　Completion-Cause: 000 success

　　// 000 表示成功，001 表示無(wú)匹配結果，002 表示輸入超時(shí)。

　　Content-Type: application/nlsml+xml

　　// W3C發(fā)布的NLSML

　　Content-Length: 289

　　

　　

　　xmlns="http://www.ietf.org/xml/ns/mrcpv2">

　　

　　

　　yes

　　

　　yes

　　

　　

　　在MRCP V2版本（RFC6787）中支持了兩種結果輸出格式，一種是nlsml（通常說(shuō)的自然語(yǔ)言語(yǔ)義的標記語(yǔ)言或者描述語(yǔ)言）是由W3C發(fā)布。另外一種是EMMA標記語(yǔ)言。EMMA全稱(chēng)為Extensible Multimodal Annotation Markup Language （EMMA）。如果讀者有興趣的話(huà)，可以查閱相關(guān)的參考文檔做進(jìn)一步的研究。

　　6、通過(guò)以上完整的介紹，可能讀者對MRCP有了一個(gè)基本的概念。但是，在部署MRCP客戶(hù)端或服務(wù)器端時(shí)，我們這里沒(méi)有真正關(guān)注其安全性的問(wèn)題。在今天的IP通信中，其實(shí)用戶(hù)已經(jīng)對SIP協(xié)議的使用場(chǎng)景做了很多的設置，但是如果沒(méi)有對MRCP協(xié)議或使用流程做安全設置的話(huà)，特別是MRCP協(xié)議中使用了多個(gè)XML文件和其語(yǔ)法語(yǔ)義解析文件，并且大部分的MRCP客戶(hù)端都是通過(guò)公網(wǎng)訪(fǎng)問(wèn)的第三方的媒體資源服務(wù)器，如果沒(méi)有設置安全措施的話(huà)，同樣可能給客戶(hù)帶來(lái)很多的安全隱患。這些安全問(wèn)題包括：

• 會(huì )話(huà)創(chuàng )建時(shí)的安全問(wèn)題。在SIP創(chuàng )建過(guò)程中用戶(hù)一定要注意安全的設置。
• 控制會(huì )話(huà)的保護。如果對其控制會(huì )話(huà)沒(méi)有做保護措施的話(huà)，可能導致第三方對其進(jìn)行安全攻擊。
• 媒體會(huì )話(huà)的保護。如果我們的媒體數據沒(méi)有經(jīng)過(guò)安全設置，可能導致媒體數據被監聽(tīng)或盜取。
• 非直接的內容訪(fǎng)問(wèn)。因為，我們的合成內容或語(yǔ)音可能經(jīng)過(guò)公網(wǎng)進(jìn)行處理，如果第三方非法訪(fǎng)問(wèn)我們的最終數據，可能導致安全問(wèn)題。
• 保護已存儲的媒體文件。客戶(hù)端和媒體資源服務(wù)器端需要針對媒體文件存儲設置一定的安全措施和安全權限來(lái)保證媒體文件不被盜取或非法訪(fǎng)問(wèn)。

　　7、在本分享中，我們首先介紹了關(guān)于MRCP的基本結構，然后分別介紹了MRCP響應中多個(gè)核心模塊和接口，MRCP客戶(hù)端的處理方式和媒體資源服務(wù)器端的處理方式。我們也介紹了MRCP目前支持的媒體資源類(lèi)型，以及結合語(yǔ)音服務(wù)，媒體網(wǎng)關(guān)完成對語(yǔ)音識別應用場(chǎng)景。為了進(jìn)一步幫助讀者了解進(jìn)一步了解MRCP的處理流程，我們對媒體控制和幾種請求響應狀態(tài)和處理流程做了介紹，并且結合語(yǔ)音合成和語(yǔ)音識別的消息處理流程，給讀者提供了一個(gè)較完整的消息解析。最后，為了部署安全穩定的解決方案，筆者也從幾個(gè)不同的方面討論了關(guān)于MRCP的安全性問(wèn)題，希望讀者能夠引起重視。

　　在接下來(lái)的分享學(xué)習中，筆者會(huì )更加詳細地一步步介紹MRCP協(xié)議中各個(gè)模塊功能作用。希望讀者繼續關(guān)注。

　　參考資料：

　　https://www.w3.org/TR/2004/REC-speech-synthesis-20040907/

　　https://www.w3.org/TR/2009/REC-emma-20090210/

　　關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的行業(yè)分享

　　freepbx 技術(shù)論壇：www.ippbx.org.cn

　　Asterisk， freepbx技術(shù)文檔： www.freepbx.org.cn

　　歐米（Omni）智能客服解決方案

　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com