you have problem to autorize your call , can you test from softphone on a windows pc direct to a isp if you can place call ?

I'll see if i can install a softphone this evening and test some things.With version 804 everything was working fine. All same hardware and credentials, only version 1004 now...So i don't think it's a provider problem.

This is my 'private' external IP of my linuxmce. So not the public ip of my internet router.I suppose that this should be the public ip that tries to reach my sip providers?I can image that the SIP provider simply blocks private adresses.

Can I give somewhere an option that the "linuxMCE 1004" hides or NAT the outgoing ip with my public IP?

idcat_metricvar_metriccommentedfilenamecategoryvar_namevar_val810180sip.confgeneralexternip178.117.103.101I've got the impression that he still use the private one (i've restarted asterisk, rebooted the server)...

insert into ast_config (cat_metric,var_metric,commented,filename,category,var_name,var_val) values(0,19,0,'sip.conf','general','nat','yes') and do test again after insert only need to asterisk -r reload

LinuxMCE after restart you can confirm that on sccpdevice continues 'on'

After a complete reboot of the machine, the value for NAT in sccpdevice is still 'on'.I've also tried a reboot of the phone, but ends up with the sam result.- an internal call towards the provider works.- an external call over that provider fails with 'all circuits are busy'...

I've opened a support ticket by WeePee. A bit bad experience, last time it took 2 weeks before they answered with: "we don't have any issuse, the problem will be at your side".But maybe today is a better day for their helpdesk...

I just hope they don't start to be difficult when we use a 'non-standard' solution. With this i mean that we don't have a full asterisk admin page...

I'm a bit ashamed to write this. But the problem appears to be solved. Apperantly when you change your asterisk installation, the SIP provider sees another 'SIP device' on my end. So there have to be a 'reset User Agent' at the SIP provider side.

Once they did this (apperantly i could do it myself on the user admin page of them), my calls are perfectly routed...

To remember:If a call to the provider itself work (short numbers for testing/accounting...), your setup is OK. The problem is further away...