使用OpenSER構建電話通信系統(tǒng)

使用OpenSER構建電話通信系統(tǒng)

BuildingTelephonySystemswithOpenSER

第一章：SIP介紹(IntroductiontoSIP)

本章結(jié)束的時候你將能夠：

?描述SIP是什么

?描述SIP是干什么的

?描述SIP的框契

?解釋SIP要緊部件的意義

?懂得并比較要緊SIP消息

?描述INVITE與REGISTER請求消息頭部的處理過程

在建立與關閉多媒體通話的過程中，SIP協(xié)議支持五種要素。

?用戶定位(Userlocation)

?用戶參數(shù)協(xié)商：Userparametersnegotiation)

?用戶口J用性(Useravailability)

?通話建立(Callestablishment)

通話管理(Callmanagement)

SIP協(xié)議被設計成多媒體框架的一部分，而這種多媒體框架包含RTSP,

RTP,RTSP還有SDP等其他協(xié)議。然而，SIP卻并不依靠其他這些協(xié)議工作。

SIP基礎(SIPBasics)

在SIP的體系結(jié)構中，有多個用戶代理與提供不一致服務的服務器。SIP使

用點對點(peer?to-peer)的分布模型來與服務器進行消息的交互。服務器只進

行消息(signaling)的處理，而用戶代理的客戶端與服務端既能夠處理消息也能

夠處理媒體。下面的圖描述了這樣的一個體系：

SIPTrapezoid

SIP

SIP

RTP

UseragentA@DomainAUseragentB@DomainB

startingthecallreceivingthecall

在SIP模型中，用戶代理，通常是一臺SIP話機與它的SIP代理進行交互,

從上圖能夠看到,外呼代理(outgoingproxy)將使用INVITE消息向外發(fā)出通

話請求。

外呼代理將觀察這通通話是否是被定向到外部的域名。然后它將向DNS服

務器發(fā)出請求將目標域名解析為對應的IP地址。然后再將通話請求發(fā)送給

DomainB對應的SIP代理。

呼入代理(incomingproxy)將在地址列表(locationtable)中查詢agentB

的IP地址。假如在地址列表這個地址與之前在注冊過程中的IP地址對應，那么

呼入代理就能夠定位這個地址了?，F(xiàn)在就能夠使用這個地址將通話請求發(fā)送到

agentB了。

agen舊收到這個SIP消息后(INVITE),就擁有了能夠與agentA建立RTP

會話(通常是音頻方面的會話)所需要的信息。使用BYE消息能夠終止這個會

話。

SIP代理在VoIP提供者里的作用/上卜文(SIPProxyinthe

ContextofaVoIPProvider)

通常VoIP服務的提供者們并不可能實現(xiàn)像上幅圖那樣的純粹的SIP四邊形

結(jié)構，他們不可能同意你向一個外部的域名發(fā)送通話請求，由于假如這樣，那么

將影響他們的收入(revenuestream)。取而代之的是一個接近三角形的SIP網(wǎng)

絡結(jié)構。(如下圖所示)

VoIPProviders

UseragentA@DomainAUseragentB@DomainA

startingthecallreceivingthecall

SIP工作原理(SIPOperationTheory)

在上圖中，你能夠看到SIP體系結(jié)構中的要緊的構成部件。所有的SIP消息

都會通過SIP代理服務器。另一方面，由RTP協(xié)議承載的媒體流則是從一瑞直

接流向另?端。我們將在下面的列表中簡要的對其中的?些構成部件進行解釋。

?用戶代理客戶端(UACuseragentclient)——發(fā)起SIP消息的客戶

端或者終端

?用戶代理服務端(UASuseragentserver)——對接收到的從用戶代

理客戶端發(fā)起的SIP消息進行相應的服務端。

?用戶代理(UAuseragent)——SIP終端(IP電話，電話適配器(ATA),

軟電話(softphone))

?代理服務器(ProxyServer)——從用戶代理接收請求，同時假如指定

的被請求的終端不在其域中時，會將請求發(fā)送給另外的SIP代理。

?重定向服務器(RedirectServer)——接收請求，但是不直接發(fā)送給

被叫用戶，而是向主叫方發(fā)送目的地址的信息。

?定位服務器(LocationServer)------向代理服務器與重定向服務器提

供被叫者的聯(lián)系地址。

通常，物理上，代理服務器，重定向服務器與定位服務器存在于同一臺

電腦與軟件中。

SIP注冊過程(SIPRegistrationProcess)

LocationRegistersip:

DatabaseFrom:sip:8500@

tosip:8500@

Contact:<sip:200,180.1.1>

Expires3600

SIP/2.0200OK

SIP協(xié)議中使用了一個構件叫做注冊服務器。它不僅能夠接收REGISTER

消息請求，還能夠?qū)⑹盏降南械男畔Υ娴焦芾韺蛎亩ㄎ环掌魃?/p>

面。SIP協(xié)議具有發(fā)現(xiàn)能力；換句話說，就是假如一個用戶要與另外一個用戶開

始會話，那么SIP協(xié)議務必要發(fā)現(xiàn)這個用戶能夠到達的主機存在。由于定位服

務器能夠收到請求消息并找到向什么地方發(fā)送，因此這個發(fā)現(xiàn)過程由定位服務器

來完成。而這則是基于管理每個域的定位服務器保護著一個定位數(shù)據(jù)庫的事實來

實現(xiàn)的。注冊服務器不僅能夠接收客戶端的IP地址，還能夠接收其他類型的消

息。比如，能夠收到服務器上面的CPL(CallProcessingLanguage)腳本。

RFC3665定義實現(xiàn)了一個最小的功能集合，這是使得SIP進行IP網(wǎng)絡交互

時的最好實踐。下面的圖就是根據(jù)RFC3665中的描述所畫出的注冊事務處理流

程。

SIPRegistrationFlows

Usera陶］Sip

AgentONewregistration；:PProxy

REGISTER.

.401Unauthorized

REGISTER4

.200OK______________

UpdateofContactList

_____________REGISTER上

<200OK______________

RequestforCurrentContactList

REGISTER?

.200OK

Cancellationoftheregistration

_____________REGISTER.

.200OK______________

UnsuccessfullRegistration

_____________REGISTER上

.401Unauthorized

REGISTER?

401Unauthorized

按照rfc3665中所說，與注冊一個用戶代理的過程有關的有五個基本的流程,

如下所述：

1.一個新的成功的注冊(Asuccessfulnewregistration)----用戶代理在發(fā)送Register請求后，

將收到認證過程的挑戰(zhàn)。我們將在闡述驗證過程的章W中看到這個過程的細|九

2.聯(lián)系列表的更新(Anupdateofthecontactlist)——山丁?不再是新的注冊，消息中已經(jīng)包含了

摘要(digest),那么不可能返回401消息。為了改變聯(lián)系列表，用戶代理僅僅需要發(fā)送一條

在CONTACT頭中帶有新的聯(lián)系信息的注冊信息即可。

3.請求獲得當前的聯(lián)系列表——在這種情況下，用戶代理將把發(fā)送消息中的CONTACT頭置空，

說明用戶希望向胭務器詢問當前的聯(lián)系列表。在回復的2000K消息中，SIP服務器將把當前

的聯(lián)系列表放在其CONTACT的頭中。

4.取消注冊(Cancellationofaregistration)——用戶代理在發(fā)送的消息中將EXPIRES頭置成0.

同時將CONTACT頭設置為“*”表示將此過程應用到所有存在的聯(lián)系信息。

5.不成功的注冊(UnsuccessfulRegistration)——用戶代理客戶端(UAC)發(fā)送一條Register

請求消息，收到一條“401Unauthorized”消息，事實上，這個過程同成功注冊過程相同。但是

接下來，它進行哈希運算嘗或進行認證。而服務器檢測到的是一個無效的密碼，繼續(xù)發(fā)送“401

Unauthorized”消息。這個過程?直重復直到重復次數(shù)超過在UAC設置的最大值。

作為SIP代理運轉(zhuǎn)的服務器(ServerOperating

asaSIPProxy)

在SIP代理模式下，所有的IP消息都要通過SIP代理。這種行為在向諸如

計費(billing)的過程中幫助很大，而且迄今為止，這也是一種最普遍的選擇。

但是它的缺點就是在會話建立過程中的所有的SIP交互中，服務器造成的額外

開銷也是客觀的。要記住的是，即使服務器作為SIP代理在工作時，RTP包也

總是直接從一端傳送到另一端，而不可能通過服務器。

Proxy

INVITELocationeINVITE

sip:8500@Registrarsip:8500@68

From:sip:2400@ServerFrom:sip:24OO@

Tb:sip:8500@To:sip:8500@

CalHD2400@Call-ID2400@

0K2000K200

From:sip:2400@From:sip:24OO@

lb:sip:8500@To:sip:8500@

CaIMD2400@Call-ID2400@

sip:2400@sip,comMediaFlowsip:8500@68

作為SIP重定向運轉(zhuǎn)的服務器(Server

OperatingasaSIPRedirect)

SIP代理能夠運行在SIP重定向模式。在這種模式下，SIP服務器的處理量

是相當巨大的，由于它不需要保持事務處理的狀態(tài)。在對INVITE消息進行初始

化后，僅僅向UAC回復一條“302MovedTemporarily”消息就能夠離開SIP對話

(dialog)了。在這種模式下的SIP代理，即使只是利用非常少的資源也能夠每

小時傳送上百萬的通話。當你需要的規(guī)模很大同時不需要對通話計費的情況下，

這種模式通常會被使用。

INVITE

sip:8500@

From:sip:2400@Location,

Tb:sip:8500@Registrar,and

Call-ID2400@Redirect

Server

OK302movedtemporarily

Contactsip:8500@200,180.4.168

INVITE8500@200?180,4?168

OK200

ACK8500@68

sip:2400@MediaFlowsip:8500@68

基本消息(BasicMessages)

在SIP環(huán)境中會被發(fā)送的某本的消息有:

SIPbasicmessages

MethodDescriptionRFC

ACKAcknowledgeanINVITERFC3261

BYETermlnatoanoxistingsessionRFC3261

CANCELCancolapendingroquottRFC32S1

INFOMid-callsignalinginformationRFC2976

INVITESessionestablishmentRFC3261

MESSAGEInstantmessagetransportRFC3428

NOTIFYSendInformationaftersubscribeRFC3265

OPTIONSQuorythecapabilitiesofth。UARFC3261

PRACKAcknowledgeaprovisionalresponseRFC3262

PUBLISHUploadstatusInformationtotheserverRFC3903

REGISTERRegistertheuseranupdatethelocationUbleRFC3M1

REFERA$kanotherUAtoactuponURIRFC3515

SUBSCRIBEEstablishasessiontoreceivefutureupdatesRFC3265

UPDATEUpdatesessionstateinformationRFC3311

大多數(shù)時間內(nèi)，你會使用到REGISTER,INVITE,BYE還有CANCELo而另外?些

消息會被用在其他的特性當中。舉例來說，INFO被用在DTMFrelay與通話中消息信息

(mid-callsignalinginformation)<,PUBLISH,NOTIFYSUBSCRIBE則用來支持列席系

統(tǒng)(presencesystems).REFER用來進行通話轉(zhuǎn)接(calltransfer)而MESSAGE則應用

于一些聊天應用程序中。更新的消息也會隨著協(xié)議標準化進程而隨之出現(xiàn)。

ResponseCodes

DescriptionCodeExamples

Informationalor1XX100Trying182Queued

provisionalresponse180Ringing

181CallIsBeingForwarded

Success2XX200OK

202Accepted

Redirect3XX300MultipleChoices303SeeOther

301MovedPermanently305UseProxy

302MovedTemporarily380AlternativeService

ClientErrors4XX400BadRequest411LengthRequired

401Unauthorized413RequestEntityTooLarge

402PaymentRequired414RequesbURITooLarge

403Forbidden415UnsupportedMediaType

404NotFound420BadExtension

405MethodNotAllowed480Temporarilynotavailable

406NotAcceptable481CallLeg/TransactionDoesNotExist

407ProxyAuthentication482LoopDetected

Required483TooManyHops

408RequestTimeout484AddressIncomplete

409Conflict485Ambiguous

410Gone486BusyHere

ServerErrors5XX500InternalServerError503ServiceUnavailable

501NotImplemented504GatewayTime-out

502BadGateway505SIPVersionnotsupported

GlobalErrors6XX600BusyEverywhere604Doesnotexistanywhere

603Decline606NotAcceptable

SIP對話流程(SIPDialogFlow)

這一節(jié)將通過一個簡單的例子來介紹一些基本的SIP操作。先讓我們來診視下圖展示

的兩個用戶代理之間的消息順序。你能夠看到伴隨這RFC3665描述的會話建立過程還有幾

個其它的流程。

INVITE(I)

INVITE(3)t

.100Trying(2)INV1TE(5)

100Trying(4)

.180Ringing⑹

.180Ringing(7)

180Ringing(8)200OK⑼

6).200OK(10)<8--------

.200OK(10)

DeviceACK(11)Device

(phone)(phone)

userA.MediaSessionRTP(12).userB

BYE(13)

200OK(14)

A

我們在這些消息上標上了序號。在這個例子中用戶A使用IP電話向網(wǎng)絡上的另外一臺

IP電話發(fā)出通話請求。為了完成通話，使用了兩個SIP代理。

事務(transaction)的建立始于用戶A向用戶B發(fā)送INVITE請求消息。INVITE請求

中包含一些特定頭域。這些頭域被稱之為屬性，為消息提供了額外的一些信息。包含唯一的

標識，目的地，還有關于會話(session)的信息。

INVITEfromA->B

INVITEsip:userB@sipB.comSIP/2.0

Via:SIP/2.0/UDPmoon.sipA.com;branch=z9hG4bK776asdhds

Max-Forwards:70

To:userB<sip:userB@sipB.com>

From:userA<sip:userA@sipA.com>;tag=1234567890

Call-ID:a84b4c76e66710@moon.sipA.com

CSeq：314159INVITE

Contact:<sip:userB@sun.sipB.com>

Content-Type:application/sdp

Content-Length:142

(SDPnotshown)

第一行是消息的方法名(themethodname)。接下來是列出的頭域。這個例子包含了

所需要的頭的最小集合。我們將在下面簡要的描述這些頭域。

?VIA：它包含了用戶A等待發(fā)出請求對應響應的所在地址。還包含了一個叫做

"branch”的參數(shù)，這個參數(shù)用來唯一的標識這個事務(transaction)oVIA頭將最近

從“SIP跳”(SIPhop)定義為IP,傳輸，與指定事務參數(shù)(TheVIAheaderdefines

thelastSIPhopasIP,transport,andtransaction-specificparameters)oVIA專

門用來路由響應消息。請求通過的每一個代理都會增加一個VIA頭。而關于響應消

息而言，相關于再次向定位服務器或者是DNS服務器進行定位請求，使用VIA頭

進行路由將更加容易。

?CALL-ID：它包含了一個作為這通通話全局性的唯一的標識，而這個唯一標識是有

一個隨機字符串，來自IP電話的主機名或者是IP地址結(jié)合而成的。TO,FROM的

tag與CALL-ID的結(jié)合完整的定義了一個端到端的SIP關系，這種關系就是我們

所明白的SIP對話(SIPdialog)

?CSEQ：CSEQ或者者稱之為命令序列(commandsequence)包含了一個整數(shù)與

一個方法名。CSEQ數(shù)關于每一個在SIP對話中的新請求都會遞增，是一個傳統(tǒng)的

序列數(shù)。

?CONTACT：它包含一個代表直接路由能夠聯(lián)系到用戶A的SIPURI,通常是有一

個用戶名與FQDN（fullyqualifieddomainname）。有的時候候域名沒有被注冊，

因此，IP地址也是同意使用的。VIA頭告訴其他的組件向什么地方發(fā)送響應消息，

而CONTACT則告訴其他組件向什么地方發(fā)送將來的請求消息。

?MAX-FORWARDS：它被用來限制請求在到達最終目的地的路徑中被同意的最大

跳數(shù)（hops）。由一個整數(shù)構成，而這個整數(shù)在每一跳中將會遞減。

?CONTENT-TYPE：它包含了對內(nèi)容消息的描述。

?CONTENT-LENGTH：它用來告知內(nèi)容消息的字節(jié)數(shù)。

會話的一些細節(jié)，像媒體類型與編碼方式并不是使用SIP進行描述的。而是使用叫做

會話描述協(xié)議（SDPRFC2327）來進行描述。SDP消息由SIP消息承載，就像是一封電子

郵件的附件一樣。

過程如下:

1.在這個例子中，代理服務器收到INVITE請求消息并發(fā)送“100trying”響應消息給

用戶A,說明代理服務器已經(jīng)收到了INVITE消息并正在轉(zhuǎn)發(fā)這個請求。SIP的響應

消息使用一個三人數(shù)字構成的數(shù)字碼與一條描述語句說明響應的類型。并擁有與

INVITE請求一樣的TO,FROM,CALL-ID與CSEQ等頭域，與VIA與其“branch”

參數(shù)。這就使得用戶A的話機同發(fā)出的INVITE請求聯(lián)系在一起。

2.代理A定位代理B的方法是向DNS服務器（SRV記錄）進行查詢以找到負責

sipB的SIP域的服務器地址并將INVITE請求轉(zhuǎn)發(fā)給它。在向代理B（譯者注：這

里作者寫的是proxyA,但是應該是B）發(fā)送INVITE消息前，代理A將其自己的地

址通過VIA頭添加進INVITE,這就使得用戶A的話機同INVITE請求的響應消息聯(lián)

系在了一起。

3.代理B收至I」INVITE請求，返回“100Trying”消息響應，說明其正在處理這個請求。

4.代理B查詢自己的位置數(shù)據(jù)庫以找到用戶B的地址，然后將自己的地址也通過

VIA頭域添加進INVITE消息發(fā)送給用戶B的IP地址。

5.用戶B的話機收到INVITE消息后開始振鈴。話機為了要說明這種情況(振鈴),

發(fā)送回“180Ringing”響應消息。

6.這個消息以相反的方向路由通過那兩個代理服務器。每一個代理利用VIA頭域來

決定向哪里發(fā)送響應消息并從頂部將其自己的VIA頭去除。結(jié)果就是，180Ringing

消息不需耍任何的DNS查詢，不需耍定位服務的響應，也不需要任何的狀態(tài)處理就

能夠返回到用戶那里。這樣的話，每一個代理服務器都能夠看到由INVITE開始的

所有消息。

7.當用戶A的話機收到的80Ringing”響應消息后開始“回鈴”，說明另一端的用戶

正在振鈴。些話機是通過顯示些信息進行表示的。

8.在這個例子中，用戶B對對方發(fā)起的通話進行了響應。當用戶B響應時，話機

發(fā)送"200Ok“響應消息以說明通話被接起?！?000k”的消息體中包含了會話的描述

信息，這些信息包含指定了編碼方式，端口號，與從屬于會話的所有情況。作這項

工作的就是SDP協(xié)議。結(jié)果就是，在從A到B(INVITE)與從B至ijA(200OK)

的兩個階段，雙方交換了一些信息，以一種簡單的“請求/響應”的模式協(xié)商了在這通

通話中所需的資源與所需要的能力要求。假如用戶B不想得到這通通話或者是此刻

處于忙線中，200Ok將不可能發(fā)出，取代它的是描述這種狀況（這里是486Busy

Here）的消息。

Response200Ok

SIP/2,0200OK

Via:SIP/2.0/UDPsipB.com

;branch=z9hG4bKnashds8;received=

Via:SIP/2.0/UDPmoon.sipA.com

;branch=z9hG4bK77ef4c2312983.1;received=

Via:SIP/2.0/UDPphoneA.sipA.com

;branch=z9hG4bK776asdhds：received=

To:userB<sip:userB@sipB.com>;tag=a6c85cf

From:userA<sip:userA@sipA.com>;tag=1928301774

Call-ID:a84b4c76e66710@phoneA.sipA.com

CSeq:314159INVITE

Contact:<sip:userB@>

Content-Type:application/sdp

Content-Length:131

第一行是響應碼與描述信息（OK）。接下來是頭域行。VIA,TO,FROM,CALL-ID

與CSEQ是從INVITE請求中拷貝的。有三個VIA頭，一個是用戶A添加的，另一個是代

理A添加的，最后一個則是代理B添加的。用戶B的SIP話機在對話的雙方加入了一個TAG

參數(shù)，這個參數(shù)在這通通話的以后的請求與響應消息中都將出現(xiàn)。

CONTACT頭域中包含了URI信息，這個URI信息是用戶B能夠直接被聯(lián)系到他們自

己的IP話機的地址。

CONTENT-TYPE與CONTENT-LENGTH頭域先給出了關于SDP頭的一些信息。

而SDP頭則包含/用來是立RTP會話的媒體有關的參數(shù)。

1.在這個例子中，“2000k”消息通過兩個代理服務器被送回給用戶A,之后用華A的

話機停止“回鈴”說明通話被接起。

2.最后用戶A向用戶B的話機發(fā)送ACK消息確認收到了“200Ok”消息。在這里，ACK

躲開了兩個代理服務器直接發(fā)送給用戶B°ACK是SIP中唯一不需要進行響應的消息請求。

兩端在INVITE的過程中從CONTACT消息中熟悉雙方的地址信息。也結(jié)束了INVITE/200

OK/ACK的過程，這個過程也就是我們所熟知的SIP三次握手。

3.這個時候兩個用戶之間開始進行會話，他們以用SDP協(xié)議協(xié)商好的方式來發(fā)送媒體

包。通常這些包是端對端進行傳送的。在會話中，通話方能夠通過發(fā)送一個新的INVITE請

求來改變會話的一些特性。這叫做re—inviteo假如re-invite不被同意，那么"488Not

AcceptableHere”響應就會被發(fā)出，但是會話不可能因此而失敗。

4.要結(jié)束會話的時候，用戶B產(chǎn)生BYE消息來中斷通話。這個消息繞過兩個代理服務

器直接路由回用戶A的軟電話上。

5.用戶A發(fā)出“2000K”響應消息以確認收到了BYE消息請求，從而結(jié)束會話。這里,

不可能發(fā)出ACKoACK只在INVITE請求過程中出現(xiàn)。

有些情況下，在整個會話過程中，關于代理服務器來說，能夠待在消息傳輸?shù)闹虚g位置

來觀察兩端的所有消息交互是很重要的。假如代理服務器想在INVITE請求初始化完成后還

待在此路徑中，能夠在請求消息中添加RECORD-ROUTE頭。用戶B的話機得到了這個

消息，之后在其消息中也會帶有這個頭，同時會將消息發(fā)送回代理。記錄路由(Record

Routing)在大多數(shù)的方案中都會被使用。

REGISTER請求是代理B用來定位用戶B的方法。當話機初始化的時候或者是在通常

的時間間隔中，軟電話B向在域sipB中的一個服務器(SIPREGISTRAR)發(fā)送REGISTER

請求。注冊服務器(REGISTER)將URI與一個IP地址聯(lián)系在一起，這種綁定被存儲在定

位服務器上面的數(shù)據(jù)庫里，通常，注冊服務器，定位服務器，與代理服務器在同一臺物理機

器上，并使用相同的軟件.OpenSER就能夠扮演這三種角色。一個URI只能夠在一個特定

的時間內(nèi)由一個單獨的機器注冊。

S工P事務與對話(SIPTransactionsand

Dialogs)

TransactionsandDialogs

INVITE(I)

INVITE(3)

.100Trying⑵INVITE⑸

<100Trying⑷

180Ringing(6)-Transaction

<180Ringing(7)

180Ringing(8)200OK(9)

200OK(10)

200OK(10)-Dialog

ACK(11)

MediaSessionRTP(12)

BYE(13)

200OK(14)-Transaction

懂得“事務”（transaction）與“對話”（dialog）的區(qū)別是非常重要的。事務發(fā)生在一個用

戶代理客戶端與另一個用戶代理服務端之間，包含從第一請求到最后一個響應的所有消息。

中間的階段性的響應消息能夠是以1開頭的三位數(shù)字碼（比如180Ringing）,最終的響應

消息則是以2開頭的三位數(shù)字碼（比如200OK）o事務包含的范圍由SIP消息中VIA頭形

成'堆?！眮頉Q定。因此，用戶代理在初始化invite后才不需要依靠DNS或者位置表進行消

息路由。

對話(Dialog)通常是從INVITE事務開始，由BYE事務結(jié)束。一個對話由CALL-ID

頭唯一標識。TOtag,FROMtag與CALL—ID的結(jié)合來完整的定義。

按照rfc3665的描述，有11個基本的會話建立流程。其列出的并不一定是完整的，但

是覆蓋了最好的例子。前兩個流程在這一章節(jié)中進行了闡述一“成功建立會話Successful

SessionEstablishment”與“通過兩個代理建立.會話SessionEstablishmentThroughTwo

Proxies”。其中的一些流程的描述你將在其他闡述呼叫前傳(callforwarding)(譬如：“不接

聽導致沒能成功建立UnsuccessfulwithnoAnswer”與"忙音導致建立失敗Unsuccessful

Busy”)的章節(jié)中看到。

RTP協(xié)議(TheRTPProtocol)

譯者注：應為RealTimeTransportProtocol

實時傳輸協(xié)議是負責諸如音頻與視頻等數(shù)據(jù)的實時傳輸?shù)?。它標準化于RFC3550。使

用UDP協(xié)議進行傳輸承載。為了能夠被實時傳輸，音頻或者視頻務必通過一定的編碼打包。

最基本的，該協(xié)議同意使用如下的一些特性對進出的數(shù)據(jù)包的媒體傳輸?shù)臅r間與內(nèi)容要求進

行指定：

?序號

?時間戳

?無重傳機制的包的前轉(zhuǎn)

?源識別

?內(nèi)容識別

?同步

與RTP相伴的協(xié)議叫做RTCP(RealTimeControlProtocol),被用作對RTP包進行

監(jiān)控。它能夠度量延遲與抖動。

編碼(Codecs)

RTP協(xié)議描述的內(nèi)容通常會由一種編碼方式進行編碼。沒一種編碼方式都有一種指定

的用途。一些有壓縮算法而另外一些則不需要。比較普遍的是使用不需要壓縮的G.711編碼

方式。一個信道64Kbps的帶寬要求需要一個高速的網(wǎng)絡，通常在局域網(wǎng)(LANs)中比較

常見。但是在廣域網(wǎng)(WAN)中關于一個單獨的聲音信道來說，64Kbps的帶寬購買起來比

較昂貴。這時候諸如G,729與GSM等能夠?qū)⒙曇舭鼔嚎s至8Kbps的編碼方法則能夠節(jié)約

很多的帶寬。由GlobalIPsound公司發(fā)明的iLBC編碼方式則能夠掩蓋網(wǎng)絡中由丟包造成

的影響。在丟包率帶到7%的情況下，使用iLBC仍然能夠維持一個比較好的聲音質(zhì)量。因

此關于你的VoIP提供商支持的編碼方式你務必進行明智的選擇。

DTMF-Relay

在一些情況下，RTP協(xié)議被用來承載諸如DTMF的信號信息。RFC2833中描述了一種

方法，這種方法就是將DTMF作為RTP協(xié)議中的命名事件(namedevents)進行傳輸。在

用戶代理客戶端與用戶代理服務端之間使用同一種方法進行DTMF傳輸是非常重要的，

實時操縱協(xié)議(RealTimeControlProtocol-RTCP)

RTCP能夠?qū)ν獾馁|(zhì)量進行反饋。它為RTP媒體流提供帶外操縱信息。諸如抖動

(Jitter),往返時延(RTT-RoundTripTime),傳輸延遲(latency)與丟包等的數(shù)據(jù)能夠

使用RTCP進行搜集。RTCP通常用來對聲音質(zhì)量進行報告。

會話描述協(xié)議(SessionDescriptionProtocol-SDP)

SDP協(xié)議在RFC4566中被進行了全面的描述。它是在用戶代理之間進行會話參數(shù)協(xié)

商之用的。媒體的細節(jié)，傳輸?shù)牡刂愤€有其他與媒體有關的一些信息都使用SDP協(xié)議在用

戶代理之間進行交互。通常，INVTIE消息中包含了SDP“供給消息”，而200Ok則包含了“回

答消息”。這些消息會在下面的圖中進行展示。在下圖中，你能夠觀察到GSM編碼方式被“供

給”，但是另外一臺話機卻并不支持該編碼，那么然后它將使用它本身支持的編碼方式進行

“回答”，在這個例子中它支持的是G.711ulaw(PCMU)與G.729編碼方式。會話的

“rtpmap:101”就是在RFC2833中描述的DTMF—relay信息。

INVITE(SDPOffer)

-'Sessloft■Initiatidh'Protocbl-------------------------------------------------

?Request-Line:INVITEsip:8520?6:42989SIP/2.0

￡MessageHeader

SMessagebody

sSessionDescriptionProtocol

sessionDescriptionprotocolversion(v):0

oOwner/Creator,Sessionid(o):root1096810968INIP48.8.1.4

Ownerusername:root

sessionID：10968

sessionversion:10968

OwnerNetworkType:IN

OwnerAddressType:IP4

OwnerAddress:8.8.1.4

SessionName(s):session

Connectioninformation(c):INIP48.8.1.4

TimeDescription,activerime(t):00

MediaDescription,nameandaddress(m):audio17412RTP/AVP0318101

MediaAttribute(a):rtpmap:0PCMU/8000

MediaAttribute(a):rtpmap:3GSM/8000

MediaAttribute(a):rtpmap:18G729/8000

MediaAttribute(a):fmtp:18annexb?no

MediaAttribute(a):rxpmap:101telephone-event/8000

MediaAttribute(a):fmtp:1010-16

MediaAttribute(a):silencesupp:off---------

200OK(SDPAnswer)

-SessioninitiationProtocol

田Status-Line:SIP/2.0200OK

國MessageHeader

BMessagebody

ssessionDescriptionProtocol

sessionDescriptionProtocolversion(v):0

日owner/creator,sessionid(o):root1121811218INIP4

Ownerusername:root

sessionID：11218

sessionversion:11218

OwnerNetworkType:IN

OwnerAddressType:IP4

OwnerAddress:

sessionName(s):session

土connectioninformation(c):INIP4

￡TimeDescription,activetime(t):00

fMediaDescription,nameandaddress(m):audio17428RTP/AVP018101

38MediaAttribute(a):rtpmap:0PCMU/8000

iMediaAttribute(a):rtpmap:18G729/8000

?：MediaAttribute(a):fmtp:18annexb?no

■MediaAttribute(a):rtpmap:101telephone-event/8000

tMediaAttribute(a):fmtp:1010-16

tMediaAttribute(a):silence5upp:off---------

SIP協(xié)議與OSI七層模型(TheSIPProtocol

andtheOSIModel)

懂得聲音有關協(xié)議的每一個協(xié)議關于OSI模型是屬于哪一層也是相當重要的。

ApplicationSER/OpenSER

PresentationG.729/G711/GSM/Speex

SessionH323/SIP/MGCP/IAX|

TransportUDP/RTP/SRTP/RTcH

NetworkIP

DatalinkFrame-Relay/ATM/PPP/Ethernet

PhysicalEthemet/V.35/RS-232/xDSL

VoIP服務提供商的整體框圖(TheVoIP

Provider"BigPicture77)

UsinganATAFirewall

orSoftphone

在我們開始深入的挖掘SIP代理之前，熟悉VoIP提供商的解決方案中的所有部件是非

常重要的。服務提供者通常由多個服務器（servers）與多個服務（services）構成。這里說

的服務能夠根據(jù)規(guī)模的大小來決定是被安裝在一臺單獨的服務器上還是安裝在多臺機器上

面。

本書將在前幾個章節(jié)中按照這張圖從左到右來描述每一個部件。所有的章節(jié)中都將使用

這張圖來幫助你來熟悉你所處的位置何在。

SIP代理（SIPProxy）

SIP代理是我們解決方案中的核心部件。用來負責用戶的注冊與保護位置數(shù)據(jù)庫（映射

IP與SIP地址）。所有的SIP路由與消息都會被SIP代理處理，它也負責一些用戶端級別的

服務譬如呼叫前轉(zhuǎn)，白/黑名單，快速撥號等。這個部件從不處理媒體（RTP包），所有與媒

體有關的包都從用戶代理客戶端，服