Then you don't have a SIP problem, you have a routing problem. Double, check the subnet mask on the phones (and also the default gateway) and I suspect you may find your problem -Adam
Mark Tinka <[email protected]> wrote: >On Sunday, June 02, 2013 05:29:21 PM Jeremy Porter wrote: > >> If the phones don't work over the VPN, and, the VPN is >> allow all, its unlikely to be pfSense. > >My thoughts too, especially since X-Lite works fine across >this path. > >> However SIP is >> tricky, in that as a protocol is has very limited >> support for NAT. PfSense doesn't have a SIP application >> layer gateway so we don't modify the settings. However >> some SIP devices try to be smart, and have a "NAT" >> setting on them. Some might even try to use >> STUN/TURN/etc to discover their external IP. >> SIP supports a VIA header which can be a public IP, or a >> private IP, depending on how you connect. Your phone >> system will have this feature as well. Asterisk's based >> products (Switchvox,etc) have a "local networks" setting >> that is basically a do not nat, feature, which needs to >> be turned >> on (all your vpn networks will be "local" so that they >> are not NATted, (non "local" networks are consider >> public Internet). > >We tried this already and didn't have much luck. We are >still playing around with it, as with you, there is little >reason to believe pfSense is doing something to the traffic >from the hard phone. > >On the other hand, the local pfSense sees traffic from the >phone, but the remote one doesn't. Using X-Lite, both >pfSense's see traffic. > >> And thats just SIP, you have two other protocols to worry >> about: RTSP, and provisioning. I'm not aware of any >> devices that provision directly over SIP, most use >> tftp/ftp/http to provision. > >Digium initially use 5060/udp for provisioning, and them >move to 5062/udp to complete it. > >RTP defaults to 10000/udp - 20000/udp, but we're nowhere >near that stage yet. We're just trying to get provisioning >and registration going. > >> A lot of devices support >> setting a dhcp server option to point to a provisioning >> server. Might be better that way. > >You refer to DHCP Option 66. > >In the case of provisioning, it simply does the same thing >you're doing on the phone, i.e., telling the phone where to >find a SIP server. > >> Since you don't mention the specific make/model of phone >> its hard to suggest exactly what is wrong, but its >> probably the NAT on the switch and phones >> being mismatched. > >The phones are Digium's own D40 and D70 hard phones. > >> You should be able to easily tell, by doing of packet >> capture of the SIP (5060) traffic and looking at the SIP >> headers. > >A packet capture on the local pfSense shows the phone >sending traffic toward to the remote SIP server. The issue >is that the remote pfSense never sees that traffic to hand >it over to the SIP server. > >Again, everything looks nice and clean when using X-Lite. > >IP settings on the phone are very basic. We can confirm the >phone get a good DHCP assignment, and it is, in fact, >pingable from the remote LAN. So this looks like an issue >with SIP and not IP to/from the phone. > >> SIP itself is really only used for call setup, and >> presence notification. Media transfer runs over other >> protocols, and provision is phone depended. > >Switchvox do things a little differently. 5062/udp is used >for provisioning when running Digium's own phones. There are >a bunch of other ports used for other features on Switchvox, >but that's at a much higher level, and fairly specific to >Switchvox. > >Will keep hacking it and report back for the archives. > >Mark. > >_______________________________________________ >List mailing list >[email protected] >http://lists.pfsense.org/mailman/listinfo/list _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
