某些4xx 響應(yīng)碼要求UA有特定的處理流程，這取決于method本身。如果收到一個(gè)401 （Unauthorized） 或407 （Proxy Authentication Required） 響應(yīng)時(shí)，UAC應(yīng)該遵從認(rèn)證部分的處理流程Section 22.2 和 Section 22.3 重新通過請(qǐng)求獲取安全消息。

　　如果收到一個(gè)413 （Request Entity Too Large）響應(yīng)（Section 21.4.11），這個(gè)請(qǐng)求包含的消息體大于UAS能夠接收的消息體時(shí)。如果可能的話，UAC應(yīng)該重發(fā)這個(gè)請(qǐng)求，忽略這個(gè)消息體或者重發(fā)一個(gè)小一點(diǎn)的消息體。

　　在以上的例子中，請(qǐng)求重發(fā)都是通過創(chuàng)建一個(gè)新的請(qǐng)求，在新請(qǐng)求中需要做一定的必要的修改才能滿足協(xié)商機(jī)制。這個(gè)新請(qǐng)求重構(gòu)了一個(gè)新的事務(wù)，并且也應(yīng)該和前面的請(qǐng)求具有同樣的 Call-ID和To頭值，但是CSeq 應(yīng)該包含一個(gè)新的序列號(hào)碼，這個(gè)新的序列號(hào)碼高于前面的號(hào)碼。

　　對(duì)于其他的4xx響應(yīng)，還有其他沒有被定義的響應(yīng)，重發(fā)請(qǐng)求可能或者也不可能發(fā)生，這依賴于使用的method和用戶使用場(chǎng)景。

　　當(dāng)UAS處理一個(gè)請(qǐng)求處于dialog外部的請(qǐng)求（outside of a dialog）情況下的請(qǐng)求，規(guī)范規(guī)定了一系列的處理流程，這些流程獨(dú)立于method。Section 12 給出了一個(gè)指導(dǎo)，指導(dǎo)說明了UAS如何通知請(qǐng)求是一個(gè)內(nèi)部的還是outside of a dialog。

　　注意，這里的請(qǐng)求處理是非常恒定的。具體來說，如果接受了這樣的請(qǐng)求，所有和此請(qǐng)求綁定的狀態(tài)修改必須執(zhí)行。如果拒絕了此請(qǐng)求，所有和此請(qǐng)求綁定的狀態(tài)修改不能執(zhí)行。

　　UASs應(yīng)該根據(jù)以下步驟處理請(qǐng)求（開始認(rèn)證處理，檢查method，頭域和以及本章節(jié)其他部分處理）。

　　一旦請(qǐng)求完成認(rèn)證流程（或者跳過認(rèn)證），UAS必須檢查請(qǐng)求的method。如果UAS已經(jīng)識(shí)別到method，但是不能支持請(qǐng)求的method的話，它必須生成一個(gè)405（Method Not Allowed）響應(yīng)消息。生成此響應(yīng)消息的處理流程在Section 8.2.6有介紹。UAS也必須對(duì)這個(gè)405響應(yīng)消息增加一個(gè)Allow頭。這個(gè)Allow頭必須增加一個(gè)列表來表示UAS能夠支持的methods列表。Allow 頭的討論在Section 20.5有討論。如果服務(wù)器端可以支持其中一個(gè)method，則處理流程繼續(xù)進(jìn)行。

　　如果UAS不能理解請(qǐng)求中的一個(gè)頭的話（規(guī)范中沒有定義這個(gè)頭域或規(guī)范不支持這個(gè)拓展頭），服務(wù)器必須忽略這個(gè)頭，繼續(xù)處理消息。如果出現(xiàn)異常的頭域，UAS應(yīng)該忽略異常的頭域值，這些頭值對(duì)于進(jìn)一步處理請(qǐng)求是沒有必要的。

　　To頭域定義請(qǐng)求的初始接收方，這里的請(qǐng)求是由在From頭域中定義的用戶發(fā)起。 因?yàn)榭赡苡泻艚星稗D(zhuǎn)或其他代理的操作，初始接收方可能是或不是正在處理此請(qǐng)求的UAS。當(dāng)這里的To頭域不是UAS的確認(rèn)身份時(shí)，UAS可以使用任何策略來決定它是否接受請(qǐng)求。

　　但是，規(guī)范推薦，UAS接受請(qǐng)求，即使它們不能識(shí)別To頭域中的URI scheme（例如，一個(gè)tel:URL），或如果To頭域不能處理這個(gè)UAS的已知的或當(dāng)前用戶。 如果，在另一方面，UAS決定拒絕這個(gè)請(qǐng)求，UAS應(yīng)該生成一個(gè)響應(yīng)消息和其響應(yīng)狀態(tài)碼403 （Forbidden），并且返回這個(gè)響應(yīng)碼到服務(wù)器事務(wù)層的傳輸。

　　如果，Request-URI定義這個(gè)UAS，它來處理這個(gè)請(qǐng)求。 如果Request-URI使用的一個(gè)scheme不是這個(gè)UAS所支持的scheme，它應(yīng)該拒絕這個(gè)請(qǐng)求，并且返回一個(gè)416 （Unsupported URI Scheme）響應(yīng)消息。如果Request-URI沒有定義一個(gè)地址，這個(gè)地址是UAS愿意為這個(gè)請(qǐng)求所接受的地址，它應(yīng)該拒絕這個(gè)請(qǐng)求，并且返回一個(gè)404 （Not Found） 響應(yīng)消息。典型環(huán)境下，一個(gè)UA會(huì)使用REGISTER method綁定它自己的address-of-record（aor）到一個(gè)具體的contact地址上，contact地址可以是多個(gè)地址形式。UA將會(huì)看到請(qǐng)求中的Request-URI 地址和contact地址相同。接收Request-URIs的其他潛在地址源包括請(qǐng)求的Contact頭和由UA發(fā)送到響應(yīng)地址源，這個(gè)響應(yīng)地址源是創(chuàng)建或刷新dialogs的地址。

　　如果請(qǐng)求中的To頭域中沒有tag標(biāo)簽，UAS core必須對(duì)比檢查請(qǐng)求的將要處理的事務(wù)。如果From tag， Call-ID，和CSeq 完全和將要處理的事務(wù)所關(guān)聯(lián)的匹配，但是請(qǐng)求事務(wù)的話（匹配規(guī)則參見Section 17.2.3），UAS core 應(yīng)該生成一個(gè)482 （Loop Detected）響應(yīng)消息，然后把這個(gè)響應(yīng)傳遞給這個(gè)服務(wù)器的事務(wù)層。

　　如果同樣的請(qǐng)求，這些請(qǐng)求抵達(dá)UAS多于一次以上的話，這些請(qǐng)求是來自于不同的路徑的話，原因可能是進(jìn)行了分叉forking處理。這里的UAS處理第一個(gè)這樣的請(qǐng)求，然后對(duì)其他請(qǐng)求返回響應(yīng)482（Loop Detected）。

　　假設(shè)UAS決定處理請(qǐng)求中的符合規(guī)則的參數(shù)要素，如果Require頭出現(xiàn)在當(dāng)前的消息中，它會(huì)檢查這個(gè)Require頭域。

　　Require頭的作用是UAC用來通知UAS關(guān)于SIP拓展的消息，UAC期望UAS支持這些SIP拓展，UAS能夠正確處理這些請(qǐng)求中的SIP拓展。Require頭的格式在Section 20.32章節(jié)中有進(jìn)一步的描述。如果UAS不能理解Require頭中列出的option-tag 列表的話，UAS必須返回一個(gè)生成的響應(yīng)狀態(tài)碼 420（Bad Extension）。UAS必須添加一個(gè) Unsupported 頭，在這個(gè)Unsupported 頭中列出UAS不能支持的拓展，這些拓展是請(qǐng)求中的Require 頭所列出的拓展。

　　注意，Require 和 Proxy-Require 不能使用在SIP CANCEL請(qǐng)求中或ACK 請(qǐng)求，這里的ACK請(qǐng)求是發(fā)送給non-2xx響應(yīng)消息的。如果這些頭值出現(xiàn)在這些請(qǐng)求中時(shí)，它們必須要被忽略掉。

　　一個(gè)針對(duì)2xx響應(yīng)的ACK請(qǐng)求必須僅包含那些出現(xiàn)在初始請(qǐng)求中的Require和Proxy-Require值。

　　客戶端和服務(wù)器端能夠互相理解雙方所有可選參數(shù)值，規(guī)范所定義的流程可以確�？蛻舳撕头�務(wù)器端的交互將會(huì)快速處理，無任何時(shí)延。如果雙方參數(shù)中，一方不能理解對(duì)方的拓展時(shí)，處理流程放緩，例如上面的示例。因此，對(duì)于客戶端和服務(wù)器端所支持的拓展都能完全匹配的場(chǎng)景中，交互處理流程會(huì)相對(duì)較快。如果需要保存一個(gè)雙向處理，通常需要協(xié)商機(jī)制來完成。另外，當(dāng)客戶端需要支持的功能，但是服務(wù)器端不能理解此拓展功能的話，此頭可以移除一些帶歧義的拓展功能支持，例如呼叫處理方面的功能，這些功能可能僅是呼叫流程末端系統(tǒng)感興趣的功能。

　　假設(shè)UAS理解所有客戶端請(qǐng)求的拓展功能，然后UAS檢查消息體的內(nèi)容和頭域。如果其中任何消息的類型（由Content-Type表示），語言（由Content-Language表示）或者 編碼（由Content-Encoding表示）不能被支持，并且body 部分不是一個(gè)可選的值（由 Content-Disposition頭表示），UAS必須拒絕這個(gè)請(qǐng)求，返回錯(cuò)誤狀態(tài)響應(yīng)碼415 （Unsupported Media Type）響應(yīng)。這個(gè)響應(yīng)必須包含一個(gè)Accept頭的列表，列表表示UAS可以理解的消息體類型，在事件中包含UAS不能理解的消息體類型。如果UAS不能理解請(qǐng)求做包含的內(nèi)容解碼，UAS響應(yīng)中必須包含一個(gè)UAS可接受的Accept-Encoding 頭列表，列表中列出UAS所支持的解碼方式。如果UAS不能理解請(qǐng)求的頭中列出的支持的內(nèi)容語言，響應(yīng)中必須包含一個(gè)Accept-Language頭，這個(gè)頭列出UAS所支持的語言。除了檢查以上這些類型以外，消息體處理還依賴于method和類型。更多關(guān)于具體內(nèi)容頭的處理，參考Section 7.4 ，還有 Section 20.11 到20.15。

　　未完繼續(xù)……

　

　　　

　　關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享

　　Asterisk freepbx，F(xiàn)reeSBC技術(shù)文檔：www.freepbx.org.cn

　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com

　　Asterisk / FreePBX / FreeSBC中國(guó)合作伙伴，官方qq技術(shù)分享群（3000人）：589995817