本發(fā)明涉及通信技術(shù)，尤其涉及一種同時支持TLS短連接和長連接的處理方法和系統(tǒng)及設(shè)備。

背景技術(shù)：
目前，在大多數(shù)基于網(wǎng)絡(luò)之間互連的協(xié)議(InternetProtocol；簡稱：IP)網(wǎng)絡(luò)承載的語音或視頻(Voice/VideooverIP；簡稱：VoIP)系統(tǒng)中，各個終端在支持傳輸層安全(TransportLayerSecurity；簡稱：TLS)的連接方式上不同，有的廠商支持TLS短連接的方式，有的廠商支持TLS長連接的方式。其中，所謂TLS短連接，是指只有在被叫終端與基于IP網(wǎng)絡(luò)承載的專用交換機(IPPrivateBranchExchange；簡稱：IPPBX)之間有實際的會話發(fā)起協(xié)議(SessionInitiationProtocol；簡稱：SIP)消息需要傳輸時，IPPBX才與該被叫終端建立傳輸控制協(xié)議(TransmissionControlProtocol；簡稱：TCP)連接，恢復(fù)TLS會話。當(dāng)業(yè)務(wù)交互(例如注冊操作或者呼叫等)完畢后，則釋放與該被叫終端的TCP連接，保持TLS會話參數(shù)。所謂TLS長連接，是指呼叫終端和被叫終端在注冊階段就已經(jīng)和IPPBX建立起TLS通道，此后一直保持連接，直至呼叫終端和被叫終端注銷的時候方拆除呼叫。但是，當(dāng)IPPBX只支持TLS短連接模式的終端時，如果被叫終端只支持TLS長連接模式，且當(dāng)完成注冊或者會話后，經(jīng)過一段時間，IPPBX發(fā)現(xiàn)與被叫終端之間無新的消息后，會主動斷開與該被叫終端的TCP和TLS通道。當(dāng)被叫終端發(fā)現(xiàn)連接斷開一定時間后，會主動與IPPBX再進行連接，從而使得IPPBX與被叫終端之間發(fā)生頻繁的建立拆除TCP和TLS通道的情況，進而造成資源浪費。當(dāng)IPPBX只支持TLS長連接模式的終端時，IPPBX需要大量占用TCP資源，另外，如果被叫終端只支持TLS短連接模式，則會主動斷開與IPPBX之間的連接，而IPPBX只是作為TCPServer，即不會主動連接被叫終端，則會導(dǎo)致呼叫失敗。

技術(shù)實現(xiàn)要素：
本發(fā)明提供一種同時支持TLS短連接和長連接的處理方法和系統(tǒng)及設(shè)備，用于IPPBX可以兼容支持TLS短連接模式的終端和支持TLS長連接模式的終端。本發(fā)明的第一個方面是提供一種同時支持TLS短連接和長連接的處理方法，包括：IPPBX通過第一TLS通道接收第一終端發(fā)送的攜帶有第二終端標識的呼叫請求，所述第一TLS通道為所述IPPBX與所述第一終端之間建立的TLS通道；所述IPPBX在判斷出與所述第二終端標識對應(yīng)的第二終端之間建立了第二TLS通道，則將所述呼叫請求通過所述第二TLS通道發(fā)送給所述第二終端。本發(fā)明的另一個方面是提供一種IPPBX，包括：第一TLS通道建立模塊，用于與第一終端之間建立第一TLS通道；接收模塊，用于通過所述第一TLS通道建立模塊建立的所述第一TLS通道發(fā)送攜帶有第二終端標識的呼叫請求；判斷模塊，用于判斷第二TLS通道建立模塊是否建立了與第二終端標識對應(yīng)的第二終端之間的第二TLS通道；發(fā)送模塊，用于所述判斷模塊判斷出所述第二TLS通道建立模塊建立的所述第二TLS通道，則將所述呼叫請求通過所述第二TLS通道發(fā)送給所述第二終端。本發(fā)明的又一個方面是提供一種同時支持TLS短連接和長連接的處理系統(tǒng)，包括第一終端、第二終端和上述所述的IPPBX。本發(fā)明的技術(shù)效果是：通過IPPBX在判斷出與該第二終端之間建立了第二TLS通道時，采用該第二TLS通道，將第一終端發(fā)起的呼叫請求發(fā)送給第二終端，從而完成第一終端和第二終端的呼叫建立。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。附圖說明圖1為本發(fā)明同時支持TLS短連接和長連接的處理方法的一個實施例的流程圖；圖2為本發(fā)明同時支持TLS短連接和長連接的處理方法的另一個實施例的流程圖；圖3為本發(fā)明支持TLS短連接和長連接的處理方法的又一個實施例的信令流程圖；圖4為本發(fā)明支持TLS短連接和長連接的處理方法的還一個實施例的信令流程圖；圖5為本發(fā)明IPPBX的一個實施例的結(jié)構(gòu)示意圖；圖6為本發(fā)明IPPBX的又一個實施例的結(jié)構(gòu)示意圖；圖7為本發(fā)明同時支持TLS短連接和長連接的處理系統(tǒng)的一個實施例的結(jié)構(gòu)示意圖。具體實施方式在本發(fā)明的各個實施例中，安全套接層(SecureSocketsLayer；簡稱：SSL)是傳輸層的一種安全協(xié)議。具體的，SSL協(xié)議提供了兩臺計算機之間的安全連接，對整個會話進行了加密，從而保證了安全傳輸。其中，該SSL協(xié)議提供的安全連接具有以下三個基本特點：1、連接是保密的：對于每個連接都有一個唯一的會話密鑰，采用對稱密碼體制(例如：數(shù)據(jù)加密算法(DataEncryptionAlgorithm；簡稱：DES)或者RC4(RivestCipher4)等)來加密數(shù)據(jù)；2、連接是可靠的：消息的傳輸采用消息鑒別碼(MessageAuthenticationCode；簡稱：MAC)算法(例如：消息摘要算法第5版(MessageDigestAlgorithm5；簡稱：MD5)或者安全散列算法(SecureHashAlgorithm；簡稱：SHA)等)進行完整性檢驗；3、對端實體的鑒別采用非對稱密碼體制(例如：RSA(Revist-Shamir-Adleman)或者數(shù)字簽名算法(DigitalSignatureAlgorithm；簡稱：DSA)等)進行認證。SSL協(xié)議建立在可靠的TCP傳輸控制協(xié)議之上，并與上層協(xié)議無關(guān)，各種應(yīng)用層協(xié)議(例如：超文本傳送協(xié)議(HypertextTransportProtocol；簡稱：HTTP)、文件傳輸協(xié)議(FileTransferProtocol；簡稱：FTP)、遠程登錄(TELNET)等)能通過SSL協(xié)議進行透明傳輸。另外，TLS是1999年推出的對SSL的改進版本，其主要區(qū)別是所支持的加密算法不同，但是一般不明確區(qū)分的情況下，業(yè)界普遍將SSL和TLS統(tǒng)稱為SSL。圖1為本發(fā)明同時支持TLS短連接和長連接的處理方法的一個實施例的流程圖，如圖1所示，本實施例的方法包括：步驟101、IPPBX通過第一TLS通道接收第一終端發(fā)送的攜帶有第二終端標識的呼叫請求，該第一TLS通道為所述IPPBX與所述第一終端之間建立的TLS通道。在本實施例中，當(dāng)?shù)谝唤K端為支持TLS長連接的終端，且第二終端為支持TLS短連接的終端時，第一終端在發(fā)起注冊前，先與IPPBX建立第一TCP連接以及第一TLS通道，并在完成注冊后，第一終端不會主動拆除該第一TLS通道和第一TCP連接，IPPBX也不會主動拆除該第一TLS通道和第一TCP連接；第二終端在發(fā)起注冊前，也先與IPPBX建立第二TCP連接以及第二TLS通道，并在完成注冊后，拆除該第二TLS通道和第二TCP連接。當(dāng)?shù)谝唤K端為支持TLS短連接的終端、且第二終端為支持TLS長連接的終端，第一終端在發(fā)起注冊前，先與IPPBX建立第一TCP連接以及第一TLS通道，并在完成注冊后，拆除該第一TLS通道和第一TCP連接。第二終端在發(fā)起注冊前，也先與IPPBX建立第二TCP連接以及第二TLS通道，并在完成注冊后，第二終端不拆除該第二TCP連接和第二TLS通道。且IPPBX不會主動向第二終端發(fā)起拆除第二TCP連接和第二TLS通道。當(dāng)?shù)谝唤K端向第二終端發(fā)起呼叫時，如果該第一終端為支持TLS長連接的終端，則根據(jù)之前建立的第一TLS通道，向IPPBX發(fā)起攜帶有第二終端標識的呼叫請求。如果該第一終端為支持TLS短連接的終端，第一終端先建立與IPPBX之間的第一TCP連接和第一TLS通道，然后通過該第一TLS通道，向IPPBX發(fā)起攜帶有第二終端標識的呼叫請求。步驟102、IPPBX在判斷出與該第二終端標識對應(yīng)的第二終端之間建立了第二TLS通道，則將該呼叫請求通過第二TLS通道發(fā)送給第二終端。在本實施例中，由于第二終端為支持長連接模式的終端，因此，在第二終端向IPPBX注冊完成后，不會主動拆除該第二TLS通道和第二TCP連接，且IPPBX也不會主動拆除該第二TLS通道和第二TCP連接，因此，當(dāng)IPPBX接收到第一終端發(fā)起的呼叫請求后，IPPBX可以通過先前與該第二終端之間建立的第二TLS通道，向第二終端發(fā)起呼叫請求。在本實施例中，通過IPPBX在判斷出與該第二終端之間建立了第二TLS通道時，采用該第二TLS通道，將第一終端發(fā)起的呼叫請求發(fā)送給第二終端，從而完成第一終端和第二終端的呼叫建立。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。圖2為本發(fā)明同時支持TLS短連接和長連接的處理方法的另一個實施例的流程圖，如圖2所示，本實施例的方法包括：步驟201、IPPBX通過第一TLS通道接收第一終端發(fā)送的攜帶有第二終端標識的呼叫請求，該第一TLS通道為該IPPBX與該第一終端之間建立的TLS通道。步驟202、IPPBX判斷是否與該第二終端標識對應(yīng)的第二終端之間建立了第二TLS通道，若是，則執(zhí)行步驟203；若否，則執(zhí)行步驟205、步驟203、IPPBX將該呼叫請求通過所述第二TLS通道發(fā)送給所述第二終端。步驟204、IPPBX根據(jù)接收到的該第二終端發(fā)起的注銷請求、釋放第二TLS通道請求和釋放第二TCP連接請求，釋放該第二TLS通道和第二TCP連接。結(jié)束。在本實施例中，當(dāng)?shù)谝唤K端為支持TLS短連接模式的終端，且第二終端為支持TLS長連接模式的終端時，由于第二終端為支持長連接模式的終端，因此，在第二終端向IPPBX注冊完成后，不會主動拆除該第二TLS通道和第二TCP連接，且IPPBX也不會主動拆除該第二TLS通道和第二TCP連接，因此，當(dāng)IPPBX接收到第一終端發(fā)起的呼叫請求后，IPPBX可以通過先前與該第二終端之間建立的第二TLS通道，向第二終端發(fā)起呼叫請求。另外，在第一終端發(fā)送拆除會話請求后，由于第一終端為支持TLS短連接模式的終端，因此過一段時間后，會主動拆除與IPPBX之間的第一TLS通道和第一TCP連接。而由于第二終端為支持長連接模式的終端，在IPPBX向第二終端轉(zhuǎn)發(fā)第一終端發(fā)送的拆除會話請求后，不會主動拆除該第二TLS通道和第二TCP連接，且IPPBX也不會主動拆除該第二TLS通道和第二TCP連接，直至第二終端發(fā)起注銷請求、釋放第二TLS通道請求和釋放第二TCP連接請求后，才會釋放該第二TLS通道和第二TCP連接。步驟205、IPPBX向第二終端標識對應(yīng)的第二終端發(fā)起TCP連接請求，并與該第二終端之間建立第二TCP連接。步驟206、IPPBX接收該第二終端發(fā)送的TLS通道請求，并與該第二終端之間建立該第二TLS通道。步驟207、IPPBX將該呼叫請求通過所述第二TLS通道發(fā)送給所述第二終端。步驟208、IPPBX根據(jù)接收到的該第一終端發(fā)起的注銷請求、釋放第一TLS通道請求和釋放第一TCP連接請求，釋放該第一TLS通道和第一TCP連接。結(jié)束。在本實施例中，當(dāng)?shù)谝唤K端為支持TLS長連接模式的終端，且第二終端為支持TLS短連接模式的終端時，由于第二終端為支持短連接模式的終端，因此，在第二終端向IPPBX注冊完成后，會主動拆除該第二TLS通道和第二TCP連接，因此，當(dāng)IPPBX接收到第一終端發(fā)起的呼叫請求后，IPPBX向第二終端標識對應(yīng)的第二終端發(fā)起TCP連接請求，并與該第二終端之間建立第二TCP連接，從而等待第二終端發(fā)起TLS通道請求，由于該第二終端為支持TLS短連接模式的終端，因此，在第二終端接收到TCP連接請求，并完成第二TCP連接的建立后，會主動向IPPBX發(fā)起TLS通道請求，從而使得該IPPBX接收該第二終端發(fā)送的TLS通道請求，并與該第二終端之間建立該第二TLS通道，最后通過該第二TLS通道發(fā)起該呼叫請求。另外，在第一終端發(fā)送拆除會話請求后，由于第一終端為支持TLS長連接模式的終端，因此過一段時間后，不會主動拆除與IPPBX之間的第一TLS通道和第一TCP連接，且IPPBX也不會主動拆除該第一TLS通道和第一TCP連接。直至第一終端發(fā)起注銷請求、釋放第一TLS通道請求和釋放第一TCP連接請求后，才會釋放該第一TLS通道和第一TCP連接。而由于第二終端為支持TLS短連接模式的終端，在IPPBX向第二終端轉(zhuǎn)發(fā)第一終端發(fā)送的拆除會話請求后，會主動拆除該第二TLS通道和第二TCP連接。在本實施例中，當(dāng)IPPBX在判斷出與該第二終端之間建立了第二TLS通道時，采用該第二TLS通道，將第一終端發(fā)起的呼叫請求發(fā)送給第二終端，從而完成第一終端和第二終端的呼叫建立；當(dāng)IPPBX在判斷出與該第二終端之間沒有建立第二TLS通道時，在向第二終端發(fā)起TCP連接請求，并與該第二終端建立第二TCP連接，并等待第二終端發(fā)起TLS通道請求，最后在接收到TLS通道請求后，與該第二終端建立第二TLS通道，并發(fā)送呼叫請求。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。圖3為本發(fā)明支持TLS短連接和長連接的處理方法的又一個實施例的信令流程圖，在本實施例中，以第一終端為支持TLS短連接模式的終端，第二終端為支持TLS長連接模式的終端為例，詳細介紹本實施例的技術(shù)方案，如圖3所示，本實施例的方法包括：步驟301、第一終端與IPPBX建立第一TCP連接。步驟302、第一終端與IPPBX建立第一TLS通道。步驟303、第一終端采用該第一TLS通道向IPPBX發(fā)起注冊。步驟304、第一終端在完成注冊后，拆除第一TLS通道。步驟305、第一終端拆除第一TCP連接。步驟306、第二終端與IPPBX建立第二TCP連接.步驟307、第二終端與IPPBX建立第二TLS通道。步驟308、第二終端采用該第二TLS通道發(fā)起注冊。步驟309、第一終端與IPPBX建立第一TCP連接.步驟310、第一終端與IPPBX建立第一TLS通道。步驟311、第一終端向IPPBX發(fā)起呼叫請求。步驟312、IPPBX通過該第二TLS通道向第二終端發(fā)起該呼叫請求。步驟313、第一終端向IPPBX發(fā)起拆除會話請求。步驟314、第一終端拆除與IPPBX之間建立的第一TLS通道。步驟315、第一終端拆除與IPPBX之間建立的第一TCP連接。在本實施例中，由于第一終端為支持TLS短連接模式的終端，因此當(dāng)?shù)谝唤K端完成會話建立或者會話拆除后，過一段時間后會主動拆除與IPPBX之間建立的第一TCP連接和第一TLS通道。步驟316、IPPBX向該第二終端發(fā)起拆除會話請求。步驟317、第二終端向IPPBX發(fā)起注銷請求.步驟318、第二終端拆除與IPPBX之間建立的第二TLS通道。步驟319、第二終端拆除與IPPBX之間建立的第二TCP連接。在本實施例中，當(dāng)?shù)谝唤K端完成會話建立或者會話拆除后，即使經(jīng)過一段時間，IPPBX發(fā)現(xiàn)與第二終端之間無新的消息，IPPBX始終不會主動拆除與第二終端之間的第二TCP連接和第二TLS通道。直至第二終端發(fā)起注銷請求，并拆除與IPPBX之間建立的該第二TCP連接和第二TLS通道。在本實施例中，IPPBX在判斷出與該第二終端之間建立了第二TLS通道時，采用該第二TLS通道，將第一終端發(fā)起的呼叫請求發(fā)送給第二終端，從而完成第一終端和第二終端的呼叫建立。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。圖4為本發(fā)明支持TLS短連接和長連接的處理方法的還一個實施例的信令流程圖，在本實施例中，以第一終端為支持TLS長連接模式的終端，第二終端為支持TLS短連接模式的終端為例，詳細介紹本實施例的技術(shù)方案，如圖4所示，本實施例的方法包括：步驟401、第一終端與IPPBX建立第一TCP連接。步驟402、第一終端與IPPBX建立第一TLS通道。步驟403、第一終端采用第一TLS通道發(fā)起注冊。步驟404、第二終端與IPPBX建立第二TCP連接.步驟405、第二終端與IPPBX建立第二TLS通道。步驟406、第二終端采用該第二TLS通道發(fā)起注冊。步驟407、第二終端在完成注冊后，拆除該第二TLS通道。步驟408、第二終端拆除該第二TCP連接。步驟409、第一終端通過第一TLS通道向IPPBX發(fā)起呼叫請求。步驟410、IPPBX向第二終端發(fā)起TCP連接，并與該第二終端之間建立第二TCP連接。在本實施例中，當(dāng)?shù)谝唤K端呼叫第二終端時，第一終端可以根據(jù)前期建立的第一TLS通道發(fā)起呼叫請求，IPPBX向第二終端發(fā)起該呼叫請求之前，發(fā)現(xiàn)沒有與第二終端之間建立該第二TLS通道，則向第二終端發(fā)起TCP連接請求，并在與第二終端之間建立的第二TLS通道之后，等待第二終端發(fā)起TLS通道請求。步驟411、IPPBX接收第二終端發(fā)送的TLS通道請求，并與該第二終端之間建立第二TLS通道。在本實施例中，由于第二終端與IPPBX之間建立了第二TCP連接，且由于第二終端為支持TLS短連接模式的終端，因此，會主動向IPPBX發(fā)起TLS通道請求。步驟412、IPPBX通過該第二TLS通道向第二終端發(fā)起該呼叫請求。步驟413、第一終端向IPPBX發(fā)起拆除會話請求。步驟414、IPPBX向該第二終端發(fā)起拆除會話請求。步驟415、第二終端拆除與IPPBX之間建立的第二TLS通道。步驟416、第二終端拆除與IPPBX之間建立的第二TCP連接。在本實施例中，由于第二終端為支持TLS短連接模式的終端，因此當(dāng)?shù)诙K端完成會話建立或者會話拆除后，過一段時間后會主動拆除與IPPBX之間建立的第二TCP連接和第二TLS通道。步驟417、第一終端向IPPBX發(fā)起注銷請求.步驟418、第一終端拆除與IPPBX之間建立的第一TLS通道。步驟419、第一終端拆除與IPPBX之間建立的第一TCP連接。在本實施例中，由于第一終端為支持TLS長連接模式的終端，因此當(dāng)?shù)谝唤K端完成會話建立或者會話拆除后，始終也不會拆除與IPPBX之間建立的第一TCP連接和第一TLS通道，另外，IPPBX也始終不會拆除與第一終端之間的第一TCP連接和第一TLS通道，直至第一終端向IPPBX發(fā)起注銷請求時，才會拆除與IPPBX之間的第一TCP連接和第一TLS通道。在本實施例中，當(dāng)IPPBX在判斷出與該第二終端之間沒有建立第二TLS通道時，在向第二終端發(fā)起TCP連接請求，并與該第二終端建立第二TCP連接，并等待第二終端發(fā)起TLS通道請求，最后在接收到TLS通道請求后，與該第二終端建立第二TLS通道，并發(fā)送呼叫請求。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。圖5為本發(fā)明IPPBX的一個實施例的結(jié)構(gòu)示意圖，在本實施例中，以第一終端為支持TLS短連接模式的終端，且第二終端為支持TLS長連接模式的終端為例，詳細介紹本實施例的技術(shù)方案，如圖5所示，本實施例的IPPBX包括：第一TLS通道建立模塊11、第二TLS通道建立模塊12、接收模塊13、判斷模塊14和發(fā)送模塊15，其中，第一TLS通道建立模塊11用于與第一終端之間建立第一TLS通道；接收模塊13用于通過所述第一TLS通道建立模塊11建立的該第一TLS通道發(fā)送攜帶有第二終端標識的呼叫請求；判斷模塊14用于判斷第二TLS通道建立模塊12是否建立了與第二終端標識對應(yīng)的第二終端之間的第二TLS通道；發(fā)送模塊15用于該判斷模塊14判斷出該第二TLS通道建立模塊建立的該第二TLS通道，則將該呼叫請求通過該第二TLS通道發(fā)送給所述第二終端。本實施例的IPPBX可以執(zhí)行圖1所示方法實施例的技術(shù)方案，其實現(xiàn)原理相類似，此處不再贅述。在本實施例中，通過IPPBX在判斷出與該第二終端之間建立了第二TLS通道時，采用該第二TLS通道，將第一終端發(fā)起的呼叫請求發(fā)送給第二終端，從而完成第一終端和第二終端的呼叫建立。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。進一步的，在本發(fā)明的另一個實施例中，在上述圖5所示實施例的基礎(chǔ)上，當(dāng)?shù)谝唤K端完成會話建立或者會話拆除后，該接收模塊13還用于接收第二終端發(fā)起的注銷請求，釋放第二TLS通道請求和釋放第二TCP連接請求，則第二TLS通道建立模塊12還用于釋放該第二TLS通道，且該IPPBX還包括：第二TCP連接建立模塊用于釋放第二TCP連接。優(yōu)選地，在第二終端完成注冊前，該第二TCP連接建立模塊還用于在接收模塊13接收到第二終端發(fā)起的TCP連接請求后，與該第二終端之間建立第二TCP連接，且第二TLS通道建立模塊12用于在接收模塊13接收到第二終端發(fā)起的TLS通道請求后，與該第二終端之間建立該第二TLS通道。需要說明的是，由于該第二終端為支持TLS長連接模式的終端，因此，第二終端不會主動拆除該第二TLS通道和第二TCP連接，且IPPBX也不會主動拆除該第二TLS通道和第二TCP連接。本實施例的IPPBX可以執(zhí)行圖3所示方法實施例的技術(shù)方案，其實現(xiàn)原理相類似，此處不再贅述。在本實施例中，IPPBX在判斷出與該第二終端之間建立了第二TLS通道時，采用該第二TLS通道，將第一終端發(fā)起的呼叫請求發(fā)送給第二終端，從而完成第一終端和第二終端的呼叫建立。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。圖6為本發(fā)明IPPBX的又一個實施例的結(jié)構(gòu)示意圖，在本實施例中，以第一終端為支持TLS長連接模式的終端，且第二終端為支持TLS短連接模式的終端為例，詳細介紹本實施例的技術(shù)方案，如圖6所示，本實施例的IPPBX包括：第一TLS通道建立模塊21、第二TLS通道建立模塊22、接收模塊23、判斷模塊24、第二TCP連接建立模塊25和發(fā)送模塊26，其中，第一TLS通道建立模塊21用于與第一終端之間建立第一TLS通道；接收模塊23用于通過所述第一TLS通道建立模塊11建立的該第一TLS通道發(fā)送攜帶有第二終端標識的呼叫請求；判斷模塊24用于判斷第二TLS通道建立模塊22是否建立了與第二終端標識對應(yīng)的第二終端之間的第二TLS通道；第二TCP連接建立模塊25用于在判斷模塊24判斷出該第二TLS通道建立模塊沒有建立該第二TLS通道，則向該第二終端發(fā)起TCP連接請求，并與該第二終端之間建立；第二TLS通道建立模塊22用于在接收模塊23接收到第二終端發(fā)送的TLS通道請求后，與該第二終端之間建立第二TLS通道；發(fā)送模塊26用于將該呼叫請求通過該第二TLS通道發(fā)送給該第二終端。本實施例的IPPBX可以執(zhí)行圖2所示方法實施例的技術(shù)方案，其實現(xiàn)原理相類似，此處不再贅述。在本實施例中，當(dāng)IPPBX在判斷出與該第二終端之間沒有建立第二TLS通道時，在向第二終端發(fā)起TCP連接請求，并與該第二終端建立第二TCP連接，并等待第二終端發(fā)起TLS通道請求，最后在接收到TLS通道請求后，與該第二終端建立第二TLS通道，并發(fā)送呼叫請求。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。進一步的，在本發(fā)明的還一個實施例中，在上述圖6所示實施例的基礎(chǔ)上，當(dāng)?shù)谝唤K端完成會話建立或者會話拆除后，接收模塊23還用于接收第一終端發(fā)起的注銷請求、釋放第一TLS通道請求和釋放第一TCP連接請求，則第一TLS通道建立模塊21還用于釋放第一TLS通道；則該IPPBX還包括：第一TCP連接建立模塊，用于釋放第一TCP連接。本實施例的IPPBX可以執(zhí)行圖4所示方法實施例的技術(shù)方案，其實現(xiàn)原理相類似，此處不再贅述。在本實施例中，當(dāng)IPPBX在判斷出與該第二終端之間沒有建立第二TLS通道時，在向第二終端發(fā)起TCP連接請求，并與該第二終端建立第二TCP連接，并等待第二終端發(fā)起TLS通道請求，最后在接收到TLS通道請求后，與該第二終端建立第二TLS通道，并發(fā)送呼叫請求。另外，由于IPPBX始終只作為TLS的服務(wù)端，并對終端所支持的模式無感知，即不知道終端是支持TLS長連接模式的終端還是支持TLS短連接模式的終端，只是被動的接受終端的連接，但從不主動的斷開與終端間的TLS通道，因此，有效地實現(xiàn)了IPPBX同時支持TLS短連接模式的終端和TLS長連接模式的終端，且不會造成IPPBX內(nèi)部層或模塊間的耦合。圖7為本發(fā)明同時支持TLS短連接和長連接的處理系統(tǒng)的一個實施例的結(jié)構(gòu)示意圖，如圖7所示，該系統(tǒng)包括：第一終端31、第二終端32和IPPBX33，其中，該IPPBX33可以執(zhí)行圖1至圖4任一所示方法實施例的基礎(chǔ)方案，其實現(xiàn)原理相類似，此處不再贅述。另外，該第一終端31可以為支持TLS短連接模式的終端，第二終端32為支持TLS長連接模式的終端；或者，第一終端31可以為支持TLS長連接模式的終端，第二終端32為支持TLS短連接模式的終端。本領(lǐng)域普通技術(shù)人員可以理解：實現(xiàn)上述各方法實施例的全部或部分步驟可以通過程序指令相關(guān)的硬件來完成。前述的程序可以存儲于一計算機可讀取存儲介質(zhì)中。該程序在執(zhí)行時，執(zhí)行包括上述各方法實施例的步驟；而前述的存儲介質(zhì)包括：ROM、RAM、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。最后應(yīng)說明的是：以上各實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制；盡管參照前述各實施例對本發(fā)明進行了詳細的說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解：其依然可以對前述各實施例所記載的技術(shù)方案進行修改，或者對其中部分或者全部技術(shù)特征進行等同替換；而這些修改或者替換，并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的范圍。