Skip to main content

Anybody Using Commpartners?

Posted by dozment on Wed, 05/06/2009

I am trying to set up a Commpartners trunk in my MTE environment. I've got incoming calls working, but I'm getting a "604-Does not exist anywhere" back when I try to send a call out. Commpartners requires that outbound calls come to them from existing Commpartner's DIDs. I replaced my outbound callerid in the tenant with one of their DIDs and turned off the ability for the user to change caller id. Still getting the 604.

From: "xxxxxxx" ;tag=as60b3cd24

Here is my from header. Any idea why it isn't working? Could it be the quoted string in the From: header?


Submitted by eeman on Wed, 05/06/2009 Permalink

surely they can tell you why it was rejected cant they? btw your from header appaears to be only 7 digits. It should be 10 to conform with standards.

Submitted by dozment on Thu, 05/07/2009 Permalink

Yeah, I munged the header when I was getting it ready to post. I was sending 10 digits. Problem was that I was sending the call to Broadsoft with a DID that wasn't on their Broadsoft switch. I was sending my customer's AT&T number which will, in theory, be ported to Commpartners once we have eveverything working correctly. We do a lot of that.

They have suggested two possible solutions: 1) The can preload our DID's into their Broadsoft switch as soon as we do the port request. Or, 2) we can move our trunks from their Broadsoft switch to their Sonus switch - which will allow us to send the correct caller id number.

Other than that the only difference they gave me in the two switches is that with Broadsoft we can register the trunks from any ip address and from Sonus we have to specify the ip address of the trunk. A couple of months ago I heard something about Asterisk and Sonus not playing well together on DTMF.

Any thoughts on the best way to go?

Submitted by eeman on Thu, 05/07/2009 Permalink

Level3 uses SONUS. The only DTMF interop issue i was aware of was with 1.2. Level3 patched it but when 1.4 came out they removed it because, in their opinion, they shouldnt have to continue to patch their system for something that was asterisk's responsibility to fix. If someone demands to still run on 1.2 they get broken DTMF. Thats all I am currently aware of FWIW.

Submitted by hostedip on Tue, 05/12/2009 Permalink

Wow, glad I saw this.

We use CP and were going to move to IP trunking on the Broadsoft from the Sonus platform (this week). But we do require the ability to mangle the caller id for most of our customers - e.g. replay the inbound caller id for call forwarding, etc. That would be a problem for us.

We don't problems with DTMF on the Sonus.

Thanks,

Brian

Submitted by eeman on Tue, 05/12/2009 Permalink

Broadsoft is a step down from SONUS and they make you do stupid things like use SIP headers that are not part of the RFC but rather a draft suggestion (diversion headers). Digium wont support diversion headers because they and the rest of the entire world believe that a history header is a better way to handle RDNIS. A lot of carriers are ditching broadsoft because they get tired of the $500k/yr licensing fees they hit them with.

Submitted by dozment on Wed, 05/13/2009 Permalink

We went ahead and set our first four trunks up on Broadsoft. In the process of porting some numbers now. Set up wasn't the easiest. It was like pulling teeth to get complete documentation on how to set it up. In the end they told us exactly how it should be set up. We were given the option to move our trunks to Sonus, but decided to stay for now. Other than what Erik said about Broadsoft vs Sonus here's what I understand to be the differences:

Broadsoft

-SIP trunks can register from anywhere or can be made ip-specific.

-Outbound callerid must be a CP DID although they told us they would pre-add DIDs that we are porting to them.

Sonus

-SIP trunks tied to specific ip (cant register the trunks from our backup server)

-Can send whatever we want as outbound callerid.

I believe they said they could set up the DIDs in sort of a hunt group where they go to one trunk, if not answered in n-seconds they go to another trunk. Will have to see about that.

So far call quality is very good.

Submitted by eeman on Wed, 05/13/2009 Permalink

dont forget to deny your tenants the ability to 'preserve original caller id' when forwarding. So as to comply with broadsoft criteria #2

Submitted by hostedip on Thu, 05/14/2009 Permalink

For 911 service, I wrote (cloned and edited) a couple scripts that allowed me to force the outbound caller id on the trunk for a tenant (which works for tenants in one location).

1. New outbound route script which accepts a new parameter with caller id, calls new dialout-base script

2. New dialout-base script which accepts and sets the forced caller id.

Can share if you need.

Submitted by owenc on Thu, 05/13/2010 Permalink

I was just about to do this so I'd love to see these.

Submitted by sit on Fri, 07/30/2010 Permalink

Newbie am I and heres my story.
Coming from a Windows environment, I recently installed the MT edition on a simple Dell P4 2gig pc. No Linux experience required, right?
Provider: CommPartners.
IB calls worked great, right off the back. After several hours, who am i kidding, days of trying to get OB calls working, I finally figured this out:
No matter what, if the CP DID is not established in the Tenant settings, and you allow the Tenant to control the DID, it seems that OB calls will fail. This is because the OB DID that is passed seems to be the dialed number and not the associated CP DID.
In closing...
as EEMAN said>>>
VERIFY ALL DIDS IN ALL SETTINGS THAT APPLY!
Thanks Erik,
Once I understood what you said, it led me to go back and find my mistake(s). Be easy on us newbs!