基于sip傳輸協議的移動心電采集及診斷系統的制作方法

基于sip傳輸協議的移動心電采集及診斷系統的制作方法
【專利摘要】本發明屬于物聯網技術領域，具體為一種基于SIP傳輸協議的移動心電采集及診斷系統。本發明系統包括心電采集工作站、心電數據傳輸與控制、心電會診工作站、心電數據庫、和心電信息管理系統。系統是基于通訊SIP傳輸協議的集心電圖采集、查看、會診及管理為一體的平臺；通過業務系統事件觸發集成整個過程，系統可與HIS系統及其他第三方系統對接，實現數據交換。心電數據的傳輸使用SIP會話協議，用于注冊、會話、傳輸、控制和釋放會話，該協議采用詢問、應答機制的方式實現實時心電數據的傳輸。本發明可用于醫療物聯網，系統技術成熟、安全可信、部署快速便捷、有助于推動移動醫療的發展，擁有廣闊的應用前景。
【專利說明】
基于s IP傳輸協議的移動心電采集及診斷系統
技術領域
[0001] 本發明屬于物聯網技術領域，具體涉及基于sip通訊協議傳輸數據的移動心電采 集及診斷系統。
【背景技術】
[0002] SIP(Session Initiation Protocol會話初始協議)是一個在IP網絡上進行多媒 體通信的應用層控制協議，它被用來創建、控制、結束一個或多個參加者參加的會話進程。 這些會話包括文本、視頻、語音、遠程醫療等。即所有的因特網上交互式兩方或多方多媒體 通信活動，統稱為多媒體會話。SIP協議是Internet制定設計的協議，采用UTF-8字符集來 進行編碼的文本協議，采用詢問與應答機制，參加會話的成員可以通過組播方式、單播聯網 方式或者兩者結合的方式進行通信。它是一種應用層協議，獨立于傳輸層協議，可以承載在 不同的傳輸協議上。如圖1所示。
[0003 ] 1、S IP協議支持終端用戶能夠在任何地方、任何時間請求和獲得服務會話啟動協 議，SIP協議功能實體，如下幾種： 定位服務(Location Service) : SIP重定位服務器或代理服務器用來獲得被叫位置的 一種服務，可由定位服務器提供，但SIP協議不規定SIP服務器如何請求定位服務。
[0004] 代理服務器(Proxy sever):用于代表其他用戶發出請求的中間程序。它既是客戶 機也是服務器。用戶請求可以直接被代理服務器處理或被轉發給別的代理服務器。代理服 務器在轉發之前要對消息進行解析，必要時還會改寫請求。
[0005] 重定向服務器(Redirect Server):用來接收SIP請求，將其地址映射成零個或多 個新地址，并把結果返回給客戶。收到主叫用戶的INVITE邀請消息，它通過查找定位服務器 發現該請求應該被重新定向（重定向主要原因為:位置改變、負荷分擔等），就構造一個重定 向響應消息(狀態碼為3xx)，將新的目標地址回送給主叫用戶。主叫用戶收到重定向響應消 息后，將逐一向新的目標地址發送INVITE邀請，直至收到成功響應并建立關聯。
[0006] 注冊員（Register):用來接收REGISTER請求消息的服務器，常與代理或重定向 服務器在同一位置，可以提供定位服務。
[0007] 用戶代理客戶端(User Agent Client):用來發起SIP請求的客戶程序。
[0008] 用戶代理服務器(User Agent Server):收到SIP請求后負責與用戶聯系并代表用 戶回送響應的服務程序。該響應可以表示接受、拒絕或重定向請求消息。
[0009] SIP設計采用客戶端/服務器架構，其邏輯實體如圖2所示。
[001 0] 2、SIP協議其結構化的層次關系，如圖3所示。
[0011] SIP消息采用文本方式編碼，消息包括兩類：請求消息和響應消息。消息 (Message)是SIP協議的基本單位，客戶端和服務器端的基本交互單元，如圖4所示。
[0012] SIP消息有兩種：客戶機到服務器的請求（Request)，服務器到客戶機的響應 (Response)〇
[0013] SIP消息由一個起始行（start-line)、一個或多個字段(field)組成的消息頭、一 個標志消息頭結束的空行(CRLF)以及作為可選項的消息體(message boby)組成。
[0014] CRLF:回車換行（carriage return/line feed)CRLF是一個標志消息頭結束的空 行。
[0015] A、請求消息：用于客戶端為了激活按特定操作而發給服務器的SIP消息。請求消 息類型包括：INVITE，ACK，OPTIONS，BYE，CANCEL 和 REGISTER 消息等，見表 1。
[0016] 表1
Request = Request-Line *(general-header | request-header | entity-header CRLF [message-body] 請求行（Request-Line )以方法(me thod)標記開始，后面是Request-URI和協議版本 (SIP-Version)，最后以回車鍵結束，各個元素間用空格鍵字符間隔。
[0017] Request-Line = Method SP Request-URI SP SIP-Version CRLF SIP。例如： INVITE sip:info@sidmedical.cn SIP/2.0 用術語"method"來對說明部分作以描述，Method標識是區分大小寫的。SIP定義了以下 幾種方法(methods )。
[0018] Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" | "CANCEL" "REGISTER" | "INFO"。
[0019] B、響應消息：用于對請求消息進行響應，指示呼叫的成功或失敗狀態。響應消息由 狀態碼來區分，狀態碼包含三位整數，狀態碼的第一位用于定義響應類型，另外兩位用于進 一步對響應進行更加詳細的說明，包括:lxx，2xx，3xx，4xx，5xx，6xx，見表2。
[0020] 表 2


Response = Status-Line *(general-header | response-header | entity-header CRLF [message-body] 〇
[0021] 狀態行（Status-Line)以協議版本開始，接下來是用數字表示的狀態碼（Status-code) 及相關的文本說明 ，最后以回車鍵結束，各個元素間用空格字符 (SP) 間隔 ，除了在最 后的CRLF序列中，這一行別的地方不允許使用回車或換行字符。
[0022] Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF〇
[0023] SIP協議中用三位整數的狀態碼（Status Code)和原因值(Reason Code)來表示對 請求的作出回答，狀態碼用于機器識別操作，原因短語(Reason-Phrase)是對狀態碼的簡單 文字描述，用于人工識別操作。
[0024] 例如：SIP/2.0 200 0K Status-Code = lxx (Information) | 2xx (Success) | 3xx (Redirection) | 4xx (Client-Error) | 5xx (Service-Error) | 6xx (Global-Failure) | extension-code o
[0025] 3基本數據類型
[0026] 4、SIP 消息： SIP消息(Message)采用文本方式編碼，任一 SIP消息都由起始行、頭域和消息體組成， 頭域都必須以CRLF(回車換行)結尾。如圖5所示。
[0027] (1)SIP起始行分請求行(Request-Line)和狀態行（Status-Line)兩種，其中請求 行是請求消息的起始行，狀態行是響應消息的起始行。如： 請求行:REGISTER sip:registrar.bplace.com SIP/2.0 狀態行：SIP/2.0 200 OK (2) 頭域（SIP Header) 攜帶SIP實體的屬性、消息體的屬性等。頭域必須以CRLF結尾，頭域的基本結構，如： 頭域名:頭域值;頭域參數 說明：頭域參數不是必備的，有些頭域不存在頭域參數 舉例： From: sip:scOsidmecical.cn；tag=l234567890 To: sip:info? sidmecical.cn; Call-ID: info@sidmecical.cn 頭域一單值與多值： 單值:消息里面只能出現一次，如From，To等 多值:消息里面可以多次出現，如Via，Route等 頭域一域值的順序 順序有關的：Via，Route，Record-Route 順序無關的：Allow，Require 重要的頭域:如下的5個頭域必須包含在每個SIP消息中。
[0028] Via :用于表示請求經過的SIP實體和路由響應； 例如：Via:SIP/2·0/UDP sidmedical · cn; branch=z9hG4bKkjshdyff From:用于標識請求的發起者；以呼叫為例，可能是主叫也可能是被叫； 格式為:From:顯示名 <sip-URL> ;tag=XXXX To:用于表示請求的接收者； 格式為:To:顯示名 <sip-URL> ;tag=XXXX Cal 1-ID :用于唯一標識一次邀請或者一次注冊； 格式為:Cal 1-ID:本地標識@主機 CSeq:用于表示請求的順序號； 例如：CSeq :4711 INVITE (3) 消息體(SIP Body) ΜΠ1Ε類型的消息體，可以支持任何類型的消息體(文本/二進制)和復合消息體(包含多 個單消息體） 消息體的屬性通過Content頭域來描述： Content-Type :消息體的類型，可以是SDP/Text或者其他 Content-Length :消息體的長度，對于UDP不是必須，對于TCP則是必須 Content-Language:消息體的語言類型 Content-Encoding :消息體的編碼類型，如是否進行了 zip壓縮 Cont ent_D i spo s i t i on:對于消息體的處理方法。

【發明內容】

[0029] 本發明的目的在于提供一種基于SIP傳輸協議的集心電實時采集、傳輸、顯示、遠 程會診為一體的移動心電采集及診斷系統。
[0030] 本發明提供的移動心電采集及診斷系統，使用SIP協議傳輸數據，通過業務系統事 件觸發集成過程，將采集系統的心電圖數據實時傳輸至心電會診工作站，在采集端和會診 端實時查看心電圖，進行心電診斷，并統一將業務數據存儲至數據庫。
[0031] -、SIP事務定義 一個SIP事務（Transaction )包含： SIP事務（Transaction )由一個單一的請求和對這個請求的任何響應(包括零或多個 臨時響應以及一個或多個最終響應)組成。事務中的請求是INVITE(稱為INVITE事務)時， 只有最終響應不是2xx響應時這個事務才包括ACK。如果最終響應是2xx，那么不應將ACK 視為事務的一部分。該ACK視為單獨事務。事務可以分為兩大類： UINVITE事務：INVITE事務由一個三向握手組成。客戶端事務發送INVITE，服務器事 務發送響應，客戶端事務還要發送一個ACK。對于INVITE的成功響應，ACK不屬于INVITE事 務，而是單獨的事務。如圖6所示。
[0032] 2、非INVITE事務:兩次握手（如BYE) 非INVITE事務不使用ACK。它們是簡單的請求一響應交互，對于非INVITE事務，一般不 存在臨時響應，對于最終響應的處理也是一樣的。如圖7所示。
[0033] 3、特殊的事務 ACK事務:對于200 of INVITE的確認(ACK)事務，是一個單獨的事務。也就是說一個消 息就是一個事務； CANCEL事務:CANEL事務只能用于CANCEL INVITE事務，而不能用于CANCEL非INVITE事 務;CANCEL事務的branch參數和INVITE是相同的，CANCEL事務只能在收到INVITE的臨時 響應后(包括100)，最終響應之前發送。如圖8所示。
[0034] 4、事務的可靠性一一消息重傳 可靠傳輸上的請求/響應消息不會重傳，SIP協議可以承載在非可靠的UDP傳輸協議之 上，所以在SIP協議中引入了超時重傳機制來保證可靠性，對于INVITE事務和非INVITE事 務，定義了不同的重傳方法： INVITE事務 (1) 對不可靠的傳輸，客戶端事務會在時間間隔T1后重傳請求，每次重傳后該時間翻 倍。T1是對往返時間（RTT)的估計，其缺省值為500ms。對于T1的缺省值來說，這將會產生 500ms、1 s、2s、4s、8s、16s 的時間間隔； (2) 接收到一個lxx響應后，任何重傳都停止，客戶端會等待進一步的響應； (3) 對客戶端事務接收到的每一個最終響應，客戶端事務都會發送一個ACK，其目的是 結束響應的重傳。
[0035]非 INVITE 事務 (1)對于不可靠的傳輸，請求在一個時間間隔(時間間隔起始值為T1，在到T2前該時間 間隔每次翻倍）內進行重傳。如果接收到一個臨時響應，那么對不可靠傳輸而言，將繼續重 傳(但時間間隔在T2內）。對于T1和T2的缺省值來說，這將會產生500ms、ls、2s、4s、4s、4s 的時間間隔； (2)服務器事務只有在接收到重傳請求時，才會重傳它發送的最后一個響應，這個響應 可以是臨時響應，也可以是最終響應。這就是即使在臨時響應之后，仍需繼續重傳請求的原 因：它們是為了確保可靠的傳輸最終響應。
[0036]二、SIP 對話 對話(Dialog)是兩個UA間持續一段時間的對等SIP關系，對話是由To標簽、From標 簽和Call-ID -起定義UAC和UAS間對等的SIP關系。
[0037] 對話不關心任何消息體的信息，由Call-ID，From Tag，To Tag唯一標識；建立后 不能被修改。當收到帶To Tag的lxx響應(非100)時，進入Early Dialog狀態;被叫發送 200 0K且主叫收到200 0K后，進入了Confirmed狀態。如圖9所示。
[0038] 在Early狀態下，主叫可以通過發送BYE或CANCLE來終結Dialog; 在arly狀態下，或者通過被叫的失敗應答來終結Dialog; 在Early狀態下，被叫是不能發送BYE來終結Dialog的； Conf irmed狀態下，主叫和被叫都能通過BYE來終結Dialog。
[0039] 三、通信流程 1、SIP消息注冊 用戶每次開機時，都需要向服務器注冊，當SIP Client的地址發生改變時需要重新注 冊，注冊信息必須定期刷新，通常Register將注冊信息保存到Location Server中，作用是 將A0R地址綁定到某個Contact地址上，便于Proxy在呼叫時查找被叫的地址。如圖10所示， 說明如下： (1) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)發起注冊請求； (2) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回401，即該用戶無權限； (3) 戶代理客戶端(UAC)授權，再次向用戶代理服務器(UAS)發起注冊請求； (4) 用戶代理服務器(UAS)注冊成功向用戶代理服務器(UAC)返回200 0K消息。
[0040] UAC:User Agent Client即用戶代理客戶端。一個address-of-record(AOR)是一 個SIP或者SIPS URI，它指向了一個具有定位服務的主機，這個主機可以把URI映射成為用 戶真正物理位置的URI。
[0041 ] UAS:User Agent Server即用戶代理服務器。
[0042] 2、直接傳輸 當主叫用戶代理客戶端(UAC)知道被叫的當前的位置時，可以通過INVITE消息直接向 被叫用戶代理服務器(UAS)發出呼叫請求。直接呼叫最為簡單，并且也是其他呼叫方式的基 礎。如圖11所示，說明如下： (1) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)發起INVITE請求； (2) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回100,即表示已經接收到請求消 息，正在對其進行處理； (3) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回200 0K消息； (4) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)返回ACK消息； (5) 用戶代理客戶端(UAC)和用戶代理服務器(UAS)之間數據傳輸。
[0043] 3、代理傳輸 隨著后期用戶數量的增加，應用并發量逐步擴大，可以逐步增加接入心電服務器，并使 用代理服務器或重定向服務器來負荷分擔，使得系統更有效使用與資源分配。所述服務器 端(重定向服務器、代理服務器）：用戶客戶端向服務器端進行注冊前，所述服務器端根據各 服務器運行情況，分配負荷最小的一個可用SIP注冊服務器給所述用戶客戶端。
[0044] 當主叫用戶代理客戶端(UAC)不知道被叫的當前的位置時，UAC可通過網絡中間的 服務器設備的轉發，最終到達UAS。即用戶代理客戶端（UAC)可以向代理服務器（Proxy Server)發起INVITE請求，再由代理服務器(Proxy Server)向用戶代理服務器(UAS)發出呼 叫請求。如圖12所示，流程如下： (1) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)發起INVITE請求； (2) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回100,即表示已經接收到 請求消息，正在對其進行處理； (3) 代理服務器(Proxy Server)向用戶代理服務器(UAS)發起INVITE請求； (4) 用戶代理服務器(UAS)向代理服務器(Proxy Server)返回200 0K消息； (5) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回200 0K消息； (6) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)返回ACK消息； (7) 代理服務器(Proxy Server)向用戶代理服務器(UAS)返回ACK消息； (8) 用戶代理客戶端(UAC)、代理服務器(Proxy Server)、用戶代理服務器(UAS)之間數 據傳輸。
[0045] 4、重定向傳輸 流程如圖13所示，說明如下： (1) 用戶代理客戶端(UAC)向重定向服務器(RedirectServer)發起INVITE請求； (2) 重定向服務器(RedirectServer)向用戶代理客戶端(UAC)返回301，即表示永久迀 移； (3) 用戶代理客戶端(UAC)向重定向服務器(RedirectServer)返回ACK消息； (4) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)發起INVITE請求； (5) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回200 0K消息； (6) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)返回ACK消息； (7) 用戶代理客戶端(UAC)和用戶代理服務器(UAS)之間數據傳輸。
[0046] 5、重定向代理傳輸 流程如圖14所示，說明如下： (1) 用戶代理客戶端(UAC)向重定向服務器(RedirectServer)發起INVITE請求； (2) 重定向服務器(RedirectServer)向用戶代理客戶端(UAC)返回302,即表示臨時迀 移； (3) 用戶代理客戶端(UAC)向重定向服務器(RedirectServer)返回ACK消息； (4) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)發起INVITE請求； (5) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回100,即表示已經接收到 請求消息，正在對其進行處理； (6) 代理服務器(Proxy Server)向用戶代理服務器(UAS)發起INVITE請求； (7) 用戶代理服務器(UAS)向代理服務器(Proxy Server)返回200 OK消息； (8) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回200 OK消息； (9) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)返回ACK消息； (10) 用戶代理客戶端(UAC)、代理服務器(Proxy Server)、用戶代理服務器(UAS)之間 數據傳輸； (11) 用戶代理服務器(UAS)向代理服務器(Proxy Server)發送BYE消息； (12) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)發送BYE消息； (13) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)返回200消息； (14) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回200 0K消息。
[0047]上述SIP消息注冊、直接傳輸、代理傳輸、重定向傳輸、重定向代理傳輸等流程中出 現的：401，100，200，301，302，等等，其數字標號的含義參見表2; INVITE、ACK、BYE，等等，其 含義參見表1。
[0048] 6、心電數據傳輸 當心電工作站向服務器請求發送心電圖數據時，心電工作站SIP模塊發送數據時即觸 發系統整個流程:首先，心電采集工作站采集心電圖數據，并將心電圖數據傳輸給服務器， 服務器SIP模塊接收數據，并對接收的心電圖數據拆包并進行解析，然后將數據發送給心電 會診工作站，再向移動心電工作站發送響應消息。另外服務器同時將接收的心電圖數據轉 儲至數據庫。心電會診工作站SIP模塊通過SIP協議接收服務器發送的數據，對數據進行解 析后在心電會診工作站實時顯示移動心電采集的心電圖，醫生可以在會診工作站進行會診 相關操作。
[0049] 1)心電采集 流程如圖15所示，說明如下： (1)采集客戶端(MIEC)向心電服務器(MIESERVER)發送邀請； (2 )心電服務器(MIESERVER)創建直播間； (3) 心電服務器(MIESERVER)返回成功消息給心電采集客戶端(MIEC); (4) 采集客戶端(MIEC)發送心電數據給心電服務器(MIESERVER); (5) 心電服務器(MIESERVER)將數據轉發至直播間； (6) 心電服務器(MIESERVER)向心電采集客戶端(MIEC)發送接收到數據響應； (7) 采集客戶端(MIEC)向心電服務器(MIESERVER)發送鏈接終止命令； (8) 心電服務器(MIESERVER)通知直播間心電采集客戶端(MIEC)退出； (9) 心電服務器(MIESERVER)向心電采集客戶端(MIEC)終止連接的應答。
[0050] 2)心電采集發送 I0CP(I/0 Completion Port),常稱1/0完成端口。I0CP模型屬于一種通訊模型，適用 于(能控制并發執行的）高負載服務器的一個技術。用于高效處理很多很多的客戶端進行數 據交換的一個模型。或者可以說，就是能異步1/0操作的模型。流程如圖16所示，說明如下： (1) 心電采集客戶端(MIEC)向TCP的I0CPM0DEL模塊發送接入邀請； (2) I0CPM0DEL模塊查找RoomMgr (房間列表)該(MIEC)采集端是否創建直播間； (3 )當沒查找到房間，10CPM0DEL模塊向RoomMgr (房間列表)創建直播間記錄； (4)創建直播間ROOM; (5 ) IOCPMODEL模塊為創建的直播間分配ROOM ID; (6) 當查找到房間則IOCPMODEL模塊分配現有的ROOM ID; (7) 采集客戶端(MIEC)向I0CPM0DEL模塊發送數據； (8 ) I OCPMODEL模塊在RoomMgr (房間列表)查找到直播間信息； (9H0CPM0DEL模塊將從采集客戶端(MIEC)接收到的數據發送給直播間，直播間即可查 看到心電圖數據。
[0051 ] 3)心電會診連接 流程如圖17所示，說明如下： (1) 會診客戶端(MIED)向心電服務器(MIESERVER)發送會話請求； (2) 經系統鑒權成功后，心電服務器(MIESERVER)將會診客戶端(MIED)加入選擇的直播 間； (3) 心電服務器(MIESERVER)向會診客戶端(MIED)返回成功消息； (4) 心電服務器(MIESERVER)向會診客戶端(MIED)發送數據，使會診客戶端(MIED)能看 見采集客戶端發來的心電數據； (5) 會診客戶端(MIED)向心電服務器(MIESERVER)發送接收數據響應； (6) 會診客戶端(MIED)向心電服務器(MIESERVER)發送鏈接終止命令； (7) 心電服務器(MIESERVER)通知直播間會診客戶端(MIED)退出； (8) 心電服務器(MIESERVER)向會診客戶端(MIED)終止連接的應答。
[0052] 4)心電會診接收 流程圖18所示，說明如下： (1) 會診客戶端(MI ED )向TCP的I OCPMODEL模塊發送接入邀請； (2) I0CPM0DEL模塊在RoomMgr查找房間； (3) 加入房間； (4 )房間發送心電數據給I OCPMODEL模塊； (5) I0CPM0DEL模塊將數據發送給會診客戶端(MIED); (6) R00M模塊發送終止連接，通知至IOCPMODEL模塊； (7) IOCPMODEL模塊將終止連接發送至會診客戶端(MIED)，數據接收終止。
[0053]四、移動心電采集及診斷系統的設計 本發明設計的移動心電采集及診斷系統，包括:移動心電采集工作站、心電數據傳輸與 控制模塊、心電數據庫、心電信息管理系統、醫生心電會診工作站，通過心電采集事件觸發 集成整個業務過程，并將相關業務數據(如心電圖、診斷報告等)存儲至數據庫。
[0054]所述移動心電采集工作站(MIEC)，使用心電采集設備和平板電腦等，通過心電采 集系統，主要為養老院、社區服務中心等采集心電圖，以及救護車現場急救人員采集心電圖 使用，可進行病人信息添加、心電采集、存儲，并可將信息數據發送到心電數據庫、心電信息 管理系統、醫生心電會診工作站，還可查詢病人相關信息及歷史記錄（如心電圖、急救記錄 等信息）。
[0055]該移動心電采集工作站還可提供刷醫保卡，通過接口調用HIS系統獲取病人的基 本資料，如無法刷醫保卡，可在系統中手動輸入病人基本資料，既往病史等信息;通過心電 采集盒采集心電數據，在移動設備上顯示12導心電圖信號。
[0056]所述心電數據傳輸與控制模塊(MIESERVER)，用于移動心電采集工作站、醫生心電 會診工作站之間的數據傳輸。該模塊主要使用SIP協議，用來傳輸移動心電采集工作站、心 電會診工作站的數據傳輸與控制，確保各個系統之間信息數據的傳遞，另外該模塊還負責 將采集的心電數據存儲至數據庫。該模塊有以下幾個子模塊分別是 ：I0CPM〇del，R〇〇mMgr、 Room模塊。I0CP(I/0 Completion Port)，常稱I/O完成端口。I0CP模型屬于一種通訊模型， 適用于(能控制并發執行的）高負載服務器的一個技術。用于高效處理很多很多的客戶端進 行數據交換的一個模型。或能異步I/O操作的模型。RoornMgr即房間列表，用于存放已建立的 房間列表。ROOM即房間，該模塊用于接收、查看心電圖心電直播間。
[0057]所述心電數據庫，用于存儲病人基本信息、心電圖數據、診斷報告、圖片等等信息， 并為移動心電采集工作站和醫生心電會診工作站提供數據對接，還有為心電信息管理系統 提供統計、查詢功能。
[0058]所述醫生心電會診工作站(MIED)，用于接收來自各移動心電采集工作站采集的心 電采集信息，提供院內醫生查看心電圖信息，進行診斷，包括做出相應的測量、會診，撰寫診 斷結論等;并將相關數據(包括診斷結論等)存儲至心電數據庫。可以通過電腦、平板、手機 進行相關操作。
[0059]所述心電信息管理系統，提供對醫院、醫生、病人的人員信息管理，具有系統使用 權限、心電圖查看、會診、撰寫診斷報告、統計分析報表、歷史記錄查詢及診斷報告打印等功 能。可提供WEB服務，供全院相關醫生瀏覽各種心電檢查報告，實現遠程會診等。
[0000]系統部署結構如圖19所示。
[0061]可以在急救中心/社區服務中心部署移動心電采集工作站，在醫院部署心電會診 工作站，在云平臺，實現數據的傳輸。心電圖數據通過移動網絡將心電圖數據傳送至心電數 據傳輸與控制模塊，心電數據傳輸與控制模塊將獲取的數據寫至數據庫，并根據選擇將數 據發送到選擇的的醫院，在醫院內部醫生登錄心電會診工作站，選擇直播間進入即實時查 看到病人的心電圖信息，醫生能對該心電圖信息及時作出診斷意見。另外在心電采集工作 站可以查看歷史的診斷信息等。
[0062]本發明提供的移動心電采集及診斷系統，其集成流程見圖20所示，具體如下： (1)移動設備(平板、手機)通過藍牙或者USB的方式與心電采集設備連接，使用移動心 電米集工作站米集心電圖。
[0063] (2)移動設備(平板)通過USB的方式與(采集盒，統一用心電采集設備)心電采集設 備連接，采集心電圖采用數字采集接口，從(采集盒)心電采集設備中獲取心電數據。
[0064]注:藍牙(采集盒）心電采集設備每次傳輸出來的數組總共18個元素，經過算法解 析后轉換成繪圖所需要的16個元素。
[0065] (3)實時顯示心電采集設備采集來的心電數據； 系統通過讀取、解析采集來的數據，在移動設備上裝有心電采集工作站中可實時查看 心電圖，并可實現3*4導聯、12*1導聯、2*6導聯、2*6+1導聯、3*4+2導聯、1導聯、60秒導聯圖 形切換顯示。系統可選擇將心電數據發送至哪一家醫院，由該醫院給出心電診斷。
[0066] (4)心電數據傳輸 心電數據傳輸使用SIP協議傳輸數據，提供SIP注冊、直接傳輸、代理傳輸、重定向傳輸、 重定向代理傳輸幾種傳輸模式； 心電采集工作站通過傳輸模塊將采集的心電數據寫入數組，當滿足一定數量后(可配 置16的倍數)通過SIP協議將數據發送至服務器； 心電采集工作站通過傳輸模塊將采集的心電數據寫入數組，當達到指定數據大小后， 將采集的數據通過SIP協議傳輸至服務器。
[0067]數據發送的過程，設置連接地址，指定的端口號。將連接信息發送給服務器，其包 含消息頭(包含消息總長度，命令或響應類型，命令執行狀態），消息主體(包括姓名，年齡， 性別）。服務器驗證正確性，進行連接。連接成功后，采集端的設備開始獲取藍牙采集盒發送 過來的數組，調用繪圖工具進行波形圖的繪制，在頁面顯示波形。與此同時為保證數據的正 確性和及時性，將每次采集的16個元素裝載到定制好的容器數組當中。當容器裝滿時，進行 處理，添加消息頭，而消息的主體就是此容器中的數據。最后通過SIP傳輸協議將數據發送 到服務器。
[0068] (5)服務器SIP協議模塊接收移動心電采集工作站SIP模塊傳輸的心電數據； 服務器SIP模塊接收移動心電工作站傳輸過來的心電數據，主要分為兩類:請求消息和 響應消息。其中向心電會診工作站發送請求，向移動心電工作站發送響應消息。
[0069] (6)服務器對接收的心電圖數據進行解析； 服務器對接收的心電圖數據拆包并進行解析。
[0070] (7)服務器SIP模塊將接收的心電圖數據轉發給心電會診工作站并將數據存儲至 數據庫； 服務器對拆包解析的心電圖數據同步存儲至數據庫，另外當使用心電會診工作站時服 務器會通過其SIP模塊將數據發送至心電會診工作站。
[0071 ] (8)心電會診工作站SIP模塊通過SIP協議接收服務器發送的數據； 醫生選擇需要查看的直播間即心電會診工作站SIP模塊開始接收心電數據。
[0072]數據接收的過程需要設置連接地址和指定的端口號。將信息發送給服務器，其包 含消息頭(包含消息總長度，命令或響應類型，命令執行狀態），消息主體(用戶登陸ID、消息 類型、消息長度、消息內容(直播間編號)等信息）。服務器接收消息后驗證正確性，驗證成功 后再發送連接響應。會診端接收連接響應后判斷消息頭部，如果該消息是連接消息，則連接 成功，否則，連接失敗，下次重新連接。連接成功后，會診端的設備開始接收心電采集工作站 發送過來的數據，調用繪圖工具進行波形圖的繪制，在頁面顯示波形。為保證數據的正確性 和及時性，會診端每次接收數據后判斷消息頭部，如果該消息為數據消息，則接收它，否則 重新接收。接收的緩沖區大小也設置為16(8個導聯，每個2字節）的倍數，一般為1600(系統 可配置），從而確保每組數據的完整。
[0073] (9)心電會診工作站實時顯示移動心電采集的心電圖，醫生可以通過軟件進行查 看、測量、診斷操作。
[0074]心電會診工作站實時顯示移動心電采集的心電圖，醫生可以通過軟件進行查看、 測量、診斷操作。
[0075]本發明為心電采集工作站和醫生心電診斷工作站之間進行異步集成，具備以下特 占. (1)具有良好的信息數據接口 可通過"數據接口"無縫連接到相關的系統，實現多系統之間的數據交換，融合醫院信 息資源，消除信息孤島，支撐醫院構架網絡化的醫院信息管理體系。
[0076] (2)實現心電圖的信息化管理，優化急救中心與醫院拯救工作流程 心電信息綜合管理系統已日益完善成熟，借助信息技術(IT)的強大功能實現心電信息 的數字化存檔、高速網絡通訊、病歷及報告相關數據庫檢索、管理等，真正實現有病歷、有據 可查的管理模式，通過與HI S融合，可實現心電圖資源共享。此外，還可實現工作流程優化， 改變和完善醫院的管理水平，優化人員結構。
[0077] (3)電子檔案全程控制管理 從建立基本信息到各種心電圖報告輸出，涉及數據信息與業務流程全程系統管理，規 避第三方軟件對數據信息的加工處理，分檢、輔助設備檢查、由系統驅動崗位責任人通過系 統采集與處理，保證數據資料的真實性、可靠性和安全性。
[0078] (4)檢查與診斷分開 可由臨床醫生即可進行心電檢查，心電醫生診斷，充分發揮網絡、信息化的特點。
[0079] (5)操作界面簡便實用 系統交互流程遵從醫生日常工作習慣，安裝及使用簡單易懂，界面美觀，減少業務處理 錄入工作量。
[0080] (6)應用便攜 采集設備方便攜帶，具備抗撞擊、抗震動，抗陽光直射功能，并帶有觸控筆，攜帶方便， 操作簡易的功能，具備GPS定位功能，能測算救護車到醫院的距離以及時間。
【附圖說明】
[0081] 圖1為SIP協議所屬網絡協議的位置。
[0082] 圖2為SIP邏輯實體。
[0083]圖3為SIP層次關系。
[0084] 圖4為SIP消息分類。
[0085] 圖5為SIP消息格式。
[0086] 圖6為INVITE事務（三次握手），對于INVITE的成功響應，ACK不屬于INVITE事務， 而是單獨的事務。
[0087] 圖7為非INVITE事務(兩次握手）：對于非INVITE事務，一般不存在臨時響應，對于 最終響應的處理也是一樣。
[0088] 圖8為特殊事務:ACK和CANCEL事務。
[0089] 圖9位SIP對話。
[0090] 圖10為SIP消息注冊。
[0091] 圖11 SIP直接傳輸。
[0092] 圖12 SIP代理傳輸。
[0093]圖13 SIP重定向傳輸。
[0094]圖14 SIP重定向代理傳輸。
[0095]圖15為心電數據采集時序。
[0096]圖16為心電數據發送流程。
[0097]圖17為心電會診數據連接流程。
[0098]圖18為心電會診接收流程。
[0099]圖19為本發明系統部署圖示。
[0100]圖20為系統使用流程圖。
【具體實施方式】
[0101 ]產品生產線上的任何生產商均可部署此發明。
[0102] 通過建設心電網絡系統，在養老院/社區服務中心提供心電采集檢查，當病人檢測 的心電圖達到預警值時，或者在養老院/社區服務中心人員發生突發情況，系統提供智能向 120預警。120急救中心根據預警的養老院/社區獲取病人所在地址、基本信息，心電圖數據 等都發往120調度中心，可作為之后再救護車搶救及入院手術等電子信息，調度中心安排最 近的救護車前往救護，另外在120救護車上部署心電采集工作站，急救醫生可以在急救途中 通過心電采集平板采集心電圖數據，救護車心電采集設備與120醫療急救中心和醫院之間 進行心電及其他生命信息傳輸，建立心電信息存儲服務器，并在救護車上配備心電采集工 作站和平板用于心電采集與傳輸，在各大合作醫療機構急診科及心內科安裝心電會診工作 站。救護車上的醫生在病人家中或車內采集心電圖，利用3G/4G移動網絡，在第一時間實時 將采集心電數據傳送到急救醫生選擇的醫生工作站，如圖19。
[0103] 在養老院/社區服務中心/120救護車上將導聯連接好后，心電采集工作站(MIEC) 先與心電數據傳輸與控制模塊(MIESERVER)建立連接，MIESERVER創建直播間并加入直播間 列表，當開始采集心電時，在心電采集工作站(MIEC)可查看采集的心電圖形，系統通過SIP 傳輸協議將采集心電圖數據發送給心電數據傳輸與控制模塊(MIESERVER)，當MIESERVER收 到心電數據后將采集到的數據發送給直播間，醫生用戶使用醫生心電會診工作站(MIED)進 入直播間即可查看遠程采集的心電圖形，直到直播間關閉。同時心電數據傳輸與控制模塊 MIESERVER將采集的心電圖數據寫入數據庫，可供會診、查詢等使用，如圖20。
[0104] 本發明有效解決了現有技術中存在的使用HTTP協議所帶來的實時性差和帶寬資 源浪費嚴重的問題;與現有技術相比，采用本發明所述方法能達到真正快速、實時地將救護 車上采集的心電圖數據實時傳輸，實現遠程心電圖顯示、測量、診斷的目的，同時節約了網 絡帶寬資源。
[0105] 統一定義Web服務的接口可以使得數據的傳輸方式更加規范，從而利于更廣泛的 應用。同時Web服務支持高并發性，使得大規模產業鏈中的事件上傳效率得到保證。
【主權項】
1. 一種基于SIP傳輸協議的移動心電采集及診斷系統，其特征在于，包括:移動心電采 集工作站、心電數據傳輸與控制模塊、心電數據庫、心電信息管理系統、醫生心電會診工作 站，通過心電采集事件觸發集成整個業務過程，并將相關業務數據存儲至數據庫;其中： 所述移動心電采集工作站，使用心電采集設備和平板電腦，通過心電采集系統，用于養 老院、社區服務中心等采集心電圖，以及救護車現場急救人員采集心電圖，具有病人信息添 加、心電采集、存儲功能，并可將信息數據發送到心電數據庫、心電信息管理系統、醫生心電 會診工作站，還可查詢病人相關信息及歷史記錄； 所述心電數據傳輸與控制模塊，用于移動心電采集工作站、醫生心電會診工作站之間 的數據傳輸;該模塊主要使用SIP協議，用于移動心電采集工作站、心電會診工作站的數據 傳輸與控制，確保各個系統之間信息數據的傳遞；另外該模塊還負責將采集的心電數據存 儲至數據庫;該模塊有以下幾個子模塊，分別是：IOCPMode 1、RoomMgr、Room模塊；IOCPMode 1 是一種通訊模型，用于高效處理很多的客戶端進行數據交換，或能異步I/O操作;RoomMgr即 房間列表，用于存放已建立的房間列表;ROOM即房間，用于接收、查看心電圖心電直播間； 所述心電數據庫，用于存儲病人基本信息、心電圖數據、診斷報告、圖片，并為移動心電 采集工作站和醫生心電會診工作站提供數據對接，還有為心電信息管理系統提供統計、查 詢功能； 所述醫生心電會診工作站，用于接收來自各移動心電采集工作站采集的心電采集信 息，提供院內醫生查看心電圖信息，進行診斷，包括做出相應的測量、會診，撰寫診斷結論； 并將相關數據包括診斷結論存儲至心電數據庫； 所述心電信息管理系統，用于對醫院、醫生、病人的人員信息管理，具有系統使用權限、 心電圖查看、會診、撰寫診斷報告、統計分析報表、歷史記錄查詢及診斷報告打印功能;還提 供WEB服務，供全院相關醫生瀏覽各種心電檢查報告，實現遠程會診。2. 根據權利要求1所述的移動心電采集及診斷系統，其特征在于，所述移動心電采集工 作站還提供醫保卡刷卡服務，通過接口調用HIS系統獲取病人的基本資料;或者在系統中手 動輸入病人基本資料，既往病史等信息;通過心電采集盒采集心電數據，在移動設備上顯示 12導心電圖信號。3. 根據權利要求1所述的移動心電采集及診斷系統，其特征在于，所述的移動心電采集 工作站部署在養老院、社區服務中心、急救中心;所述心電會診工作站部署在醫院;在云平 臺，實現數據的傳輸，心電圖數據通過移動網絡將心電圖數據傳送至心電數據傳輸與控制 模塊，心電數據傳輸與控制模塊將獲取的數據寫至數據庫，并根據選擇將數據發送到選擇 的醫院，在醫院內部醫生登錄心電會診工作站，選擇直播間進入即實時查看到病人的心電 圖信息，醫生能對該心電圖信息及時作出診斷意見；另外在心電采集工作站可以查看歷史 的診斷信息。4. 根據權利要求1所述的移動心電采集及診斷系統，其特征在于，集成流程具體如下： (1) 移動設備包括平板和手機，通過藍牙或者USB的方式與心電采集設備連接，使用移 動心電米集工作站米集心電圖； (2) 移動設備通過USB的方式與心電采集設備連接，采集心電圖采用數字采集接口，從 心電采集設備中獲取心電數據； (3) 實時顯示心電采集設備采集來的心電數據；系統通過讀取、解析采集來的數據，在 移動設備上裝有心電采集工作站中可實時查看心電圖，并可實現3*4導聯、12*1導聯、2*6導 聯、2*6+1導聯、3*4+2導聯、1導聯、60秒導聯圖形切換顯示；系統可選擇將心電數據發送至 哪一家醫院，由該醫院給出心電診斷； (4) 心電數據傳輸 心電數據傳輸使用SIP協議傳輸數據，提供SIP注冊、直接傳輸、代理傳輸、重定向傳輸、 重定向代理傳輸幾種傳輸模式； 心電采集工作站通過傳輸模塊將采集的心電數據寫入數組，當滿足一定數量后通過 SIP協議將采集的數據通過SIP協議傳輸數據； 具體過程為:將連接信息發送給服務器，其包含消息頭:包含消息總長度、命令或響應 類型、命令執行狀態，消息主體:包括姓名、年齡、性別;服務器驗證正確性，進行連接，當連 接成功后，采集端的設備開始獲取藍牙采集盒發送過來的數組數據，調用繪圖工具進行波 形圖的繪制;在心電采集工作站顯示波形，與此同時為保證數據的正確性和及時性，將每次 采集的16個元素裝載到定制好的容器數組當中，當容器裝滿數據時，對其進行處理，添加消 息頭，消息的主體就是此容器中的數據，最后通過SIP傳輸協議將數據發送到服務器； (5) 服務器SIP協議模塊接收移動心電采集工作站SIP模塊傳輸的心電數據 服務器SIP模塊接收移動心電工作站傳輸過來的心電數據，主要分為兩類:請求消息和 響應消息，其中向心電會診工作站發送請求，向移動心電工作站發送響應消息； (6 )服務器對接收的心電圖數據進行解析 服務器對接收的心電圖數據拆包并進行解析； (7) 服務器SIP模塊將接收的心電圖數據轉發給心電會診工作站并將數據存儲至數據 庫 服務器對拆包解析的心電圖數據同步存儲至數據庫，另外當使用心電會診工作站時服 務器通過其SIP模塊將數據發送至心電會診工作站； (8) 心電會診工作站SIP模塊通過SIP協議接收服務器發送數據 醫生選擇需要查看的直播間即心電會診工作站SIP模塊開始接收心電數據； 數據接收的過程需要設置連接地址和指定的端口號:將信息發送給服務器，其包含:消 息頭:包含消息總長度、命令或響應類型、命令執行狀態，消息主體:用戶登陸ID、消息類型、 消息長度、消息內容;服務器接收消息后驗證正確性，驗證成功后再發送連接響應;會診端 接收連接響應后判斷消息頭部，如果該消息是連接消息，則連接成功，否則，連接失敗，下次 重新連接;連接成功后，會診端的設備開始接收心電采集工作站發送過來的數據，調用繪圖 工具進行波形圖的繪制，在頁面顯示波形;為保證數據的正確性和及時性，會診端每次接收 數據后判斷消息頭部，如果該消息為數據消息，則接收它，否則重新接收； (9) 心電會診工作站實時顯示移動心電采集的心電圖，醫生通過軟件進行查看、測量、 診斷操作。5.根據權利要求1-4之一所述的移動心電采集及診斷系統，其特征在于，所述心電采集 的流程為： (1) 采集客戶端(MIEC)向心電服務器(MIESERVER)發送邀請； (2) 心電服務器(MIESERVER)創建直播間； (3) 心電服務器(MIESERVER)返回成功消息給心電采集客戶端(MIEC); (4) 采集客戶端(MIEC)發送心電數據給心電服務器(MIESERVER); (5) 心電服務器(MIESERVER)將數據轉發至直播間； (6) 心電服務器(MIESERVER)向心電采集客戶端(MIEC)發送接收到數據響應； (7) 采集客戶端(MIEC)向心電服務器(MIESERVER)發送鏈接終止命令； (8) 心電服務器(MIESERVER)通知直播間心電采集客戶端(MIEC)退出； (9) 心電服務器(MIESERVER)向心電采集客戶端(MIEC)終止連接的應答。6. 根據權利要求1-4之一所述的移動心電采集及診斷系統，其特征在于，所述心電采集 發送的流程為： (1)心電采集客戶端(MIEC)向TCP的IOCPMODEL模塊發送接入邀請； (2 ) IOCPMODEL模塊查找RoomMgr (房間列表)該(MIEC)采集端是否創建直播間； (3 )當沒查找到房間，10CPM0DEL模塊向RoomMgr (房間列表)創建直播間記錄； (4) 創建直播間ROOM; (5) IOCPMODEL模塊為創建的直播間分配ROOM ID; (6) 當查找到房間則IOCPMODEL模塊分配現有的ROOM ID; (7) 采集客戶端(MIEC)向IOCPMODEL模塊發送數據； (8 ) 10CPM0DEL模塊在RoomMgr (房間列表)查找到直播間信息； (9)I0CPM0DEL模塊將從采集客戶端(MIEC)接收到的數據發送給直播間，直播間即可查 看到心電圖數據。7. 根據權利要求1-4之一所述的移動心電采集及診斷系統，其特征在于，心電會診連接 的流程為： (1) 會診客戶端(MIED)向心電服務器(MIESERVER)發送會話請求； (2) 經系統鑒權成功后，心電服務器(MIESERVER)將會診客戶端(MIED)加入選擇的直播 間； (3) 心電服務器(MIESERVER)向會診客戶端(MIED)返回成功消息； (4) 心電服務器(MIESERVER)向會診客戶端(MIED)發送數據，使會診客戶端(MIED)能看 見采集客戶端發來的心電數據； (5) 會診客戶端(MIED)向心電服務器(MIESERVER)發送接收數據響應； (6) 會診客戶端(MIED)向心電服務器(MIESERVER)發送鏈接終止命令； (7) 心電服務器(MIESERVER)通知直播間會診客戶端(MIED)退出； (8) 心電服務器(MIESERVER)向會診客戶端(MIED)終止連接的應答。8. 根據權利要求1-4之一所述的移動心電采集及診斷系統，其特征在于，心電會診接收 流程為： (1)會診客戶端(MIED)向TCP的IOCPMODEL模塊發送接入邀請； (2H0CPM0DEL模塊在RoomMgr查找房間； (3)加入房間； (4 )房間發送心電數據給10CPM0DEL模塊； (5 ) IOCPMODEL模塊將數據發送給會診客戶端(MIED ); (6 )R00M模塊發送終止連接，通知至IOCPMODEL模塊； (7 ) IOCPMODEL模塊將終止連接發送至會診客戶端(MIED )，數據接收終止。9. 根據權利要求4所述的移動心電采集及診斷系統，其特征在于，所述的SIP消息注冊， 是當用戶每次開機時，要向服務器注冊，當SIP Client的地址發生改變時需要重新注冊，注 冊信息必須定期刷新，通常Register將注冊信息保存到Location Server中，作用是將AOR 地址綁定到某個Contact地址上，便于Proxy在呼叫時查找被叫的地址;具體流程為： (1) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)發起注冊請求； (2) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回401，即該用戶無權限； (3) 戶代理客戶端(UAC)授權，再次向用戶代理服務器(UAS)發起注冊請求； (4) 用戶代理服務器(UAS)注冊成功向用戶代理服務器(UAC)返回200 0K消息。10. 根據權利要求4所述的移動心電采集及診斷系統，其特征在于，所述的直接傳輸，是 當主叫用戶代理客戶端(UAC)知道被叫的當前的位置時，通過INVITE消息直接向被叫用戶 代理服務器(UAS)發出呼叫請求;具體流程為： (1) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)發起INVITE請求； (2) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回100,即表示已經接收到請求消 息，正在對其進行處理； (3) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回200 0K消息； (4) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)返回ACK消息； (5) 用戶代理客戶端(UAC)和用戶代理服務器(UAS)之間數據傳輸。11. 根據權利要求4所述的移動心電采集及診斷系統，其特征在于，所述的代理傳輸，是 用戶客戶端向服務器端進行注冊前，所述服務器端根據各服務器運行情況，分配負荷 最小的一個可用SIP注冊服務器給所述用戶客戶端； 當主叫用戶代理客戶端(UAC)不知道被叫的當前的位置時，UAC通過網絡中間的服務器 設備的轉發，最終到達UAS;即用戶代理客戶端(UAC)可以向代理服務器(Proxy Server)發 起INVITE請求，再由代理服務器(Proxy Server)向用戶代理服務器(UAS)發出呼叫請求； 具體流程為： (1) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)發起INVITE請求； (2) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回100,即表示已經接收到 請求消息，正在對其進行處理； (3) 代理服務器(Proxy Server)向用戶代理服務器(UAS)發起INVITE請求； (4) 用戶代理服務器(UAS)向代理服務器(Proxy Server)返回200 0K消息； (5) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回200 0K消息； (6) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)返回ACK消息； (7) 代理服務器(Proxy Server)向用戶代理服務器(UAS)返回ACK消息； (8) 用戶代理客戶端(UAC)、代理服務器(Proxy Server)、用戶代理服務器(UAS)之間數 據傳輸。12. 根據權利要求4所述的移動心電采集及診斷系統，其特征在于，所述的重定向傳輸， 具體流程為： (1) 用戶代理客戶端(UAC)向重定向服務器(RedirectServer)發起INVITE請求； (2) 重定向服務器(RedirectServer)向用戶代理客戶端(UAC)返回301，即表示永久迀 移； (3) 用戶代理客戶端(UAC)向重定向服務器(1^(1;^6(^561^61〇返回40(消息； (4) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)發起INVITE請求； (5) 用戶代理服務器(UAS)向用戶代理客戶端(UAC)返回200 0K消息； (6) 用戶代理客戶端(UAC)向用戶代理服務器(UAS)返回ACK消息； (7) 用戶代理客戶端(UAC)和用戶代理服務器(UAS)之間數據傳輸。13.根據權利要求4所述的移動心電采集及診斷系統，其特征在于，所述的重定向代理 傳輸的具體流程為： (1) 用戶代理客戶端(UAC)向重定向服務器(RedirectServer)發起INVITE請求； (2) 重定向服務器(RedirectServer)向用戶代理客戶端(UAC)返回302，即表示臨時迀 移； (3) 用戶代理客戶端(UAC)向重定向服務器(RedirectServer )返回ACK消息； (4) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)發起INVITE請求； (5) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回100,即表示已經接收到 請求消息，正在對其進行處理； (6) 代理服務器(Proxy Server)向用戶代理服務器(UAS)發起INVITE請求； (7) 用戶代理服務器(UAS)向代理服務器(Proxy Server)返回200 0K消息； (8) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回200 0K消息； (9) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)返回ACK消息； (10) 用戶代理客戶端(UAC)、代理服務器(Proxy Server)、用戶代理服務器(UAS)之間 數據傳輸； (11) 用戶代理服務器(UAS)向代理服務器(Proxy Server)發送BYE消息； (12) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)發送BYE消息； (13) 用戶代理客戶端(UAC)向代理服務器(Proxy Server)返回200消息； (14) 代理服務器(Proxy Server)向用戶代理客戶端(UAC)返回200 0K消息。
【文檔編號】H04L29/06GK106027566SQ201610547775
【公開日】2016年10月12日
【申請日】2016年7月13日
【發明人】周蒨
【申請人】上海數創醫療科技有限公司