服務器應當能夠接收任何IP地址、端口和協(xié)議的請求，通過對該服務器的SIP或者SIPS URI的DNS進行查找，得到這個服務器的地址然后進行連接和請求發(fā)送。

    Handing out包括在Register請求、轉發(fā)應答的Contact頭域中的添加URI、應答的Record-Route頭域中添加一個URI字段，URI字段可用通過放在網頁上被handing out讀取。

    對于服務器監(jiān)聽UDP的任何端口和界面，需要在TCP上同時進行監(jiān)聽；如果服務器在TCP上進行監(jiān)聽，那么不一定需要在UDP上同時進行監(jiān)聽。

    當服務端事務從任意一個通訊層上接收到一個請求時，必須檢查Via字段的sent-by參數；sent-by參數的主機部分包含一個主機名或者包含的IP地址和包的源地址不一致時，服務端需要添加received參數到Via字段中；received參數包含收到包的源地址。由于服務端一定要把應答信息發(fā)送給收到請求的源地址，received參數用于幫助服務端通訊層發(fā)送應答。

1. 安全與綁定策略補充

(1) 接口綁定限制

安全實踐：雖然理論上服務器可監(jiān)聽所有接口（0.0.0.0或::），但生產環(huán)境中通常僅綁定特定 IP（如內網/公網接口），以減少攻擊面。

防火墻規(guī)則：需開放 SIP 標準端口（UDP/TCP 5060，TLS 5061），并限制來源 IP 范圍（如僅允許運營商或合作伙伴 IP）。

(2) 協(xié)議優(yōu)先級

傳輸層選擇：

UDP：適用于低延遲場景，但需處理丟包重傳（需實現應用層重傳邏輯）。

TCP：確?？煽總鬏敚m合大消息（如攜帶 SDP 的 INVITE）。

TLS（SIPS）：強制加密，需管理證書鏈（如 Let's Encrypt 或私有 CA）。

2. DNS 解析的深入要求

(1) NAPTR 與 SRV 記錄

SIP 服務發(fā)現：客戶端通過 DNS NAPTR 記錄確定支持的傳輸協(xié)議（如 _sip._udp, _sips._tcp），再通過 SRV 記錄解析服務器地址和端口。

負載均衡：SRV 記錄的權重（priority/weight）支持多服務器流量分配，需配合健康檢查實現故障轉移。

(2) 多宿主與地理路由

Anycast DNS：全球部署的服務器可使用 Anycast IP，通過 BGP 路由將請求導向最近節(jié)點。

DNS TTL 管理：設置合理的 TTL（如 300 秒），平衡故障恢復速度與 DNS 查詢開銷。

3.Via 字段處理的完整規(guī)則

(1) received 與 rport 參數

NAT 穿透：當客戶端位于 NAT 后時，Via 的 sent-by IP 可能與實際源 IP 不同。

received：記錄請求的實際源 IP。

rport：記錄請求的實際源端口（若與 sent-by 端口不符）。

響應路由：服務器發(fā)送響應時，優(yōu)先使用 received:rport 作為目標地址，而非 sent-by。

(2) Via 棧操作

代理服務器行為：每經過一個代理，Via 頭添加當前節(jié)點信息，形成“棧”結構。

響應回傳：響應按 Via 棧逆序逐跳返回，確保路徑一致性。