基礎(chǔ) response code
1xx:informational－已經(jīng)收到請(qǐng)求、繼續(xù)處理請(qǐng)求粟关。
2xx:success－已經(jīng)成功收到，理解和介紹行動(dòng)粒没。
3xx:Redirection－為完成呼叫請(qǐng)求揩抡，還須采取進(jìn)一步地動(dòng)作。
4xx:ClientError－請(qǐng)求有語法錯(cuò)誤或服務(wù)器不能執(zhí)行請(qǐng)求却邓。
5xx:ServerError－服務(wù)器出錯(cuò)硕糊，不能執(zhí)行合法請(qǐng)求。
6xx:GLOBALFAILURE－任何服務(wù)器都不能執(zhí)行請(qǐng)求腊徙。
會(huì)話（Session）: 用于進(jìn)行媒體流傳送简十。當(dāng)一方發(fā)出請(qǐng)求，而另外一方或多方接受請(qǐng)求并通過信令交互成功后才能建立會(huì)話撬腾。
跟SDP內(nèi)信息相關(guān)螟蝙。在SDP中，多媒體會(huì)話指的是一組的媒體發(fā)送方和接收方及媒體流從發(fā)送方流向接受方民傻。會(huì)話是由SDP里的user name, session id, network type, address type, 和源處地址元素來確定的胰默。只有當(dāng)媒體協(xié)商成功后，會(huì)話才能被建立起來漓踢。
A session is initiated with INVITE and is created by completing offer/answer exchange.
對(duì)話（Dialog）: 由INVITE或者SUBSCRIBE創(chuàng)建
對(duì)話指的是一對(duì)一的持續(xù)一段時(shí)間的連接關(guān)系牵署，由Call-ID, From-tag和To-tag確定。當(dāng)三個(gè)元素齊全的時(shí)候喧半，即對(duì)話處于確定階段時(shí)奴迅，對(duì)話已經(jīng)建立起來。 Dialog ID：Call-Id, 本地tag, 對(duì)端tag 組成
Dialog(會(huì)話) 會(huì)話是兩個(gè)UAs(user agent) 之間持續(xù)一段時(shí)間的端到端(peer-to-peer)的SIP 關(guān)系. 一個(gè)會(huì)話由一個(gè)Call-ID, 一個(gè)local tag 和 一個(gè)remote tag來標(biāo)識(shí).會(huì)話過去也叫做 "call leg".
Dialog is a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog represents
a context in which to interpret SIP messages.
Dialogs are created through the generation of non-failure responses to requests with specific methods. Only 2xx and
101-199 responses with a To tag, where the request was INVITE, will establish a dialog
事務(wù)（Transaction）
事務(wù)包括發(fā)送的請(qǐng)求和相應(yīng)的回應(yīng)挺据，指的是UA之間的請(qǐng)求和應(yīng)答關(guān)系取具。而VIA中的branch參數(shù)用于確定事務(wù)脖隶。
Transaction(事務(wù)) 事務(wù)發(fā)生于客戶端和服務(wù)器端之間,包含從客戶端發(fā)出請(qǐng)求給服務(wù)器,到服務(wù)器響應(yīng)給客戶端的最終消息(non-1xx message)之間的所有消息. 如果請(qǐng)求是一個(gè)"Invite"消息,并且最終的響應(yīng)是一個(gè)non-2xx消息,那么該事務(wù)包含一個(gè)"Ack"響應(yīng)消息.如果服務(wù)器的響應(yīng)是一個(gè)2xx消息,那么,隨后的ACK是一個(gè)單獨(dú)的事務(wù).
Branch是一個(gè)事務(wù)ID（Transaction ID），用于區(qū)分同一個(gè)Client所發(fā)起的不同Transaction者填。
對(duì)于遵循RFC3261規(guī)范的實(shí)現(xiàn)浩村，這個(gè)branch參數(shù)的值必須用magic cookie”z9hG4bK”打頭. 其它部分是對(duì)“To, From, Call-ID頭域和Request-URI”按一定的算法加密后得到。
這7個(gè)字母是一個(gè)亂數(shù)cookie（定義成為7位的是為了保證舊版本的RFC2543實(shí)現(xiàn)不會(huì)產(chǎn)生這樣的值）占哟，這樣服務(wù)器收到請(qǐng)求之后心墅，可以很方便的知道這個(gè)branch ID是否由本規(guī)范所產(chǎn)生的（就是說，全局唯一的）榨乎。
事務(wù)是由事件（方法）來引起的怎燥，一個(gè)方法（Method）的建立和到來都將建立新的事務(wù)。
SIP Transaction
?一個(gè)SIP事務(wù)處理包含一個(gè)請(qǐng)求蜜暑、零個(gè)或多個(gè)臨時(shí)響應(yīng)和一個(gè)最終響應(yīng)铐姚。
?同一個(gè)事務(wù)處理中，請(qǐng)求和響應(yīng)的To肛捍、From隐绵、Call-ID、CSeq等頭域的值相同拙毫。
?Call-ID用于標(biāo)識(shí)一個(gè)會(huì)話依许，在同一時(shí)刻全局唯一。
?事務(wù)類型：
INVITE Client Transaction
INVITE Server Transaction
non-INVITE Client Transaction
non-INVITE Server Transaction
總的來說缀蹄，
1.對(duì)話和事務(wù)處于信令層峭跳，而會(huì)話處于媒體傳輸層。SIP使用SDP來通知傳輸層（RTP）來創(chuàng)建缺前、增加蛀醉、移除和修改會(huì)話。
2.一般來說衅码，在會(huì)議應(yīng)用中SIP可以通過請(qǐng)求來讓另一方加入已有會(huì)話中拯刁。在這種情況下，新的對(duì)話會(huì)被創(chuàng)建逝段。
3.對(duì)話是end-point對(duì)end-point的關(guān)系筛璧，即真實(shí)的通信雙方，
而transaction 是hop by hop的關(guān)系惹恃，即路由過程中交互的雙方。
理解會(huì)話
一 會(huì)話的初始化
Session用于進(jìn)行媒體流傳送棺牧。當(dāng)一方發(fā)出請(qǐng)求巫糙，而另外一方或多方接受請(qǐng)求并通過信令交互成功后才能建立會(huì)話。
一次呼叫只能建立一次會(huì)話颊乘，但可以建立多個(gè)對(duì)話（Dialog）参淹，因?yàn)榻邮苷?qǐng)求的可能不止一個(gè)醉锄。
1 UAC的處理
1.1 創(chuàng)建初始IVITE請(qǐng)求
初始的IVITE可以帶有消息體。SIP使用提供/回答模型來進(jìn)行會(huì)話協(xié)商浙值，即提供者發(fā)送一些提議的媒體信息恳不，而另一方可以回應(yīng)選擇的媒體信息（不一定在發(fā)送來的媒體中選擇）。而提供/回答的交互是在對(duì)話中進(jìn)行的开呐，所以初始請(qǐng)求可能造成多個(gè)獨(dú)立的對(duì)話烟勋。
而提供/回答模型有多個(gè)限制，如在這個(gè)規(guī)范下筐付，提供和回答媒體信息只能存在于INVITE和回應(yīng)及ACK中卵惦。
作為初始的請(qǐng)求，還有以下限制：(該限制在以后的擴(kuò)展中已經(jīng)被修改瓦戚，詳見draft-ietf-sipping-sip-offeranswer-04.txt)
1）初始提供媒體信息可以出現(xiàn)于INVITE沮尿，否則只能在2回應(yīng)中。
2）如果提供媒體信息在INVITE中较解，回答媒體信息可以出現(xiàn)在1或2回應(yīng)中畜疾，1中的媒體信息只是2的拷貝。
注意印衔，UAC只是處理第一個(gè)提供媒體信息啡捶。
3）如果初始提供媒體信息出現(xiàn)在2回應(yīng)中，則回答媒體信息必須在對(duì)2**回應(yīng)的ACK中当编。
- UAC不能在一個(gè)媒體提供信息正在進(jìn)行處理過程中提出新的一個(gè)媒體提供信息(即不能在沒收到回答媒體信息之前發(fā)送新的提供媒體信息)届慈。
5）在一個(gè)事務(wù)之中UAS只能提供一次媒體信息，而UAC無此限制忿偷。
注：以上的限制僅作用于Content-Disposition頭字段為session時(shí)（如果該字段缺失金顿，則Content-Type字段為application/sdp時(shí)Content-Disposition頭字段為session，其它時(shí)候?yàn)閞ender）鲤桥。
1.2 處理IVITE回應(yīng)
2 UAS的處理
2.1 處理INVITE消息
注：此節(jié)中所說的INVITE消息均為初始化會(huì)話的INVITE揍拆。
如果INVITE中不包含會(huì)話描述，則UAS應(yīng)在2的回應(yīng)中加上會(huì)話描述茶凳，轉(zhuǎn)變?yōu)榱嗣襟w提供信息方嫂拴。
對(duì)于INVITE的處理，UAS可以回應(yīng)處理贮喧、接受筒狠、重定向或者拒絕。
2.1.1 處理
如果UAS暫時(shí)無法回應(yīng)請(qǐng)求箱沦，則可以選擇回應(yīng)處理中消息辩恼，特別是回鈴消息。該類消息可以發(fā)送任意多次，但不是可靠性傳送（無ACK回應(yīng)）灶伊。
代理服務(wù)器在處理事務(wù)時(shí)疆前，如果一段時(shí)間內(nèi)沒有消息回應(yīng)的話則會(huì)取消該事務(wù)，而該類消息可以用于延續(xù)事務(wù)生命（除100外）聘萨。
2.1.2 拒絕
如果INVITE提供媒體信息竹椒，而UAS無法接受的話回應(yīng)488，這類消息應(yīng)該包括一個(gè)Warning消息頭米辐。
2.1.3 接受
2回應(yīng)中應(yīng)該包括Allow和Supported消息頭胸完，可能包括Accept消息頭。這些告訴UAC在呼叫過程中允許的特性儡循。
如果作為回答媒體信息方舶吗，之前的回應(yīng)中沒有回答媒體信息，則在2中必須包含媒體信息择膝。
如果2沒有ACK的回應(yīng)誓琼，雖然建立起了對(duì)話，但也應(yīng)發(fā)送BYE來結(jié)束會(huì)話肴捉。
二 會(huì)話的修改
在《理解對(duì)話》一章中說過腹侣，通過目標(biāo)更新請(qǐng)求可以修改對(duì)話（如修改對(duì)話的遠(yuǎn)端目標(biāo)）。而此節(jié)主要講的是如何修改會(huì)話齿穗，如地址傲隶、端口、增減媒體流等窃页。這些是通過在同一對(duì)話中發(fā)送INVITE消息來實(shí)現(xiàn)的跺株，即re-INVITE（該消息可以同時(shí)修改會(huì)話和對(duì)話）。UAC和UAS都具有re-INVITE功能脖卖。
1 UAC行為
同樣的提供-回應(yīng)模型同樣適用于re-INVITE消息乒省。re-INVITE同樣可以不帶有媒體描述信息，而隨后的處理（包括ACK響應(yīng)）跟普通INVITE一樣畦木。
不過媒體信息提供方應(yīng)該修改會(huì)話版本（如果存在的話）袖扛。
跟普通INVITE不同的是，因?yàn)槭窃谕粚?duì)話會(huì)中發(fā)送的INVITE消息十籍，所以是點(diǎn)到點(diǎn)的交互蛆封。即re-INVITE不會(huì)衍生（fork），Request-URI不是AOR(address of record)勾栗，而是對(duì)話目標(biāo)惨篱。
雖然UA可以同時(shí)建立多個(gè)事務(wù)，但在同一個(gè)對(duì)話中只允許一個(gè)事務(wù)存在围俘，除非舊事務(wù)正處在completed妒蛇、confirmed或者terminated狀態(tài)中机断。
2 UAS行為
如果收到的新的INVITE消息中的CSeq序號(hào)比舊的要小，則回應(yīng)500且?guī)в蠷etry-After消息頭绣夺。
三 會(huì)話的結(jié)束
對(duì)話內(nèi)BYE的發(fā)送可以結(jié)束跟該對(duì)話相關(guān)的會(huì)話（如re-INVITE的協(xié)商失敗，則關(guān)閉新和舊的對(duì)話及會(huì)話）欢揖。而BYE的發(fā)送必須在建立對(duì)話之后陶耍，而建立對(duì)話之前取消則應(yīng)使用CANCEL方法。UAC可以在對(duì)話初始和確定狀態(tài)時(shí)發(fā)送BYE她混，而UAS只能在對(duì)話確定狀態(tài)時(shí)發(fā)送BYE烈钞。而且UAS在對(duì)話確定狀態(tài)時(shí)，只能在收到對(duì)2的ACK或事務(wù)超時(shí)的時(shí)候才能發(fā)送BYE坤按。
一般來說毯欣，呼叫發(fā)起方在最終回應(yīng)未到之前使用CANCEL來結(jié)束，而最后回應(yīng)到了之后使用BYE方法臭脓；被叫方只適用BYE方法酗钞，當(dāng)被叫摘機(jī)之后，2將被產(chǎn)生所以只能等ACK到來之后才能發(fā)送BYE来累。
理解SIP對(duì)話
Dialog是SIP中的一個(gè)關(guān)鍵概念砚作。根據(jù)RFC3261，會(huì)話是兩個(gè)UA之間持續(xù)一段時(shí)間的點(diǎn)到點(diǎn)的SIP連接嘹锁，即是記錄兩者已經(jīng)連接上的相關(guān)內(nèi)容實(shí)體葫录，方便在對(duì)話中請(qǐng)求進(jìn)行識(shí)別和處理。
對(duì)話都是有對(duì)話ID來標(biāo)識(shí)的领猾，包括Call-ID米同，一個(gè)本地標(biāo)簽（From-tag）和一個(gè)遠(yuǎn)端標(biāo)簽（To-tag）。即是說三者確定了某個(gè)對(duì)話的存在摔竿。
對(duì)話中還包括一些對(duì)話中的后續(xù)消息所需的狀態(tài)面粮，包括：對(duì)話ID、本地序列號(hào)拯坟、遠(yuǎn)端序列號(hào)但金、本地URI、遠(yuǎn)端目的郁季、布爾型標(biāo)記“secure”和路由集冷溃。路由集是一個(gè)順序的URI集，指定發(fā)送請(qǐng)求到目的地所需遍歷的服務(wù)器地址梦裂。
會(huì)話的狀態(tài)有初始狀態(tài)和確認(rèn)狀態(tài)似枕。當(dāng)臨時(shí)的相應(yīng)被創(chuàng)建時(shí)，即標(biāo)記對(duì)話的三個(gè)因素剛齊全時(shí)為初始狀態(tài)年柠；而收到2**的最后響應(yīng)到達(dá)時(shí)轉(zhuǎn)為確認(rèn)狀態(tài)凿歼，如果是其他響應(yīng)或無響應(yīng)到達(dá)，初始狀態(tài)終結(jié)。
如下所示
圖1-1 對(duì)話建立過程
創(chuàng)建對(duì)話
UAS i. 路由集由請(qǐng)求的Record-Route頭字段提供答憔，并要保留順序和URI參數(shù)味赃，實(shí)時(shí)更新，如果下一輪的請(qǐng)求中無Record-Route頭字段虐拓，則路由集變?yōu)榭? ii. 本地URI填入回應(yīng)的Contact頭字段 iii.布爾型標(biāo)記“secure”心俗，如果請(qǐng)求基于TLS(傳輸層安全協(xié)議)，則由Request-URI中的secure參數(shù)來提供 iv. 遠(yuǎn)端目的由請(qǐng)求的Request-URI提供 v. From-tag可能不存在蓉驹，則默認(rèn)為空UAC i. 路由集必須為響應(yīng)消息中的Record-Route頭字段的URI列表城榛，保持相反的順序和保留所有的URI參數(shù) ii. 遠(yuǎn)端目的為響應(yīng)消息的Contact頭字段的URI iii. 本地序列號(hào)為請(qǐng)求消息的CSeq頭字段的序列號(hào)值 iv. 遠(yuǎn)端序列號(hào)必須為空，當(dāng)遠(yuǎn)端UA發(fā)送一個(gè)本次對(duì)話中的請(qǐng)求后該值才能確定 v. To-tag可能不存在态兴，則默認(rèn)為空
對(duì)話中的請(qǐng)求
對(duì)話創(chuàng)建后狠持，UA方可能需要建立新的事務(wù)，這時(shí)發(fā)起請(qǐng)求的UA為UAC瞻润，這可能跟對(duì)話創(chuàng)建之時(shí)的角色不同喘垂。re-INVITE是一種對(duì)話中修改目的URI的重新請(qǐng)求。
UAC行為 i. 發(fā)起請(qǐng)求 一個(gè)對(duì)話中的請(qǐng)求消息有對(duì)話所保存的狀態(tài)信息來構(gòu)建敢订。 1. 請(qǐng)求消息的To頭字段的URI必須設(shè)置為對(duì)話狀態(tài)的遠(yuǎn)端URI 2. 請(qǐng)求消息的To頭字段的標(biāo)簽值設(shè)置為對(duì)話ID的遠(yuǎn)端標(biāo)簽值 3. 請(qǐng)求消息的From頭字段的URI必須設(shè)置為對(duì)話狀態(tài)的本端URI 4. 請(qǐng)求消息的From頭字段的標(biāo)簽值設(shè)置為對(duì)話ID的本端標(biāo)簽值 5. 請(qǐng)求消息的Call-ID必須設(shè)置為對(duì)話的Call-ID 而對(duì)話中的其它字段同樣有限制： 6. CSeq序列號(hào)王污。CSeq是按照各自方向嚴(yán)格增1的值，如果為空則設(shè)為初始值楚午。 7. Request-URI由遠(yuǎn)端目的指定 8. Route由路由集指定昭齐，如果路由集為空，則無Route字段矾柜。如果路由集的第一個(gè)URI中包含lr參數(shù)阱驾，UAC必須將Request-URI設(shè)置為遠(yuǎn)端目的URI值；如果路由集的第一個(gè)URI中不包含lr參數(shù)怪蔑，UAC必須將Request-URI設(shè)置為路由集的第一個(gè)URI里覆，且不允許去掉任何參數(shù)，同時(shí)Route頭字段在最后增加一個(gè)目的URI缆瓣。 9.Contact喧枷。對(duì)話中任何一個(gè)更新目的的請(qǐng)求消息包含一個(gè)Contact頭字段，Contact字段內(nèi)URI為對(duì)話的遠(yuǎn)端目的URI弓坞。
如果UAC收到對(duì)目的刷新請(qǐng)求消息的2**響應(yīng)時(shí)隧甚，UAC必須將對(duì)話的遠(yuǎn)端目的URI設(shè)置為存在Contact字段的URI值。如果響應(yīng)為481（呼叫/事務(wù)不存在）或408（請(qǐng)求超時(shí)）渡冻，UAC應(yīng)該終止對(duì)話戚扳；在無對(duì)方響應(yīng)時(shí)也應(yīng)該終止對(duì)話。
2） UAS行為
i. 如果請(qǐng)求To字段存在標(biāo)簽值族吻。UAS內(nèi)核會(huì)計(jì)算與此請(qǐng)求相關(guān)的對(duì)話標(biāo)簽值帽借，同時(shí)與已有的對(duì)話標(biāo)簽值比較珠增，如果匹配則為同一個(gè)對(duì)話中的請(qǐng)求。此時(shí)UAS采用與對(duì)話外請(qǐng)求消息處理規(guī)則相同的流程進(jìn)行處理砍艾；如果不存在匹配的對(duì)話蒂教，UAS可以拒絕（481）或接受這個(gè)請(qǐng)求。
ii.如果遠(yuǎn)端序列號(hào)為空脆荷，則設(shè)置為請(qǐng)求消息中CSeq字段的序列號(hào)值悴品；如果遠(yuǎn)端序列號(hào)存在并大于請(qǐng)求的CSeq序列號(hào)值，則認(rèn)為請(qǐng)求次序顛倒简烘，回500（服務(wù)器內(nèi)不出錯(cuò)）消息。
終止對(duì)話
初始狀態(tài)的對(duì)話不依賴于發(fā)起請(qǐng)求的具體方法定枷，只要收到一個(gè)非2**的終止響應(yīng)即可將其終止孤澎；確認(rèn)狀態(tài)的對(duì)話的終止與確切方法相關(guān)，BYE方法終止一次會(huì)話并終止與其相關(guān)的對(duì)話欠窒。
事務(wù)（Transaction）的理解
Transaction有交易的意思覆旭，Sip是個(gè)事務(wù)型的協(xié)議，因?yàn)樗枰鞑考g互通消息來實(shí)現(xiàn)岖妄。
事務(wù)所處的位置如圖：
圖一 事務(wù)環(huán)境圖
1）事務(wù)處理主要用于處理消息的交互型将，它的實(shí)現(xiàn)使用了狀態(tài)機(jī)。向上它向事務(wù)使用者（TU）提交事務(wù)的觸發(fā)事件（計(jì)時(shí)器超時(shí)和傳輸層消息）荐虐，向下把所要發(fā)送的Sip消息包傳送給傳輸層代為轉(zhuǎn)發(fā)七兜。
2）而在事務(wù)中一定有客戶端和服務(wù)器端，兩者沒有必然的界限福扬。只要是發(fā)起請(qǐng)求的腕铸，在該事務(wù)中充當(dāng)?shù)漠?dāng)然是客戶端，接受請(qǐng)求的必然是服務(wù)器端铛碑。所以對(duì)于代理服務(wù)器來說狠裹，相對(duì)下面的請(qǐng)求來說它是服務(wù)器端，對(duì)于上面來說卻是代發(fā)請(qǐng)求的客戶端汽烦。
事務(wù)分類
事務(wù)根據(jù)類型還分Invite和Non-Invite型涛菠，即邀請(qǐng)和非邀請(qǐng)類型。Non-Invite類型事務(wù)主要處理的是除Invite和ACK類型外的所有Sip信息撇吞。而非Invite里的ACK信息要處理的話就不屬于事務(wù)處理的范圍了俗冻，一般由程序自己把信息發(fā)送給傳輸層直接發(fā)送。Invite需要三次握手梢夯，所以需要的時(shí)間比較長(zhǎng)言疗；而Non-Ivite類型只需兩次握手，要求回應(yīng)時(shí)間短颂砸。
所以由RFC3261規(guī)定噪奄，Sip中主要有四種事務(wù)死姚，對(duì)應(yīng)有四種狀態(tài)機(jī)：
Invite Client Transaction(ICT):
Non-Invite Client Transaction(NICT):
Invite Server Transaction(IST):
Non-Invite Server Transaction(NIST):
其中有個(gè)特別的地方在于：對(duì)于2**回應(yīng)的ACK不屬于ICT的事務(wù)處理范圍
原因在于收到200(OK)的ACK上。
對(duì)于接收到這些ACK的用戶來說勤篮，如果非最后的客戶端都毒，即UA接收到該消息的話將關(guān)掉該事務(wù)再轉(zhuǎn)發(fā)該消息，不再理會(huì)之后的事情碰缔。而收到200的UAC可能把ACK直接發(fā)往真正的UAS账劲，此時(shí)不再通過代理服務(wù)器或重定向服務(wù)器。而前面提到的事務(wù)的概念指的是兩者之間的交互金抡，可此時(shí)UAC要發(fā)往信息不再是之前存在的事務(wù)(交易者已變)瀑焦。所以此時(shí)發(fā)送ACK已不是事務(wù)的范疇了，同樣ACK的重發(fā)和UAS的200重發(fā)都不再是事務(wù)的范疇梗肝，因?yàn)榘l(fā)送200的UAS和接收到200的UAC的事務(wù)狀態(tài)已置為結(jié)束榛瓮。
