SIP Match Transactions

在 RFC3261，必須有 Via branch，對特定 UA 發請求時必須產生在時空上是唯一的 Via branch，且開頭是「z9hG4bK」。

RFC2543 沒有唯一的規定，且不會以「z9hG4bK」開頭。

CANCEL 和失敗的 ACK 則是沿用要取消或 ACK 請求的 Via branch。

回應比對 Client Transaction，需符合：

1. Via branch
2. CSeq method (因為 CANCEL 沿用 Via branch，但不同 Transaction)

有可能收到來自不同 server 的多個回應 (基本上 To tag 會不同)，第一個收到的回應會被採用，其它視為重送，這樣並不是錯誤，multicast SIP provides only a rudimentary "single-hop-discovery-like" service that is limited to processing a single response.

請求比對 Server Transaction

• 來自 RFC3261 client，需符合：
1. Via branch
2. Via sent-by (不同 client 可能產生相同 branch。)
3. Method 符合，ACK 是符合 INVITE。
• 來自 RFC2543 client (無 Via branch 或不是)，需符合：

項目	INVITE	ACK 比對 INVITE	其它
Request-URI	v	v	v
To tag	v	response	v
From tag	v	v	v
Call-ID	v	v	v
CSeq	v	number	v
top Via	v	v	?

CANCEL 和失敗的 ACK 會有 Inclusion of the tag in the To header field in the ACK matching process helps disambiguate ACK for 2xx from ACK for other responses at a proxy, which may have forwarded both responses (This can occur in unusual conditions. Specifically, when a proxy forked a request, and then crashes, the responses may be delivered to another proxy, which might end up forwarding multiple responses upstream). An ACK request that matches an INVITE transaction matched by a previous ACK is considered a retransmission of that previous ACK.

Via branch 格式參考：...

Proxy 收到請求可選擇檢查 Loop Detection