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 helper: SIP works, but no RTP...

Hi there,

after years of using Astaro (since V3.1) I have now a problem which
I have not solved yet (Version 9.204-20).
End of this week our phone line will be switched to IP (VoIP). Therefor I prepare the UTM for this day and want to test it with a sipgate.de account. The internal PBX is a Starface. VoIP Support is enabled and all Sipgate servers and the IP of the local PBX is entered correctely at the VoIP Support
page. (Strict mode)
Internet access with PPPoE from the UTM.

With wireshark I inspected the packets on the pbx going to the UTM:
registering and dialing is working as expected. Phones are ringing but no tone is going in any direction!
The Ports stated in the SIP-Session description are used by the pbx for outgoing RTP. But UTM is blocking them all. (Default DROP)
Strange thing: Outgoing packets are marked as 'UDP' - Default DROP ; Incoming packets are marked as 'RTP' - Default DROP. Wireshark shows the outgoing packets as RTP and not as UDP... Is the helper not recognising the RTP packets correctely?

If I enter a Firewall rule (PBX -> AllSipgateServer -> Any) everything works fine - but I do not want to have an 'ANY' Rule in the list...

What's going wrong here?

Thanks for your help in advance

Marc


This thread was automatically locked due to age.
Parents
  • I've checked back with the developer responsible for the SIP helper. His reply is that the observed behavior is the expected behavior, as is also documented in the Sophos UTM Online Help.

    Expectation mode: Select how strict the initializing of communication sessions should be:
        

    • Strict: Incoming calls are only allowed from the ISP's registrar, i.e. the IP address the REGISTER SIP message was sent to. Additionally, the UTM only accepts media (voice or video) data sessions from signaling endpoints, i.e., the devices that exchanged the SIP message. Some providers send the media data from another IP address than the SIP message, which will be rejected by the UTM.
    • Client/server networks: Incoming calls are allowed from all clients of the defined SIP server or client networks. Media data is accepted from another sender IP address than the one that sent the SIP message, provided that the address belongs to the defined SIP server or client networks.
    • Any: Incoming calls as well as media data are permitted from anywhere.



    If you still believe there is some issue with the SIP helper please provide a PCAP for the SIP traffic (at least TCP port 5060) and the list of failed expectations.

    With this explanation given, Mantis #32548 is now considered resolved/answered.

    Best regards,
    mlenk
Reply
  • I've checked back with the developer responsible for the SIP helper. His reply is that the observed behavior is the expected behavior, as is also documented in the Sophos UTM Online Help.

    Expectation mode: Select how strict the initializing of communication sessions should be:
        

    • Strict: Incoming calls are only allowed from the ISP's registrar, i.e. the IP address the REGISTER SIP message was sent to. Additionally, the UTM only accepts media (voice or video) data sessions from signaling endpoints, i.e., the devices that exchanged the SIP message. Some providers send the media data from another IP address than the SIP message, which will be rejected by the UTM.
    • Client/server networks: Incoming calls are allowed from all clients of the defined SIP server or client networks. Media data is accepted from another sender IP address than the one that sent the SIP message, provided that the address belongs to the defined SIP server or client networks.
    • Any: Incoming calls as well as media data are permitted from anywhere.



    If you still believe there is some issue with the SIP helper please provide a PCAP for the SIP traffic (at least TCP port 5060) and the list of failed expectations.

    With this explanation given, Mantis #32548 is now considered resolved/answered.

    Best regards,
    mlenk
Children
No Data