[7.402] Update Killed SIP registrations

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.

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

Can someone write up a "Best Practices" for VOIP and/or SIP?

I have a single VOIP (SIP) line from AT&T (who happen to be discontinuing service so I'll be switching to BroadVoice soon)...

I've had this longer than Astaro had "VOIP Security" features, so I've always just used DNAT and PF to get it to work, and it's been fine, but now I'm wondering if it would be better to use the Astaro VOIP features?

I don't have a list of AT&T's servers so I just did a whois and added their netblocks... I realize this isn't extremely secure...
but, without knowing the exact servers, what should I put in the VOIP settings, the netblocks?

Also, QOS details would be nice.
I _think_ I have it setup right, but if I let BitTorrent go all-out, and then get a phone call, the quality is terrible.
Someone on another thread said that QOS can't modify existing connections; it can only control new ones... is that right?

Thanks!
Barry

Hi Barry,
while your approach might not seem that secure it is quite secure in practice. With one of my ISP (VoIP) I was not able to determine their servers, kept changing on a random basis, so I opened the destination to any. I was surprised who many strange SIP servers my phone attempted to register with. In the end I did the same as you a small ip block and that stopped all the junk.

This is very impressive from my point of view, because I was one of couple who complained Astaro had got it wrong in their first attempt. I stil haven't recreated the qos target groups yet, I am waiting for my wife to make a long overseas call and tell me whether there is any improvement or not, that will decide the qos setup.

Ian M

Well back to the drawing board for me after the above setup working for a day after last changes(still strange that a day later after last changes that it stopped working), The RTP associated traffic with a SIP call the RTP setup failed.
So Do you still require a RTP DNat Rule?

Added the removed RTP PF rule that I removed from above post.

Still testing Not Qute right yet.

Mark. [:)]

Hi Mark,
I have two device definitions, one for each phone and two ISP definitions again one for each ISP networks. I have treated each ISP's SIP site as a number of boxes so they can grow without causing me any grief. One is a dns pool, the other is sub range.

I use the MASQ for for each of my internal networks.

One thing I haven't tried is powering everything off then seeing if the registration works.

Ian M

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

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

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!

[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

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.

Mark_D

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

Regards,
Grant

Mark_D

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

Regards,
Grant

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

The issue with port 4444 being blocked has been resolved.
So hopefully tonight Astaro will be able to login.

Mark

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

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