0

I am using SIP between two subnets (192.168.3.0/24 and 192.168.30.0/24) each connected via VPN.

I have a call server on 192.168.3.100, and two phones 192.168.30.118 (Ext. 3128) and 192.168.30.119 (Ext. 3126) on the remote subnet.

The WAN IP on the subnet where the call server is located is 77.0.0.81.

There is an issue with quality of service from the ISP with SIP packets, so instead of the phones communicating over the internet, we wish them to communicate over the site-to-site VPN instead (at no point should SIP and RTP packets leave the VPN).

For the invite packet #10, I can see the following inside the header captured with WireShark (source -> destination):

Source: 192.168.3.100
Destination: 192.168.30.119

INVITE sip:3126@192.168.30.119:5062 SIP/2.0
+ Via: SIP/2.0/UDP 77.0.0.81:5060;branch=z9hG4bK1ddb1569;rport
+ From: <sip:3128@77.0.0.81>;tag=as5c1d47d0
+ To: <sip:3126@192.168.30.119:5062>
+ Contact <sip:3128@77.0.0.81:5060>
+ Call-ID: 132184eda2535423432dde2343243252@77.0.0.81:5060

As far as I understand, once the call has been setup the Call Manager will hand off the conversation between the phones directly with RTP packets.

When this happens, the RTP packets try and out from the rmeote subnet, over the WAN (and not VPN) and try and connect to the address of the WAN router 77.0.0.81:5060.

What is going on here and why does the phone not continue to talk to one another over the VPN via the Call Manager(192.168.30.119 -> 192.168.3.100 <- 192.168.30.118), or even directly (192.168.30.119 <-> 192.168.30.118)?

Why is 77.0.0.81 mentioned in the INVITE packet?

No. Time    Source  Destination Protocol    Length  Info
1   0   192.168.30.119  192.168.3.100   SIP 504 Request: NOTIFY sip:192.168.3.100 | 
2   0.219589    192.168.3.100   192.168.30.119  SIP 464 Status: 200 OK | 
3   15.006336   192.168.3.100   192.168.30.118  SIP 578 Request: OPTIONS sip:3128@192.168.30.118:5062 | 
4   15.041422   192.168.30.118  192.168.3.100   SIP 383 Status: 200 OK | 
5   20.043149   192.168.30.118  192.168.3.100   SIP 508 Request: NOTIFY sip:192.168.3.100 | 
6   20.263419   192.168.3.100   192.168.30.118  SIP 468 Status: 200 OK | 
7   25.212516   192.168.30.118  192.168.3.100   SIP 313 Request: ACK sip:3126@192.168.3.100 | 
8   25.299476   192.168.30.118  192.168.3.100   SIP/SDP 1134    Request: INVITE sip:3126@192.168.3.100 | 
9   25.522622   192.168.3.100   192.168.30.118  SIP 496 Status: 100 Trying | 
10  25.874887   192.168.3.100   192.168.30.119  SIP/SDP 925 Request: INVITE sip:3126@192.168.30.119:5062 | 
11  25.876331   192.168.3.100   192.168.30.118  SIP 512 Status: 180 Ringing | 
12  25.892092   192.168.30.119  192.168.3.100   SIP 366 Status: 100 Trying | 
13  26.01489    192.168.30.119  192.168.3.100   SIP 592 Status: 180 Ringing | 
14  26.234984   192.168.3.100   192.168.30.118  SIP 512 Status: 180 Ringing | 
15  27.900866   192.168.30.119  192.168.3.100   SIP/SDP 782 Status: 200 OK | 
16  28.066616   192.168.30.119  77.0.0.81   RTP 214 "PT=ITU-T G.711 PCMU, SSRC=0x2EB141F2, Seq=7931, Time=0, Mark"
  • 1
    The router/firewall that is handling the VPN could possibly alter the addresses as part of NAT. what kind of device do you use for the vpn? I assume the packet you show was captured at the destination? – lacasitos Jun 18 '14 at 17:41
  • On the call server side there is a Zyxel router, on the local side (where the 2 phones are) is a Mikrotik. A IPSEC VPN tunnel is between both. The techs insist the Zyxel does not have NAT or SIP ALG (the Mikrotik definitely has disabled SIP ALG and NAT) - would the trace indicate the Zyxek is changing packets and not the Mikrotik? – morleyc Jun 19 '14 at 7:36
0

You have use

localnet=192.168.3.0/255.255.255.0
localnet=192.168.30.0/255.255.255.0

in sip.conf in general section.

Also you need ensure no nat applied

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.