還有一種可能就是服務(wù)器端同時(shí)對多臺不同的終端不同用戶(hù)進(jìn)行呼叫。但是，如果有多臺終端被同時(shí)呼叫時(shí)，代理服務(wù)器如何才能知道哪臺是終端第一個(gè)應答的呼叫，如何處理那些沒(méi)有應答呼叫的終端或者稍晚應答的呼叫的終端。為了回答這個(gè)問(wèn)題，我們需要詳細地分析關(guān)鍵參數-branch為大家進(jìn)行比較詳細地剖析。
1、Forking呼叫背景知識
在前面的很多文章中筆者已經(jīng)討論過(guò)Forking 呼叫的具體流程，為了讓讀者能夠快速了解Forking呼叫，我們再次做一個(gè)簡(jiǎn)單的回顧。Forking呼叫事實(shí)上是相對于并行按序呼叫來(lái)說(shuō)的。一端發(fā)起呼叫后，通過(guò)SIP服務(wù)器端可以同時(shí)對多臺終端進(jìn)行呼叫，首先接聽(tīng)的開(kāi)始通話(huà)。其他終端呼叫則被取消。
在具體的應用環(huán)境中，用戶(hù)可以發(fā)起一個(gè)呼叫振鈴組，或者分機隨行等功能。如何實(shí)現這個(gè)具體的功能，每個(gè)廠(chǎng)家的產(chǎn)品不同可能配置命令有所不同。在A(yíng)sterisk中，可以通過(guò)以下語(yǔ)法來(lái)實(shí)現同時(shí)對三臺SIP分機進(jìn)行呼叫。
exten => s,1,Dial（SIP/s1&SIP/s2&SIP/s3,10）
以上語(yǔ)法簡(jiǎn)單來(lái)說(shuō)，就是通知系統同時(shí)呼叫分機s1，s2,和s3。
2、Branch定義和神奇的七個(gè)字符
在進(jìn)行具體的討論之前，我們這里需要介紹一下branch。在RFC3261中，branch是這樣定義的：
The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server.
https://www.rfc-editor.org/rfc/rfc3261.txt
通過(guò)以上規范，我們可以理解，branch是用來(lái)確認事務(wù)的，并且branch會(huì )被使用在終端和服務(wù)器端。另外，每個(gè)branch id必須是唯一的，以字符串“z9hG4bK”開(kāi)頭。在RFC3261規范說(shuō)明中，僅簡(jiǎn)單說(shuō)明使用這7個(gè)神奇的字符這是為了防止和rfc2453的規范沖突，rfc2453不使用這個(gè)值。為了進(jìn)一步了解為什么使用這七個(gè)字符，筆者也查閱了很多文章和論文，沒(méi)有看到為什么使用這七個(gè)神奇字符的具體的原因。
3、Fork初始化
根據我們上面介紹的關(guān)于分叉處理的機制，我們可以看到，一般來(lái)說(shuō)，分叉呼叫大概的流程是這樣的。一個(gè)SIP終端發(fā)起呼叫，通過(guò)了SIP服務(wù)器以后，分別對兩個(gè)終端進(jìn)行了呼叫，并且分別進(jìn)行分叉處理。現在的問(wèn)題是，如果第一個(gè)分機首先應答了這個(gè)呼叫后，服務(wù)器端怎么才能知道哪個(gè)終端執行了應答。
為了解決這個(gè)問(wèn)題，我們需要借助branch id來(lái)處理。具體的語(yǔ)法格式如下：
Via:SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 ;branch=z9hG4bK77asjd
https://www.rfc-editor.org/rfc/rfc3261.txt
4、在呼叫時(shí)插入branch id
SIP服務(wù)器端在對其他分機進(jìn)行呼叫時(shí)，分別添加了自己的branch id號（這里簡(jiǎn)化表達），并且生成了一個(gè)專(zhuān)門(mén)對每一個(gè)終端的branch id。這樣就確認了終端和服務(wù)器端的關(guān)系。
當第一個(gè)SIP分機首先接聽(tīng)時(shí)，服務(wù)器端收到200 OK，服務(wù)器端會(huì )根據branch id來(lái)確定是第一個(gè)分機的應答。應答以后，雙方開(kāi)始其他的流程處理。
5、取消其他沒(méi)有接通的呼叫
接通了雙方通話(huà)以后，接下來(lái)，SIP服務(wù)器端會(huì )根據branch判斷其他未接聽(tīng)的終端，分別對其終端發(fā)送Cancel。
這里，讀者需要注意，SIP 服務(wù)器發(fā)送到Cancel仍然使用的是同樣的branch id。如果是這樣的話(huà)，這里的處理是否和RFC3261的定義沖突？因為一般情況下，這個(gè)branch id是唯一的。答案顯然不是。在RFC3261中還有這樣的一個(gè)規定：
The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels.
https://www.rfc-editor.org/rfc/rfc3261.txt
因此，在Cancel請求發(fā)送時(shí)，仍然可以使用原來(lái)同樣的branch id，否則SIP服務(wù)器端沒(méi)有辦法根據其唯一性來(lái)取消其他服務(wù)。
6、總結
通過(guò)以上介紹，筆者可能基本了解了如何處理分叉呼叫的機制。其過(guò)程主要借助了branch id的方式來(lái)確認每個(gè)分支的身份確認信息。服務(wù)器端在Via頭中增加一個(gè)branch id來(lái)識別其處理身份。在遠端用戶(hù)應答率呼叫后，服務(wù)器端可以通過(guò)ID來(lái)識別其終端，然后轉發(fā)會(huì )呼叫方進(jìn)行下一步處理。如果沒(méi)有在第一時(shí)間應答的用戶(hù)則會(huì )根據id發(fā)送Cancel請求。
以上過(guò)程就是一個(gè)簡(jiǎn)單的分叉呼叫的流程，另外，筆者提醒讀者，需要特別注意到還有一個(gè)branch id的七個(gè)神奇字符的問(wèn)題，筆者沒(méi)有看到比較權威的解釋。在處理Cancel時(shí)，用戶(hù)一定要注意，Cancel需要使用同一branch id，而不是再使用新的唯一的id。
參考資料：
https://andrewjprokop.wordpress.com/2015/04/07/multiple-registration-and-call-forking-with-sip/
https://tools.ietf.org/html/rfc3261#section-8.1.1.7
https://mailarchive.ietf.org/arch/msg/sip/_5zV4Vh41XqgTBYfpzZP19fLpOM
