I think those messages and the one on FOP are normal (I remember getting them, anyway!) so red herring...
I haven't responded because its a while since I did this and I am by no means an expert. You would be far better to entice a response from Zaerc, as he is. Maybe get onto the IRC channel and chat to him, he is only 1 hour ahead (CET), so it should be easy for you.
From me, if you are still having the issue with being able to place calls but not receive them, then that is definitely a networking issue. SIP and the media channels do NOT like NATs. This is a very common issue for the reasons I explained. The far end initiates a call through SIP (which you have correctly NAT'd to your core), so both ends are expecting a call setup. But the far end actually initiates the media channel, and it does so by selecting an ephemeral/tcphigh (random, free, > port 1024) port number at its end and the ephemeral port given to it by your core, during the SIP session, as the destination port. Of course, the VoIP server on your core is now expecting an inbound media connection on that port, but your broadband router knows nothing about it!! So the session ACKs will come in to your router's external IP address on this port and the router will think "so what? Drop!" This is why it is messy. There is no easy way to tell the router to expect this connection and NAT it. There are lots of different ways to achieve it, but I will give you the simplest and dirtiest.
So long story short: You will need to do a little research for this stuff. There is an Asterisk config file somewhere on your system where you can specify the maximum range of ports that SIP is allowed to choose the near-end ephemeral port from. By default the kernel will choose a new port between 1024-65535, you can then limit this. The suggested range is 10,000-20,000 from memory, and I suspect that this might actually be already set in that file by default in 0710. If not, set it.
Then setup a NAT/virtual server/PAT (whatever your broadband router calls it) to address translate any inbound connections on ports 10,000-20,000, to your core on the same port (ie, it will translate the IP address and leave the port number intact). This will get the connections through.
There is just one more option that I recall. Again, somewhere on your Asterisk a config file dictates how part of the SIP negotiation is done. This basically means that when your server talks to a remote SIP server, it will tell that SIP server either "use this IP address for me" or "read my IP address from the session". This is important, because if your SIP server uses the former option, it will be telling the remote SIP server to connect to it using your core's external IP address, which is almost certainly a non-public IP address such as 192.168.1.5, for instance. Thus the remote server will not be able to connect. You need to use the latter option (if this isn't the default, can't remember) as this will tell the remote SIP server, when initiating the media channel, to use the source address in the SIP packets as the destination address for the media channel(s). When the SIP packets leave your core, then will of course have your non-public IP address still. However, once they pass through your broadband router and get NAT'd, they will get your correct public IP address. This is the one that the remote SIP server will read and use to connect back to you the media channel.
Naturally, all of this is vastly easier if you have a static IP address from your ISP. If not, there are other options to make dynamic IPs more stable, but I will only dredge up that memory if you indeed have that issue.
