Hi guys, sorry for late reply, been busy.

marrold, I'd like to help resolve it as much as I possibly can, however I'm operating in production, so I can't just decide to change things and pull readings etc whenever I want. Production world doesn't work like that.

And to follow up before someone says "you shouldn't do this in production anyway!"... I agree, and we did bench test it as much as was possible. We don't have a spare voip setup that matches this exact layout.

This router is doing OSPF, BGP, etc and is acting as a main gateway on a fiber line. There are too many variables to reproduce, and I have nowhere that I can put it where it is in an exact same configuration. We have gotten it as closely as possible to this situation on the bench, but have not been able to go further. (Hence why the cutover went perfectly, despite this one single issue) My goal this week is to try and get further testing done, and hopefully some *&(*&@ packet captures.

To confirm some of the questions:
- The Cisco ATAs are SPA122 and SPA112. Some are behind a PPPoE connection directly to this router, others are sitting on IP/Ethernet links (Passing through radio bridges). Network configs don't seem to matter. (This makes me feel that this is not an MTU issue either, as it was one of my theories.)

- The config between the upgrades on this router are absolutely identical export/imports. I can flip the firmware between 6.20 and 6.21+ like a switch and it's the only bug/problem that we encounter.

In the end this could be a possible VOIP config issue. But I'm seriously doubting it from what I'm seeing. Perhaps it's an incompatibility with the Cisco units as well, but this seems to occur across all Cisco firmware versions. I confirmed 4 different versions running on ATAs, including the newest version. I also don't believe this is a Cisco issue or a voip config issue as these ATAs run on every other provider, with almost every crazy configuration possible, without any issues. This is the first time I've seen anything actually "break" them.

As I said, I'm going to try and get some packet captures, but it's going to take time.
I just wish I could get a better idea of what could be causing the trigger for this problem between those firmware versions. From what I see, there is nothing in the changelogs that *should* have an effect on this. But something obviously is. Maybe it's not a bug, but it's still something that I need to identify.

With the delay of 6.28 (I prefer as others better updates not fast updates) Will any of the fixes address a universal problem we are seeing and I have seen other comment on with NV2 TCP throughput.

Even with 6.28 RC20 we see the same problem On an NV2 circuit if every interface along the path is not negotiated at 1gig then there is a Dramatic tcp speed drop. From 100Meg in our case to 10 Meg TCP. We see the UDP is still doing fine but tcp is all but halted.

However, this does not accuse with Nstream.

I for one would really rather see the 802.11ac and NV2 bugs fixed and stabilized prior to any new features being released.

With the delay of 6.28 (I prefer as others better updates not fast updates) Will any of the fixes address a universal problem we are seeing and I have seen other comment on with NV2 TCP throughput.

Even with 6.28 RC20 we see the same problem On an NV2 circuit if every interface along the path is not negotiated at 1gig then there is a Dramatic tcp speed drop. From 100Meg in our case to 10 Meg TCP. We see the UDP is still doing fine but tcp is all but halted.

However, this does not accuse with Nstream.

I for one would really rather see the 802.11ac and NV2 bugs fixed and stabilized prior to any new features being released.

Talked to responsible people at the MUM in Prague. There is no solution for nv2 regarding this problem in the near future. He promised some work to stabilize nstreme for ptp. Time frame was 3-6 months.

As we cant live with this situation (I am bored talking to speedtesters every day) we replace ptp with other gear which does not show this problems.

@jdog
Have you tried disabling SIP direct media in firewall settings ?

Yes I did try that as well (Both on and off configurations).

In theory that should only affect the media flow though, and not registrations correct?
My issue is with initial registrations not even happening.

Well the testing on this release have been going on for some weeks now,so i whouldnt call it imature and there is probaly a good reason why it hvaent been relased. As other have sayd its bether they delay it if there is known bug then release a faulty version.
Besides none is foreceing you to update if the version you have installed is working and there is no known security holes.

Nope, you didn't understand. Don't promise or make announcements about things that you're not sure about, this it's not pro

I have a ccr1016-12g , basic configuration ppoe client + routing, but ccr1016-12g stops routing after 10 or 20min aprox, not scan and find it through Winbox, ping no respond, I have to turn off and turn back to work and connected to CCR, nothing is logged, no errors are shown and it otherwise appears to be happy and healthy, where is the problem? , , back to my crs, because this has problems.

SIP helper in RouterOS has some features that other way may be needed to be disabled. Or, if your configuration is running configuration aware of NAT you should be able to disable the helper altogether.

Points of interest to you are these settings:
sip-timeout - TTL of SIP connection, defaults to 1 hour
sip-direct-media - to redirect RTP media streams when NAT is used.

You can try do set to connection-tracking default timeout value and disable direct-media.

.. just an idea:
- some complain about problems concerning PPPoE (duplicating, ..)
- the problems to SIP do not seem related to NAT (some do not use NAT)

Makes me wonder if all those who complain about problems on SIP are using PPPoE (in effect in the changelog PPPoE has been changed)

Dont say "this week" because there is a new week every 7 days!

Yes I did try that as well (Both on and off configurations).

In theory that should only affect the media flow though, and not registrations correct?
My issue is with initial registrations not even happening.

I had similar issue when I replaced my Linux based gateways with CCR and it helped. It's magic.

With the delay of 6.28 (I prefer as others better updates not fast updates) Will any of the fixes address a universal problem we are seeing and I have seen other comment on with NV2 TCP throughput.

Even with 6.28 RC20 we see the same problem On an NV2 circuit if every interface along the path is not negotiated at 1gig then there is a Dramatic tcp speed drop. From 100Meg in our case to 10 Meg TCP. We see the UDP is still doing fine but tcp is all but halted.

However, this does not accuse with Nstream.

I for one would really rather see the 802.11ac and NV2 bugs fixed and stabilized prior to any new features being released.

Talked to responsible people at the MUM in Prague. There is no solution for nv2 regarding this problem in the near future. He promised some work to stabilize nstreme for ptp. Time frame was 3-6 months.

As we cant live with this situation (I am bored talking to speedtesters every day) we replace ptp with other gear which does not show this problems.

So this is really an important failure that needs to be mentioned!
In the last weeks/months I am puzzled why I get more and more clients with speed issues (yes, it looks they don't do nothing else than speedtests and bombard the results to me.... ) and indeed I see link with poor throughputs that were fine months ago.
I blame it on interferences but in some cases nothing is to be found that really worries me...

So now the final word is out (regular member could have filtered that in the forum) that when a NV2 running network is used and units are more and more going to be replaced by gig-able devices you basically break your network down!

You guys are basically saying the backhauls should made nstreme instead of NV2? That would help the issue until you have all units in a link from user to border router replaced by Gigabit units...

Question 1: Nstream only on the backhauls would help? AP-CPE networks can be left in NV2?
Question 2: Does is make a difference where in the whole route fm internet gateway towards end user units are gig or fast ethernet?

Reading this post makes me both happy and very disappointed.

Happy because it finally give me the reason for all my sorrows lately.....
Sad because it seems instead of upgrading my network I am basically downgrading it and MT "doesn't foresee a quick solution??"

This could really be my last push towards a new hardware provider (no, that is not going to be ubnt!) for the whole of my network. Only need to find the money!
I think I look for a bottle and call it a day.....

Forgot to ask; Would setting the gigabit ports to 100Mb manual not solve the issue?
Is a gigabit port set to 100/100 not acting as fastethernet port? Or is there still an issue then?

Forgot to ask; Would setting the gigabit ports to 100Mb manual not solve the issue?
Is a gigabit port set to 100/100 not acting as fastethernet port? Or is there still an issue then?

I have found that the only solution is with negotiation. The problem with that is that when links or auto negotiated and with the problem of poor our negotiation currently plaguing previous firmware. One minute my network will be at one gig and the next it's at 100 meg making the problem worse

Forgot to ask; Would setting the gigabit ports to 100Mb manual not solve the issue?
Is a gigabit port set to 100/100 not acting as fastethernet port? Or is there still an issue then?

I have found that the only solution is with negotiation. The problem with that is that when links or auto negotiated and with the problem of poor our negotiation currently plaguing previous firmware. One minute my network will be at one gig and the next it's at 100 meg making the problem worse

I don't understand what you mean? Can you explain?

Sorry was trying to post from my cell phone.

I have found that the only fix it to have the ports Auto Neg to 1 gig. The problem is I have ports that will flap from 1 Gig to 100 MEg. IN that case the problem is much worse as the customer is getting the speed they purchased but then the speed in general goes down to 10 Meg because my port flapped to 100 Meg.

sip-timeout - TTL of SIP connection, defaults to 1 hour

Hi,
I'm running 6.28 and would like to configure the sip-timeout value.
But can't find it anywhere.

Have gone in via IP/firewall/service ports
and clicked on the sip line.

Can see SIP Direct Media but not sip-timeout.
Went in through both the web interface and Winbox.

It was the same with version 6.23, sip-timeout not there either.
Help, thanks.

Thank you for the update.

(I am posting this here because if it is a valid bug, I do not want it sneaking into 6.28, I would rather it be fixed first)

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 with a CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

I have the sameexact issues. Registration not holding.
I have checked with my VOIP carrier, he told me that the sip request comes from internal IP 192.168.0.xx on the ATA that are not working (cisco spa 112 with latest firmware).
No other config changes occured. For sure it can be a ROS issue.

Thank you for the update.

(I am posting this here because if it is a valid bug, I do not want it sneaking into 6.28, I would rather it be fixed first)

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 with a CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

I have the sameexact issues. Registration not holding.
I have checked with my VOIP carrier, he told me that the sip request comes from internal IP 192.168.0.xx on the ATA that are not working (cisco spa 112 with latest firmware).
No other config changes occured. For sure it can be a ROS issue.

Similar for me, but at random. And indeed only on Cisco spa 112 or 122.
To correct we need to erase all connection rules in both client CPE as the border gateway (because trackin remembers) and we need to power cycle both client wifi router and spa or when spa is in front, the SIP adapter.
After that a unit will register newly with my SIP/VOIP provider under its proper public IP.

If anywhere anything goes wrong, like my main border routers swap, two SIP lines on one public IP, or we take an adapter back form a client to install somewhere else (so a new register add is made at provider) things go wrong.
We have a CCR as border router.
And indeed the VOIP provider tells me the unit gets registred under a local 192.168.xxx.xxx address which can only be the client's wifi router. This should not be happening since the clients network gets srce natted into a Client<===>CPE network, than in a CPE<===>Borderrouter local network and only than into a public IP.

We actually blamed the VOIP provider for their crappy server, but now it looks like.........?

With "connection rules" I meaned to say "registrations in the conn. tracker"

Anyone know what issue "route - using ldp could cause connected routes with invalid interface nexthop" refers to? Any link to any post on the forum discussing this exact fault?

I think I may have found a key to this issue...

If you are "masquerading" your network behind an address using a src-nat action, everything breaks.
If you are "masquerading" your network behind an address using a masquerade action, everything works.

We normally use a src-nat action to masquerade sections of our network behind static IPs that we have for BGP.

As an example we split each /25 of our internal network, into one static IP. We do this using src-nat actions.
This rule is where things break or stop working.

The moment I change the src-nat rule to a masquerade action (It doesn't preserve the same outgoing IP as the src-nat rule, but same concept) everything works.

I think there may possibly be a problem with the connection tracking mechanism in the src-nat rule vs the masquerade rule. Certainly there must be something different between the two.

MT? Ideas?

MT... Ideas?