2013-03-21 136 views
2

開發一個NAT穿越解決方案,使用resiprocate,它工作正常,但往往SIP INVITE獲得的特別沒在Cisco路由器上SIP INVITE請求端口得到搞砸

1 SIP寄存器由端口發送出去1024

來源:107.108.188.26

目的地:107.108.188.52

用戶數據報協議,源端口:1024(1024),目的端口:SIP(5060)

enter image description here

2. SIP狀態200 OK

來源:107.108.188.52

目的地:107.108.188.26

用戶數據報協議,源端口:SIP(5060) ,Dst Port:1024(1024)

3. SIP/SDP INVITE

來源:107.108.188.52 目的地:107.108.188.26 用戶數據報協議,源端口:SIP(5060),目的端口:SIP(5060)

enter image description here

理想地,送交─通過端口應該是1024在步驟1和步驟3 請點我背後同樣

+0

哪臺機器是你的?機器發送REGISTER/INVITE? – 2013-03-22 09:36:59

+0

Windows 7是機器,INVITE get的失敗,因爲路由器暴露的端口變成默認的一個.. – RDX 2013-03-22 09:38:57

+0

那麼你的是107.108.188.26,路由器的107.108.188.52? – 2013-03-22 09:55:48

回答

0

討論的相同的邀請和得到以下結論

If RFC5626 (Outbound) is not used on the client side, then resip will route INVITEs to the user based on the information in their Path or Contact headers of the registration request. You want to try out a repro setting that forces RFC5626 behaviour in the proxy even if the clients to no support it: 
# Enable use of flow-tokens in non-outbound cases 
# WARNING: Before enabling this, ensure you have a RecordRouteUri setup, or are using 
# the alternate transport specification mechanism and defining a RecordRouteUri per 
# transport: TransportXRecordRouteUri 
EnableFlowTokens = true 
0

跟任何可能的原因您的REGISTER請求中的字段都指定端口5060:sip:[email protected]:5060

這表示您希望在此端口上接收呼叫(即INVITE)。 See the rfc

更改URI的主機部分107.108.188.26:1024代替,如果你希望收到端口1024

+0

我現在意識到你在抱怨INVITE的源端口,而不是目的地。在接收第一個INVITE AFAIK時,這不是您可以在SIP協議中控制的東西。 我認爲唯一的辦法是配置你的cisco路由器使用這個端口。 – Thierry 2013-04-01 21:57:16