I have removed all firewall rules, there is no any firewall on router. still its not working...
If that includes also
rules, not just
ones, it cannot work. And unless the router is on the very latest software in 6.40.x or 6.41.x or 6.42.x, disconnect it from the intenet immediately and revert the firewall rules as it may get hacked otherwise. Or install the three following rules to prevent any access from outside at all:
/ip firewall filter
add chain=input action=accept connection-state=established,related
add chain=input action=accept protocol=icmp
add chain=input action=drop in-interface=your-wan-interface-name
Do I read you right that this was not happening before you've upgraded to 6.42.1?
I tried 3.39 also and same issue.
Fine, so it may be time to engage packet sniffing and Wireshark, because otherwise we don't know what exactly happens. You say that it works after router reboot and goes wrong later so it may be that the connection tracking remembers the previous WAN address after it changes, so the responses from the SIP exchange are sent back to the previous address which is not yours any more (normally use of masquerade rule resolves this, dropping all connections once the public IP address changes, but weird things may happen). Or your SIP exchange may ban re-registrations coming from a different address before the previous registration has expired. Or something else may happen.
So it would be fine to
- disconnect the SIP CPE from the network,
- reboot the router
- configure sniffing into a file with the filter set to any interface and IP address of the SIP exchange, press [Apply]
- start sniffing by pressing [Start]
- connect the SIP CPE and let it register (supposingly, successfully)
- wait until the SIP re-registration or call fails
- stop the sniffing, download the file and use Wireshark to see what has actually happened.
But before doing all that, please post the output of
after replacing each occurrence of any public IP address you don't want to reveal with a distinctive pattern like
,
etc. so that the context remains comprehensible. It is possible that there is some misconfiguration in your NAT rules which causes the phones to fight for the connection.