Trunk wont register with provider

This worked for me.

Allow anonymous inbound sip calls under general settings set to yes

TrunkName: whatever

Outgoing Settings:
PEER DETAILS:
username=SIPUSER
type=peer
secret=XXXXXX
nat=yes
insecure=very
host=yoursipprovider.com

Usercontext: from-trunk
Incomming Settings:
type=user
secret=xxxxx
nat=yes
insecure=very
host=yoursipprovider.com
context=from-trunk

Register String:
sipuser:secret@yourproxysipprovider.com

please note, sometimes the SIP providers give a specific proxy DNS to use in registration string.

suggest using this basic config to get it running then focus on locking it down

Also, ensure your dialplans direct to this trunk in outbound.

K

What in "/var/log/asterisk/full " log file about your registration?

here is the end of the log file
[Oct 13 14:00:02] NOTICE[3594] chan_sip.c: -- Registration for 'genocide@166.70.242.163' timed out, trying again (Attempt #28)
[Oct 13 14:00:02] VERBOSE[3594] logger.c: -- Got SIP response 423 "Interval Too Brief" back from 166.70.242.163
[Oct 13 14:00:22] NOTICE[3594] chan_sip.c: -- Registration for 'genocide@166.70.242.163' timed out, trying again (Attempt #29)
[Oct 13 14:00:22] VERBOSE[3594] logger.c: -- Got SIP response 423 "Interval Too Brief" back from 166.70.242.163
[Oct 13 14:00:39] NOTICE[3597] chan_iax2.c: Restricting registration for peer '1100' to 60 seconds (requested 300)
[Oct 13 14:00:42] NOTICE[3594] chan_sip.c: -- Registration for 'genocide@166.70.242.163' timed out, trying again (Attempt #30)
[Oct 13 14:00:42] VERBOSE[3594] logger.c: -- Got SIP response 423 "Interval Too Brief" back from 166.70.242.163
[Oct 13 14:01:02] NOTICE[3594] chan_sip.c: -- Registration for 'genocide@166.70.242.163' timed out, trying again (Attempt #31)
[Oct 13 14:01:02] VERBOSE[3594] logger.c: -- Got SIP response 423 "Interval Too Brief" back from 166.70.242.163
[Oct 13 14:01:22] NOTICE[3594] chan_sip.c: -- Registration for 'genocide@166.70.242.163' timed out, trying again (Attempt #32)
[Oct 13 14:01:22] VERBOSE[3594] logger.c: -- Got SIP response 423 "Interval Too Brief" back from 166.70.242.163

Even after correcting your registration string.

/var/log/asterisk/full indicates:
[2008-10-13 21:41:05] VERBOSE[6069] logger.c: -- Got SIP response 423 "Interval Too Brief" back from 166.70.242.163
Now a SIP response 423 Interval too brief is RFC3261 type response code.
http://www.stroppytux.net/voip/sip-response-codes/

If Memory serves, and someone can correct me here but RFC3261 is avail in Asterisk 1.6.X for SIP over TCP and UDP I am not sure Trix 2.6.X versions can handle RFC3261, someone can correct me here too if I am wrong.
rhwebhosting, I suggest you get hold of your softswitch/SIP provider and have them confirm protocol requirements for your connection to be sure.
Also, it would not hurt to try get them furnish you with registration requirements including maxretry e.t.c. e.t.c., we can then try and help thumping out the configs provided.

O.K., there's an interesting twist!.

What is it you actually want to achieve by connecting to this Xoip device/platform?
And once you connect, presuming you are hosting the hardware, what interconnects do you want to achieve?
Do you wish to become a SIP provider of sorts to add to your hosting offerings?
Or Do you plan on distibuting global office or home based registration interconnects?
Or maybe corporate sofswitch interconnects?

Or are you just plain and simple toying with the thing?

There are a lot of blanks here, we can only really help you if we can understand what it is you are trying to accomplish.

Kevern.

O.K. That makes more sense now, Fantastic Rodney.

Looks like you already have sufficient global presence, global regulatory savvy and are all set to provision intercalling offering VOIP services with vertical growth into peering, problem is you have proprietry stuff and you have just discovered what a boon asterisk is.

Well, if I were you I should be considering the 80/20 rule i.e. 20% investment to 80% returns with visability to growth.

Personally and this is my opinion, anyone else is welcome to jump in here, I assume you have some good bandwidth i.e. a T1/E1 internet or higher banmdwidth pipe connections with QOS and static public IP's.

You already have Trixbox CE, and as you may be aware Fonality is about to launch HUDlite 3.0 this month Oct' 09 which is supposed to be Unified Messaging capable on CE platform, thus an answer to your service offering needs, so heres the advice;

I would deploy firewalled, IAX trunked IPBX's in global locations where dialplanned inter-calling extension sets form your global client registrations or accounts through SIP registrations and your interoffice dialplans form your global inter-office calling.
I should imagine that the $$ for proprietry soft switch technology and support would be a little higher than opensource capital investment.

Short, medium and long term risk mitigation to your company can be addressed by support levels and escalation support from various sources and options.

I have done similar architecture for ten locations but only for interbranch dialling, adding customers through SIP registration is just one step further.
If what I say makes sense and you are interested in the technicalities of this solution I will glady impart the architecture to you.

Kevern.

It's fine that you are looking at a ISO based Asterisk distribution to evaluate the potential. FreePBX (the PBX engine trixbox is based on) is not designed for multiple tenants. There are also no viable high availability options.

A service provider needs to consider scalability, especially in provisioning and billing. A Session Border Controller is also very useful to provide admission control and better NAT Traversal that Asterisk can provide.

My company is a Service Provider service the Cleveland and Akron Ohio LATA's We use Asterisk, Iperia, SONUS, Juniper, Cisco and soon an Acme Packets Session Border Controller. We tried to use SER with limited success, we then decided to go with the Acme Packets device. The Voice Mail in Asterisk 1.6 is supposed to be far more robust than in 1.4. If that is so the Iperia box will go away.

We where an ISP before we offered Voice Services so like you we had a large amount of infrastructure in place. In fact most of our inbound DID POP's where repurposed from our dial up network.

Rodney.

You now have outbound calls working vis a vie SIP trunk to Xoip softswitch, how is inbound doing?, I just ask before diving into architecture.
Also, the internal use VOIP calling using Trixbox CE makes sense, do you intend to position with softswitches using internal calling as base for testing with intention to expand from there to VOIP offering?
Again the questions asked before diving into any architectural ideas.