在SIP消息中，通常Via頭字段會記錄請求經(jīng)過的各個代理的地址和端口。不過，Via頭中的端口可能不是原始發(fā)送端口，而是經(jīng)過NAT或代理后的端口。因此，直接解析Via頭可能不夠準確。

    模擬SIP終端（網(wǎng)關(guān)）運行在192.168.0.63:9012，而測試程序（test）在9013端口，MicroSIP使用隨機端口如62885。需要區(qū)分來自這兩個端口的INVITE請求，是為了不同的業(yè)務邏輯處理，比如來自測試程序的請求需要特殊處理，而來自MicroSIP的請求則按正常流程處理。 

如何在Go語言中獲取UDP連接的來源IP和端口

    在Go的net包中，當使用ReadFromUDP方法讀取數(shù)據(jù)時，會返回遠程地址（包括IP和端口），這個地址是發(fā)送請求的實際來源地址。因此，在接收INVITE請求時，可以通過檢查這個遠程地址的端口來區(qū)分是來自9013還是62885。

    接下來，需要驗證這一方法的可行性。當測試程序從9013端口發(fā)送INVITE到網(wǎng)關(guān)的9012端口時，網(wǎng)關(guān)在接收時會得到來源地址為192.168.0.63:9013。同樣，如果MicroSIP從62885端口發(fā)送請求，網(wǎng)關(guān)會看到來源端口為62885。因此，通過判斷遠程地址的端口即可區(qū)分請求來源。在Go中，處理UDP連接時，每次讀取數(shù)據(jù)都會返回remoteAddr，其中包含IP和端口。因此，在處理每個INVITE請求時，可以檢查remoteAddr.Port的值，如果是9013，則執(zhí)行特定邏輯；如果是62885，則執(zhí)行另一種邏輯。還需要考慮如何處理其他可能的端口，或者錯誤情況。例如，如果收到來自未知端口的INVITE請求，是否需要記錄或拒絕。需要根據(jù)用戶的實際需求來決定。來自9013的請求需要轉(zhuǎn)發(fā)到MicroSIP，而來自62885的請求可能需要回復特定的響應。

關(guān)鍵步驟:

1. 在接收UDP數(shù)據(jù)時，獲取來源端口。

2. 根據(jù)端口號（9013或62885）決定處理邏輯。

3. 對不同來源的請求執(zhí)行不同的操作，如轉(zhuǎn)發(fā)、記錄或響應。

核心原理

• 網(wǎng)絡層信息：當 SIP 網(wǎng)關(guān)通過 UDP 接收 INVITE 請求時，底層網(wǎng)絡協(xié)議會攜帶發(fā)送方的 IP 地址和端口。
• Go 語言實現(xiàn)：使用 net.UDPConn.ReadFromUDP() 方法讀取數(shù)據(jù)時，會返回 remoteAddr 對象，包含發(fā)送端的 IP 和端口。
• 端口判斷：直接檢查 remoteAddr.Port 的值即可區(qū)分來源端口。