Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 18198 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

SIP/TRP Proxy Details

tmbm50
I'm hoping someone can give me some more details on the SIP/RTP proxy features of ASG 7.  My emails to Astaro have gone unanswered so I'm hoping the community will pick up their slack.  Ok. enough intro.

My business currently uses SIPX (a sip based pbx) for VOIP.  We will soon be doing a SIP trunk to an external provider for our outbound/inbound calls.  However, the SIPX server is behind a NAT/Firewall and moving to a public ip is not possible.  For sip to work behind NAT we either need to Port Forward every port under the sun or use a Firewall that has a sip proxy built in.  

The Astaro literature states it has a SIP/RTP proxy but the details are slim.  Looking at the admin guide also show few details about deployment scenarios.  The docs seem to be geared more for a UserAgent (UA) behind the nat connecting to a provider like vonage.  Is that the only scenerio that works?

Does anybody have experience with a SIP server behind Astaro? I downloaded the demo and the options are pretty slim.  And I'm not seeing the options I would expect from a true SIP/RTP proxy compared to something like the Ingate Siparator.  For example, on outbound calls the sip proxy doesn't need much configuration but for inbound connections/registration the SIP proxy needs to know which domain and sip server to forward calls to.  I don't see that anywhere in the admin page.

Any help would be appreciated.  If astaro works with sip as we will use it replace our current Bordermanager firewall.

Thanks,
Tim


This thread was automatically locked due to age.
Parents
  • 0
    It's a shame that Astaro dropped the SIP proxy from 7.  I hope it makes it's way back in.  I'm also disappointed to hear that Astaro doesn't respond to anyone.  You'd think they would take the time to respond when someone is considering spending a few thousand dollars on their hardware.  That alone may make influence us to seek a difference solution.

    I do wonder if anyone's been able to hack a sip proxy onto the ASG v7.  I'm sure it would void the support but it sounds like they aren't good with support to start with.

    -tim
  • 0 in reply to tmbm50
    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
Reply
  • 0 in reply to tmbm50
    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
Children
  • 0 in reply to Gert Hansen
    Unfortunately I have to disagree with you Gert. My SIP and RTP connections are pointing to the same IP-number from my SIP-provider and all UDP-packets are dropped!  Isn't so that the SIP-protocol looks for TCP-packets instead of UDP-packets ??? I think that there is the problem also.....
  • 0 in reply to PabloDiablo
    I forgot to add that the SIP uses UDP and the ASG SIP security seems to handle it, in that the packets were grey and UDP in the packet filter log.

    Ian M
  • 0 in reply to RFCat_vk_01
    Why are the UDP-Packets dropped when I make a call? If I open Packet Filter Live Log, it's dropping the UDP-packets like hell and got to close the window because it can't handle the packets anymore.
  • 0 in reply to PabloDiablo
    Fobe,

    Why are the UDP-Packets dropped when I make a call? If I open Packet Filter Live Log, it's dropping the UDP-packets like hell and got to close the window because it can't handle the packets anymore.


    did you create a definition with UDP instead of the TCP that comes default with the ASG? Add that to the VOiP group definition and use that group definition in your packet filter rule until the SIP helper fix is released. (wrong answer)

    Check the packet filter log to see what the address is that is being dropped, if like me your VOiP provider keeps adding new devices so I have to add extra address to the RTP packet filter destination list.
    I have a SIP proxy address (DNS) and 2 return addresses that are not in the VOiP providers DNS, no name.

    Ian M