Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 1089 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VOiP belongs here? So I have a question

RFCat_vk_01
I have been extensively testing VOiP with and without the ASG VOiP security.

Without VOiP security enabled, only using PF rules VOiP works.

With VOiP security enabled
1/. I can make the calls,
2/. I hear the ring
3/. I can hear sounds from the far end, 
4/. but I am not heard at the far end.

5/. The PF log shows the incoming traffic at setup time blocked, but shows lots of outgoing packets.

Setup is

phone -> pap2t -> ASG-> mynetfone (VOiP provider)
ASG setup with PF rule pap2t rtp mynetfone allow

My VOiP provider has two sip proxies, but both resolve to the same IP address, but my packets are sent (x.x.x.24) to one IP address and answered by another (x.x.x.20). I have allowed for this by the use of network groups within mynetfone definition.

Any help would be gratefully appreciated.

Ian M


This thread was automatically locked due to age.
  • 0
    Hi there all,

    as there has many requests regarding the SIP proxy/helper not working as expected in V7, we investigated it.

    First of all, the SIP proxy has been replaced by the SIP helper, as the proxy could only handle outbound SIP connects, the helper can handle inbound and outbound SIP connects. Means if you host your own SIP PBX, like many of our customers do, you need the helper.

    We are aware that there still has been issues with the SIP helper under certain conditions.
    I think we found the issue and have a solution:

    In case you connect to bigger SIP-Provider, than they tend to process the RTP-Streams on a different host than the SIP data in order to do load balancing/sharing.

    Our current SIP connection tracking helper assumes that the endpoint he talks to with SIP is also the endpoint he must sent the RTP-Streams to.

    In a case, as we saw in packet dumps, the addresses were different.
    the SIP connection used 217.10.79.9
    the RTP connection used 217.10.68.67
    (you can see this also in the attached screenshot sip_analyze.png)

    this lead to the issue that the kernel expected the RTP connection to come from 217.10.79.9 but it actually came from 217.10.68.67, what you can also see from the packetfilter.log, as than this packet got dropped.

    This should only happen if you use SNAT/Masquerading on the external interface towards the SIP provider.

    For the smaller setups the sip-helper included in 7.003 should work as expected, but connection to bigger sip provider will fail.

    We have a fix for that issue which will be released in one of the next up2dates.

    You can check if you are affected by reading the packetfilter logfile, if the dropped RTP packet comes from a different IP address as where your SIP connection goes to, than you are affected by this issue.

    i hope this clear's things up.

    best regards
    Gert
  • 0 in reply to Gert Hansen
    Gert,
    thank you, that is exactly what I am seeing. I use MASQ only. My current VOiP connection is for outgoing only.

    Ian M