Your post, Ian, is very "raw"! Don't quiet follow some of it. But will make a few comments...

I'm pretty sure that you do not need to setup rules on your core - when the process starts 'listening' at a port, this effectively allows communication on that port.Firewall rules on the core are active as soon as you create/edit them, no need to reload.I think you only need 5060 NAT'dI think you will find the media channels are all TCP not UDP - update that rule on your router - this is probably why you are getting no sound on remote initiated calls. The TCP media channel connection from you to the remote end is successful because it is outbound initiated so requires no rules. But the media channel from the remote end to you (ie the sound) is remote initiated and thus cannot connect because there is no valid TCP rule...

Also, you are mapping 10,000-20,000 to only one internal port - 10,000. This is definitely wrong! You need to map them to the same port, because this is exactly what the core is expecting and listening on. During the SIP negotiation, the remote end tells your core that it will initiate a connection on, say, port 12,345.. that is what the core will listen for. You are then mapping the inbound port 12,345 to internal port 10,000. Miss. You probably have to tell your router port 0 so that it maintains the port mapping. ie you want a NAT not a PAT.

Suggest you update this and the TCP, and try again. Failing that, perhaps try UDP after all

Alsamixer is showing nothing muted, (altho headphones colum doesn't show a volume colum,nor can i get it to) audio cds play fine, outgoing calls from orbiter,100% OK

freepbx admin

-COULD NOT RELOAD FOP SERVER

Could not reload the FOP operator panel server using the bounce_op.sh script. Configuration changes may not be reflected in the panel display. Added 1 days , 9 minutes ago ................((last clean install))(freepbx.reload_fop)

No, I'd definitely say it still is a NAT/network problem, personally. The SIP session is working but the media sessions are not. And the fact that it is only inbound strengthens my suspicion. For some reason I feel like your NATs aren't working properly....

The only suggestions I can make at this point are:

1) Using something like netstat and grep out the TCP sessions for an outbound call and then an inbound call and compare. They should be the same (one connection in each direction), but I think you might find only one connection outbound for the inbound initiated call. If so, then definitely a network issue.

2) Look into the option I was talking about for telling the remote SIP server to use the TCP source address for initiating media sessions (rather than the IP address that your SIP server provides during the SIP session, as this will be a private, non-routeable address, so the SIP server will be unable to connect)

thanks for all the help,I've just tinkered with netstat,but I'm way out of my depth (as I'm sure you've noticed ) and I have no idea of the commands to enter :/to search/to redirect to file so I can look thro/ ......while at the same time making/receiving a call... SOooooo unless you're up for some heavy duty handholding ,- I'm going to go away and sulk, -get my nose into Rute , http://rute.2038bug.com/index.html.gz , and try and get up to speed..

And read the manual entry. Essentially, you want to list all the connections coming out of/into the asterisk process. So you can use "ps aux | less" to list all your processes, page through and make a note of the PID (process ID) of any processes that look like they maybe to do with Asterisk. I cannot remember the exact options for netstat, but lets just say they are "-ao", then you can type:

netstat -ao | grep <PID>

And substitute the <PID> with each PID you recorded. This should list any current connections (takes a while to show the UDP ones so wait). Once you find a candidate (should be obvious with the remote end being Internet addresses, and the PID being the same one that the 5060 connection originates/terminates on) you can then compare incoming and outgoing calls in session.

BTW - I am still deeply troubled by the TCP/UDP question. I think I made a big mistake and got them the wrong way around. UDP is typically used when real time delivery is essential but packet loss is tollerable - hence for media protocols. Whereas TCP is used for non-time-critical, but highly reliable delivery conversations. Thus the 5060 SIP session is the TCP one and the 10,000-20,000 ports are the UDP ones! You should take another look at your rules on the router and core

One more thing to check/try, in the web-admin go to Advanced>Configuration>Phones setup, this should take you to the FreePBX interface. Then go to Trunks and select the trunk you're using on the right, scroll down to "Incoming Settings" and under "USER Details" there are some settings you may need to fiddle with, an important one seems to be "nat=yes" but IIRC there are also ways to specify your "outside" or "internet" IP number there. My current settings don't have this but you may need to have them set, unfortunately I can't remember what keyword(s) they were if I remember or figure that out I'll post them. I hope that maybe helps a bit, as colinjones made me think me of those settings in one of his earlier posts here... Maybe the UDP packages are indeed only routed one way but that is a wild stab in the dark on my part as I'm not sure how you'd be able to get a connection at all then.

Zaerc's advice on "nat=yes" definitely rings a bell for me. But from a config file rather than in the web admin. Asterisk has loads of config files, and I believe that option was in the one where I set the option saying to use the packet's IP address. It may even be the option itself - certainly looks like it, there were other commands in there as well I needed to do with the same thing. Can't remember! I have a feeling that it was Zaerc that put me onto this in the first place, so you might want to search his previous posts on the subject!

Don't forget, the NAT issue with SIP is extremely common, it isn't just a LMCE thing. Try googling "sip nat asterisk"... I found a lot of articles and posts this way. Many were just general or old, but some really gave me the pointers to understanding the NATing issue and the options to deal with them...