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

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

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

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

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

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

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

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

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

　　To頭域定義請求的初始接收方，這里的請求是由在From頭域中定義的用戶發(fā)起。 因為可能有呼叫前轉(zhuǎn)或其他代理的操作，初始接收方可能是或不是正在處理此請求的UAS。當這里的To頭域不是UAS的確認身份時，UAS可以使用任何策略來決定它是否接受請求。

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

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

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

　　如果同樣的請求，這些請求抵達UAS多于一次以上的話，這些請求是來自于不同的路徑的話，原因可能是進行了分叉forking處理。這里的UAS處理第一個這樣的請求，然后對其他請求返回響應482（Loop Detected）。

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

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

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

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

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

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

　　未完繼續(xù)……

　

　　　

　　關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享

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

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

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