專利名稱：一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法
技術(shù)領域：
本發(fā)明涉及一種用IP傳送話音(VoIP)的方法，尤其是一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法。
背景技術(shù)：
傳統(tǒng)的電話技術(shù)使用電路交換傳輸話音，但隨著Internet的普及，應用因特網(wǎng)協(xié)議(IP，Internet Protocol)進行話音業(yè)務傳輸?shù)腣oIP(Voice over IP)技術(shù)近年來得到迅速發(fā)展，并且VoIP的含義和設計目標也超越了其字面意義，也就是說VoIP技術(shù)不僅指提供雙方會話的傳統(tǒng)電話技術(shù)，而且是包含話音、活動圖像數(shù)據(jù)、支持各種智能業(yè)務的雙方及多方多媒體通信技術(shù)。
IP是基于數(shù)據(jù)分組傳輸?shù)穆酚蓞f(xié)議，位于IP協(xié)議族的第三層，在IP之上有兩種可以選擇的協(xié)議傳輸控制協(xié)議(TCP，Transmission Control Protocol)和用戶數(shù)據(jù)報協(xié)議(UDP，UserDatagram Protocol)。TCP協(xié)議保證數(shù)據(jù)分組的可靠、無差錯傳輸。當多個分組被同時傳送時，TCP協(xié)議保證所有的分組都能到達目的地，并且以正確的次序提交給上層的應用程序。UDP協(xié)議是一個相對簡單的協(xié)議，主要針對一次性的事務處理或?qū)崟r性要求較高的事務，它并不提供順序和重傳機制。在TCP協(xié)議和UDP協(xié)議之上，存在許多不同的應用和服務，這些應用和服務的本身決定了是使用TCP協(xié)議還是使用UDP協(xié)議。
UDP無法做到避免分組丟失和確保分組有序傳輸，而運行在UDP之上的實時傳輸協(xié)議(RTP，Real-Time Transport Protocol)和實時傳輸控制協(xié)議(RTCP，Real-Time transport ControlProtocol)幫助實現(xiàn)了這些功能。圖1是RTP的報頭格式，其中V代表2bit的版本域，P代表1bit的填充域，X代表1bit的擴展域，CC代表4bit的有用源(CSRC，Contributing Source)計數(shù)域，M代表1bit的標志位，PT代表7bit的凈荷類型域，隨后是16bit的序列號域、32bit的時間戳域、32bit的同步源(SSRC，Synchronization Source)標識域、32bit的有用源(CSRC)標識域。RTP協(xié)議提供具有實時特征的、端到端的數(shù)據(jù)傳輸業(yè)務，可以用來傳送聲音和活動圖像數(shù)據(jù)。通常RTP的協(xié)議數(shù)據(jù)單元是用UDP分組來承載的。而且為了盡量減少時延，話音凈荷通常都很短。與RTP相配套的另一個協(xié)議是RTCP協(xié)議。RTCP是RTP的控制協(xié)議，它用于監(jiān)視業(yè)務質(zhì)量并與正在進行的會話者傳送信息。當一個RTP會話打開時，一個RTCP會話頁被隱性的打開。換句話說，當一個UDP端口號被分配給一個RTP會話用來傳遞媒體分組時，一個獨立的端口號被分配給RTCP信息。一個RTP分組的UDP端口號一般是偶數(shù)，相應的RTCP分組的UDP端口號將是相鄰的下一個奇數(shù)。RTP和RTCP可以使用介于1024和65535之間的任何UDP端口對，但是在端口號沒有被顯式分配的情況下，端口5004和5005將分配作為缺省端口。
Internet網(wǎng)絡包含計算機和路由器，在Internet網(wǎng)中傳輸?shù)臄?shù)據(jù)分組穿過一個路由器(router)被認為是一跳(hop)，即一跳表示數(shù)據(jù)分組在一個由互聯(lián)網(wǎng)段或其子網(wǎng)組成的網(wǎng)中通過一個路由器的傳輸。目前VoIP技術(shù)中是通過信令協(xié)商和資源預留協(xié)議(RSVP，Resource-Reservation Protocol)來保證實時業(yè)務在Internet網(wǎng)絡中的傳輸?shù)摹?br> 信令協(xié)商是指通信雙方在通信之前要通過控制信令建立連接。首先，發(fā)送方通過服務器尋找接收方，即尋找接收方的IP地址，然后，發(fā)送方與接收方協(xié)商參數(shù)并建立連接。協(xié)商后發(fā)送方可以得知接收方的端口號和業(yè)務類型。
RSVP是一個信令協(xié)議，它提供了一種在信息傳輸之前，提前在IP網(wǎng)絡中建立一個有帶寬資源保障的通道的方法。傳統(tǒng)上IP路由器只負責分組轉(zhuǎn)發(fā)，通過路由協(xié)議知道鄰近下一跳路由器的地址。而RSVP則類似于電路交換系統(tǒng)的信令協(xié)議一樣，為一個數(shù)據(jù)分組通知其所經(jīng)過的每個節(jié)點(IP路由器)，與端點協(xié)商為此數(shù)據(jù)分組提供質(zhì)量保證。其基本原理如圖2所示·發(fā)送端向接收端發(fā)送一個PATH消息，該消息中包含了業(yè)務標識(即目的地址)及其業(yè)務特征，業(yè)務特征包括所需要的帶寬的上下限，延遲以及延遲抖動等。如圖1中1所示。
·該消息由沿路徑的路由器逐跳(hop by hop)傳送，并且每個路由器都被告知準備預留資源，從而建立一個“路徑狀態(tài)”信息表，該信息表包含PATH消息中的前一跳源地址。如圖1中2、3所示。
·接收方收到此消息后從業(yè)務特征和所要求的QoS計算出所需要的資源，向其上游節(jié)點發(fā)送一個資源預留請求(RESV)消息，該消息中主要包含的參數(shù)就是要求預留的帶寬。如圖1中4所示。
·RESV消息是沿PATH的發(fā)送路徑原路返回的，沿途的路由器收到RESV消息后，調(diào)用自己的接入控制程序以決定是否接受該業(yè)務，如果接受，則按要求為業(yè)務分配帶寬和緩存空間，并記錄該業(yè)務狀態(tài)信息，然后將RESV消息繼續(xù)向上游轉(zhuǎn)發(fā)；如果拒絕，則向接收端返回一個錯誤信息給接收端以終止呼叫。如圖1中5所示。
·當最后的路由器收到RESV消息并且接受該請求時，它向接收端發(fā)回一個確認消息。如圖1中6所示。
RSVP協(xié)議較好地解決了資源預留的問題，在很大程度上為IP網(wǎng)絡提供了QoS保障，在用戶數(shù)量極少時是一種重要的資源分配方法。但隨著時間的推移，網(wǎng)絡的爆炸性增長，RSVP所暴露出來的問題越來越多，主要體現(xiàn)在沿途的路由器本來是為轉(zhuǎn)發(fā)數(shù)據(jù)分組而設計的，并不是專門為資源預留設計的，在網(wǎng)絡流量爆炸性增長的情況下，路由器轉(zhuǎn)發(fā)的數(shù)據(jù)急劇增長，為提高轉(zhuǎn)發(fā)速度，路由器中已經(jīng)承受了很大負荷，而不可能再為每個數(shù)據(jù)進行復雜的資源預留協(xié)議。因此網(wǎng)絡會因為呼叫過多、沒有足夠資源進行分配而斷掉，或者無法響應新的呼叫。另外，當由于線路繁忙或路由器故障等原因，路由修改時，需要重新進行一次相對耗時的RSVP過程。
由于上述資源預留協(xié)議不能解決大規(guī)模用戶的實時傳輸，促使人們尋找其他方法解決上述問題。其中的一種方法就是利用端口號來識別實時業(yè)務。
如上所述，TCP和UDP都是位于IP層上的傳輸協(xié)議，是IP與上層之間的處理接口。在TCP和UDP的報頭中都包括源地址端口號和目的地址端口號等信息。TCP和UDP的端口號用來區(qū)分運行在單個設備上的多個應用程序的IP地址。
由于同一臺機器上可能會運行多個網(wǎng)絡應用程序，所以計算機需要確保目標計算機上接收源主機數(shù)據(jù)分組的軟件應用程序的正確性，以及響應能夠被發(fā)送到源主機的正確應用程序上。該過程正是通過使用TCP或UDP端口號來實現(xiàn)的。上述TCP和UDP報頭部分的源端口和目標端口字段，正是用于顯示發(fā)送和接收過程中的身份識別信息。IP地址和端口號合在一起被稱為“套接字”。
服務器一般都是通過知名端口號來識別的。例如，對于每個TCP/IP實現(xiàn)來說，F(xiàn)TP服務器的TCP端口號都是21，每個Telnet服務器的TCP端口號都是23，每個TFTP(簡單文件傳送協(xié)議)服務器的UDP端口號都是69。這些端口號由Internet號分配機構(gòu)(Internet AssignedNumbers Authority，IANA)來分配和管理。
IANA定義了三種端口知名端口、注冊端口以及動態(tài)和/或私有端口，各自的端口號如下·知名端口(Well Known Ports)從0到1023。
·注冊端口(Registered Ports)從1024到49151。
·動態(tài)和/或私有端口(Dynamic and/or Private Ports)從49152到65535。
Cisco公司曾在解決VoIP分組從以太網(wǎng)(Ethernet)進入到幀中繼(Frame Relay)網(wǎng)中的轉(zhuǎn)換時，采用了一種使用端口號識別會話優(yōu)先級的方法(Frame Relay IP RTP Priority，CiscoIOS Release 12.0(7)T)。具體地說，幀中繼網(wǎng)絡的幀中有一個優(yōu)先級比特，幀中繼網(wǎng)絡根據(jù)此優(yōu)先級比特識別需要轉(zhuǎn)發(fā)的幀的先后順序。如果以太網(wǎng)中的一個用戶和幀中繼網(wǎng)中的另一個用戶使用RTP協(xié)議進行實時會話，則需要在網(wǎng)關(gateway)處將來自以太網(wǎng)的消息(或者幀)映射成具有優(yōu)先級的幀中繼網(wǎng)絡中的幀。由于沒有為RTP協(xié)議注冊UDP的端口號，網(wǎng)關不能識別出RTP幀，因此無法將RTP幀映射成高優(yōu)先級的幀，從而使得RTP幀的優(yōu)先級降低、甚至被丟棄。Cisco公司為解決上述問題，采用的方法是將UDP端口號為1024到65535的幀都設置為高優(yōu)先級，這樣RTP幀就會被認為是具有高優(yōu)先級而被優(yōu)先轉(zhuǎn)發(fā)。
但是，由于1024到65535的端口號范圍過大，將本應具有低優(yōu)先級的幀也設置成高優(yōu)先級，其后果是容易引起網(wǎng)絡攻擊，使合法用戶無法得到服務響應。這樣高優(yōu)先級的幀不僅沒有得到高優(yōu)先級服務，反而得到低優(yōu)先級服務，最終導致通話無法建立或者中斷。

發(fā)明內(nèi)容本發(fā)明的目的是提供一種方法，使用該方法可以通過Internet傳輸以話音和活動圖像為代表的實時多媒體業(yè)務，使得延遲、抖動能夠限制在可以接受的范圍之內(nèi)。為達到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，包括發(fā)送端和接收端，以及網(wǎng)絡中的路由器，其特征在于向Internet工程任務組IETF下設的Internet號碼分配機構(gòu)IANA分別為實時傳輸協(xié)議RTP、實時傳輸控制協(xié)議RTCP、實時傳輸流協(xié)議RTSP注冊用戶數(shù)據(jù)報協(xié)議UDP的源端口號和目的端口號，然后分別在上述實時傳輸協(xié)議RTP、實時傳輸控制協(xié)議RTCP、實時傳輸流協(xié)議RTSP的報頭中添加用于識別會話的會話標識Session ID字段。
根據(jù)本發(fā)明的一個方面，上述用于識別會話的會話標識Session ID字段的位數(shù)為32比特。根據(jù)本發(fā)明的另一個方面，上述分別為實時傳輸協(xié)議RTP、實時傳輸控制協(xié)議RTCP、實時傳輸流協(xié)議RTSP注冊用戶數(shù)據(jù)報協(xié)議UDP的源端口號和目的端口號為1024到65535之間的任意一個號碼。
根據(jù)本發(fā)明的再另一個方面，上述分別為實時傳輸協(xié)議RTP、實時傳輸控制協(xié)議RTCP、實時傳輸流協(xié)議RTSP注冊用戶數(shù)據(jù)報協(xié)議UDP的源端口號和目的端口號為1024到49151之間的任意一個號碼。
一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，包括發(fā)送方和接收方，以及網(wǎng)絡中的路由器，其特征在于向Internet工程任務組IETF下設的Internet號碼分配機構(gòu)IANA分別為實時傳輸協(xié)議RTP、實時傳輸控制協(xié)議RTCP、實時傳輸流協(xié)議RTSP注冊用戶數(shù)據(jù)報協(xié)議UDP的目的端口號。
根據(jù)本發(fā)明的另一個方面，上述分別為實時傳輸協(xié)議RTP、實時傳輸控制協(xié)議RTCP、實時傳輸流協(xié)議RTSP注冊用戶數(shù)據(jù)報協(xié)議UDP的目的端口號為1024到65535之間的任意一個號碼。
根據(jù)本發(fā)明的再一個方面，上述分別為實時傳輸協(xié)議RTP、實時傳輸控制協(xié)議RTCP、實時傳輸流協(xié)議RTSP注冊用戶數(shù)據(jù)報協(xié)議UDP的目的端口號為1024到49151之間的任意一個號碼。
采用本發(fā)明所提供的在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法具有以下優(yōu)點1.采用本發(fā)明能夠在分組傳輸過程中逐跳地識別實時傳輸協(xié)議(RTP)的幀，由于每一個路由器都能識別RTP幀，因此可以為實時業(yè)務傳輸提供優(yōu)先等級。
2.本發(fā)明提供了資源預留協(xié)議之外的另外一種VoIP服務機制，相對于只能容納少量網(wǎng)絡用戶的資源預留協(xié)議而言，本發(fā)明可以在實際的Internet網(wǎng)中采用，尤其是在網(wǎng)絡用戶多時仍然可以采用。


圖1是現(xiàn)有技術(shù)中實時傳輸協(xié)議RTP的報頭格式。
圖2是使用資源預留協(xié)議RSVP建立傳輸路徑以及預留資源的過程。
圖3是采用本發(fā)明的實時傳輸協(xié)議RTP的報頭格式。
具體實施方式
圖3表示本發(fā)明的第一個實施例。在Internet網(wǎng)絡中傳輸實時業(yè)務RTP幀時，發(fā)送端首先將上述RTP幀經(jīng)UDP、IP打包后傳遞給第一個路由器，由于向Internet工程任務組IETF下設的Internet號碼分配機構(gòu)IANA分別為RTP、RTCP、RTSP注冊了UDP的源端口號和目的端口號，因此該路由器接到上述實時業(yè)務幀時，該路由器由該實時業(yè)務幀中的UDP的目的端口號即可判斷出該幀為實時業(yè)務幀，因此以高優(yōu)先等級將該幀向下一路由器轉(zhuǎn)發(fā)，而無需再進行資源預留的過程。同樣，下一路由器也由該實時業(yè)務幀中的UDP的目的端口號即可判斷出該幀為實時業(yè)務幀，再向更下一路由器轉(zhuǎn)發(fā)。這樣在Internet網(wǎng)絡中便可實現(xiàn)逐跳識別實時業(yè)務，一直到接收端。
在現(xiàn)有技術(shù)中，UPD的源端口號和目的端口號被用于識別不同的會話。而在本發(fā)明中由于UDP的源端口號和目的端口號都被注冊使用，因此在RTP的報頭中添加一個32比特的用于識別不同會話的會話標識Session ID字段。
下面論述本發(fā)明的第二個實施例。在Internet網(wǎng)絡中傳輸實時業(yè)務RTP幀時，發(fā)送端首先將上述RTP幀經(jīng)UDP、IP打包后傳遞給第一個路由器，由于向Internet工程任務組IETF下設的Internet號碼分配機構(gòu)IANA分別為RTP、RTCP、RTSP注冊了目的端口號，因此該路由器接到上述實時業(yè)務幀時，該路由器由該實時業(yè)務幀中的UDP的目的端口號即可判斷出該幀為實時業(yè)務幀，因此以高優(yōu)先等級將該幀向下一路由器轉(zhuǎn)發(fā)，而無需再進行資源預留的過程。同樣，下一路由器也由該實時業(yè)務幀中的UDP的目的端口號即可判斷出該幀為實時業(yè)務幀，再向更下一路由器轉(zhuǎn)發(fā)。這樣在Internet網(wǎng)絡中便可實現(xiàn)逐跳識別實時業(yè)務，一直到接收端。采用上述第二實施例的方法，由于只注冊了目的端口號，而源端口號仍可以作為識別不同會話的標識字段使用，因此在RTP的報頭中無需添加會話標識Session ID字段，此時RTP的報頭和現(xiàn)有技術(shù)(即圖1)中的相同。
綜上所述，采用本發(fā)明的方法能夠在分組傳輸過程中逐跳地識別實時傳輸協(xié)議RTP的幀，為實時業(yè)務傳輸提供優(yōu)先等級，使得在網(wǎng)絡流量爆炸性增長的情況下仍然可以為實時業(yè)務提供QoS保證。
權(quán)利要求
1.一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，包括發(fā)送端和接收端，以及網(wǎng)絡中的路由器，其特征在于向Internet工程任務組下設的Internet號碼分配機構(gòu)分別為實時傳輸協(xié)議實時傳輸控制協(xié)議實時傳輸流協(xié)議注冊用戶數(shù)據(jù)報協(xié)議的源端口號和目的端口號，然后分別在上述實時傳輸協(xié)議實時傳輸控制協(xié)議實時傳輸流協(xié)議的報頭中添加用于識別會話的會話標識字段。
2.如權(quán)利要求1的一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，其特征在于上述用于識別會話的會話標識字段的位數(shù)為32比特。
3.如權(quán)利要求1的一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，其特征在于上述分別為實時傳輸協(xié)議、實時傳輸控制協(xié)議、實時傳輸流協(xié)議注冊用戶數(shù)據(jù)報協(xié)議的源端口號和目的端口號為1024到65535之間的任意一個號碼。
4.如權(quán)利要求1的一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，其特征在于上述分別為實時傳輸協(xié)議、實時傳輸控制協(xié)議實時傳輸流協(xié)議注冊用戶數(shù)據(jù)報協(xié)議的源端口號和目的端口號為1024到49151之間的任意一個號碼。
5.一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，包括發(fā)送方和接收方，以及網(wǎng)絡中的路由器，其特征在于向Internet工程任務組下設的Internet號碼分配機構(gòu)分別為實時傳輸協(xié)議、實時傳輸控制協(xié)議、實時傳輸流協(xié)議注冊用戶數(shù)據(jù)報協(xié)議的目的端口號。
6.如權(quán)利要求5的一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，其特征在于上述分別為實時傳輸協(xié)議、實時傳輸控制協(xié)議、實時傳輸流協(xié)議注冊用戶數(shù)據(jù)報協(xié)議的目的端口號為1024到65535之間的任意一個號碼。
7.如權(quán)利要求5的一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，其特征在于上述分別為實時傳輸協(xié)議、實時傳輸控制協(xié)議、實時傳輸流協(xié)議注冊用戶數(shù)據(jù)報協(xié)議的目的端口號為1024到49151之間的任意一個號碼。
全文摘要
本發(fā)明提出一種在Internet網(wǎng)絡中逐跳識別實時業(yè)務的方法，包括發(fā)送端和接收端，以及網(wǎng)絡中的路由器，向Internet工程任務組(IETF)下設的Internet號碼分配機構(gòu)(IANA)分別為RTP、RTCP、RTSP注冊UDP的源端口號和目的端口號，然后在上述UDP的報頭中添加用于識別會話的會話標識(Session ID)字段。采用本發(fā)明的方法能夠在分組傳輸過程中逐跳地識別實時傳輸協(xié)議(RTP)的幀，為實時業(yè)務傳輸提供優(yōu)先等級，使得在網(wǎng)絡流量爆炸性增長的情況下仍然可以為實時業(yè)務提供QoS保證。
文檔編號H04L29/06GK1783835SQ20041009756
公開日2006年6月7日 申請日期2004年11月30日 優(yōu)先權(quán)日2004年11月30日
發(fā)明者田立剛, 劉振, 雷志平 申請人:西門子(中國)有限公司