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

[7.402] Update Killed SIP registrations

Mark_D_01
Hi all
After installing Update 7.402 on to an ASG my VOIP system was unable to register back to the SIP Hosts.
The last change to this configuration was many months ago.
(The ASG is configured to protect a VOIP stand alone network with the following services running on the ASG Box. Intrusion Prot, IM, & SMTP Proxy.)
(and yes I have rebooted all boxes.)

Anybody else having problems?


Astaro any thoughts?


This thread was automatically locked due to age.
Parents
  • 0
    Can you please be more specific?

    I've tested SIP with X-Lite Softphone from sipgate.de and also used sipgate as provider (217.10.0.0/16) and it worked in both directions, outgoing and incoming calls. All this without having to reconfigure anything on X-Lite.

    If you had to manually create packetfilter rules etc., please deactivate them now with v7.402. Also deactivate any 'smart behaviour' on your SIP Clients, the ASG should now completely take care of dynamically opening ports for SIP calls etc.

    What is known being defect since v7.402 is the SIP statistics. Just ignore them for now.
  • 0 in reply to trollvottel
    I have an Asterisk IP PBX with 2 VOIP Trunks.
    These Trunks register to a VOIP supplier via port 5060.
    Prior to 7.402 patch I had in the "SIP Protocol Support"
    In the "SIP server networks" I had the VOIP SIP Servers.
    In the "SIP client networks" I had the Internal VOIP Network (Where the IP PBX and IP Pones Live).
    In the Packet filter rules I allowed Rules that where required to connect to the VOIP Supplier.
    In DNAT I had Rules that allow IP PBX and VOIP Supplier to setup calls.
    With the above configuration, all was OK.

    When Patch 7.402 was installed the IP PBX was unable to register the 2 VOIP Trunks.
    Turning OFF the SIP "SIP Protocol Support" All works again.

    As Most VOIP Providers require different setups to run an IP PBX, is there any detailed documentation on this function.

    Mark
  • 0 in reply to RFCat_vk_01
    I had a support case about some VOIP problems I was having, which cleared up in 7.402, and I asked Astaro if I should be using the VOIP Security features (since it always worked before without)...

    Astaro support says that it is recommended to use the SIP proxy (VOIP Security, I presume).

    Anyways, I'm moving to a new house this weekend, but will switch the configuration soon.

    Barry
  • 0 in reply to BarryG
    Mark's current findings[:)].
    Current SETUP.
    Definitions » Networks » Sip Server is defined as a DNS Group (Interface RED).
    SIP Protocol Support » SIP server networks= Sip Server is defined in DNS Group.
    SIP Protocol Support » SIP client networks= Asterisk BOX (IP PBX).
    Network Security » Packet Filter. Host Asterisk Any VOIP RTP 10000:20000.
    Network Security » NAT. DNAT [Asterisk RTP Voip] Voip Asterisk Traffic selector: Any→RTP 10000:20000→Red (Address) Destination translation:Host Asterisk RTP 10000:20000 Automatic packet filter rule:

    I added the PF and DNAT rule after VOIP stopped working approx 12hours after last change.(ie change done approx 4pm. The Next day at about 1pm all OK at 2:30pm Call setup OK but no Voice.) Rolled back config 3 days earlier enabled above and all working.
    Next is to take out RTP DNAT as per earlier post saying Helper should take care of VOIP.

    Will update after next change.

    The SIP Proxy the you mention Barry can be very misleading as you say.As a SIP Proxy and Registration Server are 2 different services (yet these services can be supplied by the same BOX).
    For SIP Registrations you should use the SIP server supplied by the VOIP Provider.
    IF a SIP Proxy is supplied by the VOIP Provider I would assume you would enter this into SIP Server Network "Area". The Phones or PBX would be required to know about the SIP Proxy into there "Settings".

    Ian that is how I would have said that I had my setup in 7.401 and when patch 7.402 came along I was unable to register to SIP Servers turning off Helper and all OK. From what I understand from the above posts you do not require any MASQ rules as the SIP Helper should that care of all of the SIP VOIP call details.

    Mark
  • 0 in reply to BarryG
    I had a support case about some VOIP problems I was having, which cleared up in 7.402, and I asked Astaro if I should be using the VOIP Security features (since it always worked before without)...

    Astaro support says that it is recommended to use the SIP proxy (VOIP Security, I presume).

    Anyways, I'm moving to a new house this weekend, but will switch the configuration soon.

    Barry


    Good luck on your move, helping a buddy move in a couple of weeks, not a lot of fun, even with help!
  • 0 in reply to BrucekConvergent
    [quote=
    Ian that is how I would have said that I had my setup in 7.401 and when patch 7.402 came along I was unable to register to SIP Servers turning off Helper and all OK. From what I understand from the above posts you do not require any MASQ rules as the SIP Helper should that care of all of the SIP VOIP call details.

    Mark[/quote]

    I have to assume that your ISP is using standard SIP of 5060 UDP/TCP, otherwise the rules change.
    I you are using 5060 then it should automatically hang together with entries in 2 fields of the SIP security setup.

    Ian M
  • 0 in reply to RFCat_vk_01
    I needed to Reboot the Asterisk Box today and I again failed to receive SIP registrations and First call had one way conversation. Returned back to OLD pre 7.402 config and all working again.
    I have submitted a support case.
    Yes SIP = 5060 UDP
    If any body here interested I will add my finding to this post.
  • 0 in reply to Mark_D_01
    Mark_D

    How did you get on with your findings?
    Any solution from the support case?

    Regards,
    Grant
  • 0 in reply to grunta
    Due to an issue with port 4444 being blocked, the Astaro Team have Logged in a couple of times but until the issue with port 4444, 4443 being blocked inbound is fixed, nothing has changed.

    I have now setup a dedicated packet analyser across a span port to help.

    Will update when anything new comes along.
     
    Mark
  • 0 in reply to Mark_D_01
    The issue with port 4444 being blocked has been resolved.
    So hopefully tonight Astaro will be able to login.

    Mark
  • 0 in reply to Mark_D_01
    FYI.
    Astaro have logged in a few more times.
    I have sent packet captures of SIP registrations and other requested captures to Astaro for analysis.

    Until next update.
    Mark
  • 0 in reply to Mark_D_01
    Well findings so far.
    We have found 1 and fixed 1 and found a Gotcha for any one using Asterisk out there.

    I had to use Wireshark to find this out.
    When Asterisk sent the SIP registration packet's to port 5060 to my SIP provider I noticed additional SIP Option Packets Below are the contents of these packets
    Request: OPTIONS sip:sip.gotalk.com SIP/2.0

    Via: SIP/2.0/UDP *.*.*.*:5060;branch=z9hG4bK09cf8c8f;rport

    From: "Unknown" ;tag=as0218471d

    To: 

    Contact: 

    Call-ID: 04e5e6931cb42107269579940974a250@*.*.*.*

    CSeq: 102 OPTIONS

    User-Agent: Asterisk PBX

    Max-Forwards: 70

    Date: Tue, 19 May 2009 01:59:31 GMT

    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

    Supported: replaces

    Content-Length: 0


    Notice the from "sip:Unknown@*.*.*.*", well this returned a Status-Line: SIP/2.0 400 Bad Request SIP Packet.

    The Actual SIP Registration Packet received a SIP Status: 200 OK 

    So the SIP Handler couldn't handle the SIP Registration Option Packets, but it still doesn't explain the inability to handle the normal registration packets.

    Now to those that are interested in why my Asterisk Box was sending these packets.
    In the Trunk Settings under Peer settings I had qualify=yes, but in /etc/asterisk/SIP* I had no SIP settings. So setting qualify=no fixed the SIP Registration Packets. Note this setting of yes was recommended by the VOIP Provider and that this system has been working fine for more than a year now, so I guess we all should be looking a little bit closer at our systems with Wireshark. (Ohh for the time and luxury).

    Hope this helps.
    If anybody after further details ask

    Have just put Beta on. See what happens
Reply
  • 0 in reply to Mark_D_01
    Well findings so far.
    We have found 1 and fixed 1 and found a Gotcha for any one using Asterisk out there.

    I had to use Wireshark to find this out.
    When Asterisk sent the SIP registration packet's to port 5060 to my SIP provider I noticed additional SIP Option Packets Below are the contents of these packets
    Request: OPTIONS sip:sip.gotalk.com SIP/2.0

    Via: SIP/2.0/UDP *.*.*.*:5060;branch=z9hG4bK09cf8c8f;rport

    From: "Unknown" ;tag=as0218471d

    To: 

    Contact: 

    Call-ID: 04e5e6931cb42107269579940974a250@*.*.*.*

    CSeq: 102 OPTIONS

    User-Agent: Asterisk PBX

    Max-Forwards: 70

    Date: Tue, 19 May 2009 01:59:31 GMT

    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

    Supported: replaces

    Content-Length: 0


    Notice the from "sip:Unknown@*.*.*.*", well this returned a Status-Line: SIP/2.0 400 Bad Request SIP Packet.

    The Actual SIP Registration Packet received a SIP Status: 200 OK 

    So the SIP Handler couldn't handle the SIP Registration Option Packets, but it still doesn't explain the inability to handle the normal registration packets.

    Now to those that are interested in why my Asterisk Box was sending these packets.
    In the Trunk Settings under Peer settings I had qualify=yes, but in /etc/asterisk/SIP* I had no SIP settings. So setting qualify=no fixed the SIP Registration Packets. Note this setting of yes was recommended by the VOIP Provider and that this system has been working fine for more than a year now, so I guess we all should be looking a little bit closer at our systems with Wireshark. (Ohh for the time and luxury).

    Hope this helps.
    If anybody after further details ask

    Have just put Beta on. See what happens
Children
No Data