UAC將會從事務層收到一個請求的響應消息。如果客戶端事務返回一個超時的話，此錯誤看作是一個408（請求超時）響應。

　　UAC處理方式需要注意。如果此UAC收到了一個針對一個請求返回的3xx響應，此請求是在一個dialog中發(fā)送到請求，那么，此UAC處理方式和dialog外部發(fā)送到請求處理方式相同。具體的討論參考Section 8.1.3.4。

　　注意，但是，當UAC嘗試可選地址時，它仍然使用路由組支持此dialog創(chuàng)建請求的 Route頭。

　　當UAC收到一個針對目的地刷新請求的2xx響應時，如果出現(xiàn)了遠端目的地URL的話，UAC必須用此響應中的Contact頭的URL替換dialog的遠端目的地（ remote target URI）。

　　如果在dialog中的請求響應是一個481錯誤（Call/Transaction Does Not Exist） 或者一個408 （Request Timeout）的話，UAC應該結束此dialog。UAC也應該結束完全無請求響應回復的dialog（此客戶端事務層將會通知TU超時的結果）。

　　對于以INVITE發(fā)起的dialogs，通過發(fā)送一個BYE消息來結束dialog。

　　在dialog中發(fā)送的請求就像其他請求一樣，它是一個原子的核心請求。如果UAS接受了一個特別的請求，所有和它關聯(lián)的狀態(tài)修改都要被執(zhí)行。如果此請求被拒絕的話，不執(zhí)行任何狀態(tài)修改的流程。

　　注意，一些請求，例如，INVITE請求，它們會影響一些狀態(tài)改變。

　　UAS將會從事務層收到此請求。如果此請求在To頭中包含一個tag標簽，UAS core會處理dialog身份確認，和此請求保持一致，然后通過現(xiàn)有的dialogs和此dialog進行對比。如果對比匹配的話，那將確認這是一個mid-dialog 請求。在此情況下，UAS首先使用同樣的針對外部dialog請求的處理規(guī)則來執(zhí)行處理流程，具體的討論在Section 8.2中。

　　如果此請求的To頭中包含了一個并且tag，但是，dialog身份確認不能匹配當前存在的任何dialog時，UAS可能已經(jīng)出現(xiàn)系統(tǒng)崩潰然后重新啟動，或者維持現(xiàn)有狀態(tài)，這里，此UAS可能已經(jīng)收到一個請求，這個請求可能是支持了不同的（失敗的）UAS（這些UAS有能力構建To標簽，因此那個UAS可以通過此tag標簽來確認請求，這些標簽是用來支持UAS提供失敗恢復狀態(tài)的標簽）。另外一種可能是，收到的請求可能已經(jīng)執(zhí)行了錯誤路由。基于To tag標簽，UAS可能接受或者拒絕此請求。接受此請求可以為To tag標簽提供健壯性，因此dialog可以維持持續(xù)性，甚至UAS崩潰。希望支持這種能力的UA必須考慮前面的這一點。在處理過程中可能出現(xiàn)一些問題，例如UA重啟時選擇了嚴格遞增CSeq 序列號，重構路由組和接受超出范圍的RTP時間戳和序列號碼。

　　如果UAS想解決此請求的，因為UAS不想重新創(chuàng)建此dialog，UAS必須針對其請求回復一個481響應（Call/Transaction Does Not Exist）狀態(tài)響應碼，并且發(fā)送此響應到服務器事務層。

　　如果此請求沒有通過任何方式修改dialog狀態(tài)的話，此請求可能就會在dialog中收到（例如，OPTIONS請求）。對它們的處理方式就像外部dialog中收到的請求一樣。

　　如果遠端序列號為空，此序列號必須設置為在請求中CSeq頭的序列號值。如果遠端序列號不為空，但是請求中的序列號值低于遠端序列號的話，此請求已經(jīng)排序異常，必須返回一個500（Server Internal Error）錯誤響應碼。如果遠端序列號不為空，并且請求的序列號大于遠端的序列號值，此請求是按續(xù)處理的。本地CSeq序列號大于遠端CSeq序列號一位數(shù)是可能存在的。這本身不是一個錯誤狀態(tài)，UAS應該準備好接收處理類似的請求，這樣的請求中攜帶的CSeq值會高于前一個接收的請求的CSeq值。

　　如果代理對一個由UAC生成的請求進行驗證的話，此UAC需要重新提交攜帶安全消息的請求。重新提交請求將會生成一個新的CSeq序列號。因為UAS從來沒有看到過第一個請求，因此，UA會在CSeq序列號位置提示間斷，這樣的間斷不代表任何錯誤狀態(tài)消息。

　　當UAS收到一個目的地刷新請求時，它必須使用此請求中Contact頭中的URL替換dialog中的遠端目的地URL地址（如果存在的話）。