dialog
當ua 傳送初始invite
請求後，只有接收到失敗響應才有可能建立dialog
。通過callid，from
域中的tag
引數，to
域中的tag
引數來唯一標識
dialog
。 from
域中的引數由主叫新增，to
域中的引數由被叫新增。
根據dialog的定義，只有當101－199或200訊息中的to域中帶有tag引數時，此時才建立dialog。對通過101－199訊息（目前一般是18×訊息）建立的dialog，我們稱之為早期會話(early dialog).
訊息傳送和定時器保護
無論是client
還是server
方，在定時器和訊息重發的處理上，可分為與
invite
相關的transaction
和與invite
不相關的
transaction
。rfc3261
中定義了
兩個基準定時器
t1＝500ms和t2＝4s
。無論是可靠傳送還是不可靠傳送，當實體傳送訊息（包括請求或響應訊息）後，都會啟動乙個64
倍的t1
定時器（計時器b、h、f），當此定時器終結時，如果沒有收到相應的響應或確認訊息，實體將會清掉相關的transaction
。一、與invite請求
訊息相關的行為（client
側行為）
當sip
實體（包括ua
和proxy
）傳送invite
訊息後，無論是可靠傳送還是不可靠傳送，實體都會啟動 transaction
保護，啟動定時器b
（timer b=64*t1
，如果t1
＝500ms,
則此定時器為32s
）。在不可靠傳送的情況下，實體同時會啟動t1（
500ms
）定時器（a定時器），如果
t1終結了沒有收到任何響應訊息，實體將會重發
invite
訊息，以後的間隔分別為
2t1,4t1,8t1,16t1,32t1,
在此期間，如果收到響應訊息，實體將會終止重發行為。
當定時器b
（timer b=64t1
）終結時，如果實體仍然沒有收到響應訊息，實體將終止該呼叫請求。
二、與invite
訊息相關的最終響應行為（server
側行為）
當被叫使用者應答時，被叫側ua
（uas
）將會向對端傳送200
訊息，表示對invite
訊息的確認，主叫側ua
（uac
收到200
訊息）後，將會傳送ack
訊息，表示收到200
訊息。因此，對server
側來講，當傳送200
訊息後，為了等待ack
訊息，將會啟動定時器h
（timer h=64t1
）。在不可靠傳送的情況下，
server
還會啟動
t1定時器（計時器g）
如果t1
終結，沒有收到
ack訊息，
uas將會重發
200
訊息。以後的間隔分別為
2t1,4t1,8t1,
當時間達到t2（
t2＝8t1）後，後續重發的間隔將一直為
t2。當定時器h
（timer h=64t1
）終了時，如果實體仍然沒有收到ack
確認訊息，實體將會終止該呼叫請求。
其它的最終響應訊息，訊息的重傳和定時器保護也與200
訊息的相同。
三、與invite訊息無關的請求訊息的行為（client
側行為）
其它請求（非invite
請求）訊息，例如info
訊息或bye
訊息，實體接收到最終響應後，由於不需要對最終響應訊息進行確認，因此訊息重發行為上與invite
訊息的重發存在不同。
當實體傳送info
或bye
訊息後，實體將會啟動定時器f
（timer f=64t1
）。如果定時器f
終了時，沒有收到最終響應訊息，實體將會清掉transaction
。在不可靠傳送的情況下，實體同時啟動t1
定時器（計時器e）。如果沒有收到任何響應訊息，實體重發的行為將與invite
訊息相關的最終響應行為（server
）相同。如果在此期間沒有收到臨時響應訊息，實體將會以t2
的間隔重發。
ack 只有在響應非200 ok
時才和invite
一樣，否則與invite
不為同一事務，只屬於同乙個對話。
預設值節
含義t1
500 ms
17.1.1.1
經歷來回時間（rtt）
t24 秒
17.1.2.2
非 invite 請求和 invite 響應的最長重新傳輸時間間隔
t45 秒
17.1.2.2
訊息可保留在網路中的最長持續時間
計時器 a
最初為 t1
17.1.1.2
invite 請求重新傳輸時間間隔（僅適用於 udp）
計時器 b
64*t1
17.1.1.2
invite 事務超時計時器
計時器 d
大於 32 秒（對於 udp）
17.1.1.2
響應重新傳輸的等待時間
0 秒（對於 tcp 和 sctp）
計時器 e
最初為 t1
17.1.2.2
非 invite 請求重新傳輸時間間隔（僅適用於 udp）
計時器 f
64*t1
17.1.2.2
非 invite 事務超時計時器
計時器 g
最初為 t1
17.2.1
invite 響應重新傳輸時間間隔
計時器 h
64*t1
17.2.1
ack 接收的等待時間
計時器 i
t4（對於 udp）
17.2.1
ack 重新傳輸的等待時間
0 秒（對於 tcp 和 sctp）
計時器 j
64*t1（對於 udp）
17.2.2
重新傳輸非 invite 請求的等待時間
0 秒（對於 tcp 和 sctp）
計時器 k
t4（對於 udp）
17.1.2.2
響應重新傳輸的等待時間
0 秒（對於 tcp 和 sctp）
RPC超時機制
linux下rpc支援簡單的超時重傳機制，採用了固定超時時間間隔和固定重試次數。當rpc服務傳送乙個報文時 對應一次遠端過程呼叫 它便啟動乙個定時器 如果定時器在遠端過程呼叫應答到達前期滿，rpc服務便重發請求。程式設計師可以為某個給定應用調整超時時間間隔以及重試次數，但無法自適應。這種簡單機制無法...
haproxy 超時機制
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！code class python option redispatch option redispatch 是否允許重新分配在session 失敗後 option abortonclose 丟棄由於客戶端等待時間過長而關閉連線但仍在haproxy等...
inpu超時機制
input的超時檢測機制跟service broadcast provider截然不同，為了更好的理解input過程先來介紹兩個重要執行緒的相關工作 input的超時機制並非時間到了一定就會 而是處理後續上報事件的過程才會去檢測是否該 所以更相信是掃雷的過程，具體如下圖所示。inputreader執...