DTMF issue with Cbeyond

yes, downgrade your asterisk version... theres a dtmf bug that showed up in recent versions.. look for a 1.6.0.x version that has a release date around the time of 1.4.26.2 and see if that solves your issue. I'm running 1.6.0.15 at home.

Just took the system down to to 1.6.0.15 and same issue. Works perfect on my switch but failed on the Broadsoft. Any other magic version to try?

Michael

looks like you're going to have to do a wireshark capture and see if they are even sending the RC2833 packets. Those show up in wireshark with a different filter. Maybe the provider is screwed up and they either didnt set it to rfc2833 or they are behind on firmware updates or something. At least knowing if the packets are being sent will go a long way to troubleshooting the right end. If they didnt send the packets at all then it sounds like a simple 'hey asshole' phone call :-)

If it works from your switch it seems like a great sales opportunity =)

Already have the pcap's of a working dtmf and the non with them. Any recommend wireshark filter to confirm the dtmf is being sent?

And yes sales slime has been made aware of the matter :)

your filter should be 'rtpevent'

Did the filter and didnt see the DTMF events on theirs but did on mine.

Advised them of this and they responded with this:

--------------------------------------
Notice that on the good call your softswitch is sending DTMF payload 101 – Telephone Event. The PBX is honoring that in its 200 SDP response. This is why you see the events in the trace for the good call (RFC2833 is used).

Our gateway sends payload 100 X-NSE which asterisk doesn’t seem to know how to deal with hence the exclusion of the payload type in the PBX’s 200 SDP response. Typically this would mean the PBX would fallback to Inband if set to Auto and that our gateway will send tones Inband. This is why you don’t see events in the bad call. If you were to capture the audio you would hear the tones we’re sending down inband.

My thought is that the PBX is set for RFC2833-only somewhere in the configs and isn’t honoring your change to Auto. On my PBX I had to make this change on the trunk itself as the change didn’t take when I modified the sip.conf general section alone. See if you can find what’s locking down to RFC2833 and let me know.
--------------------------------------

Going to double check everything now.

you didnt by chance set dtmf=inband in [general] did you? that would mess up your phones connected to the pbx. This is the first time I've heard of any broadsoft switch having an interop problem, but I dont like broadsoft for many other M$-type behaviors anyway. Can you confirm that in the specific trunk you set dtmfmode=inband ?

btw its that whole "Our gateway sends payload 100 X-NSE" crap that makes me hate broadsoft. They fucking do this with the damn call forwarding crap too. They chose to implement a DRAFT amendment to SIP for P-Asserted-Identity and made it gospel. Guess what, that goddamn draft was shot down and burned at the stake by the community maintainers of the SIP standards; and yet Broadsoft is still making people configure non-compliant standards. They should be ass-raped at noon every day for pulling a microsoft. I'd love to know, that when I hear a clocktower chime noon, somewhere those assclowns were getting what was coming to them :-)

General section is clean, no dtmf anywhere in there.
On the trunk i have manually tried inband/auto/rfc2833
Anywhere else to configure DTMF other than sip.conf and rtp.conf (for dtmf timeout?)

Michael

nope thats it...

you really dont want to do inband simply because slight jitter will case a number to duplicate...

if I press

1 - 2 - 3 - 4

but it comes across sounding like

1 - 2*jitter*2 - 3 - 4 then it will get registered as 1 - 2 - 2 - 3 - 4

the whole purpose of dtmf out-of-band is so that tones are not being interpreted... the server says 'he pressed the number 3 for 300 milliseconds' .. thats pretty definitive versus having to fool with the whole relax mode of dtmf etc.

btw if they dont recognize any payload for dtmf than 100 X-NSE your customer wont be able to call any off site IVR's either.

if you do get inband working just be aware of its limitations. I would call into a # you can record, just to make sure his story about sending audible tones inband is true... you should be able to hear them just by calling a direct dial # of a handset and pressing the digits on a regular phone call.

Erik,

You will love this one. I have taken it down from 1.6.0.22 to 1.6.0.15 and then down to 1.6.0.9. All the time its working great with our switch and failing DTMF tones with the Cbeyond Broadsoft switch. Now i am being asked to do the following:

"I think, at this point, it may be a bit more effective to simply switch to Trixbox CE. From what I can see, there are a few customized settings that you are using, and it might just be in the customer's best interest to use a tested and true solution such as Trixbox..."

I am considering dropping down to 1.4.26.2 now, but that will involve a reload of the thirdlane module, correct? Dropping from 1.6.0 to 1.4 doesnt sound fun.

Also, is it possible to setup a single inbound DID that bypasses anything TL and goes right to the IVR?

Thank you

Michael

then they dont understand asterisk at all. thirdlane is just a config writing front-end. Why not just set up an extension on your faxing gateway machine, set up a trunk, and then use simple dialplan to dial in and out.. that would tell you if their switch works with 1.4 branch or not.

as far as ruling out TL dialplan you can make use of user_extension.include to make a simple context of dialplan like

_NXXNXXXXXX,1,Dial(SIP/${EXTEN}@their-trunk-name-in-sip.conf, 90)

_19196661212,1,Dial(SIP/your-exten, 60)

in your sip.conf for both the phone and the provider set the context to the context you made in this file.

test your calls, as you can see theres not a damn option set on this call in either direction. Test DTMF and see if it works. IF it does then you can start adding the options back into the dail statements like

r and Tt Ww etc.

your problem is on inbound or outbound? refresh my memory

Both inbound and outbound dtmf issues. I am asking if i can setup their trunk from a different source IP. Then i will test it on other boxes here. Just need to let the customer know they will be down once i register their trunk on a different box. Shouldnt take long to test on another box.

Thank you

Michael

you know that idiot probably only tested trixbox CE 2.6.x versions which are all 1.4 based.

They just created a 1.6 based build toward the end of last year that was 1.6 based.

That's funny! Change the gui because of a lower level issue. That's kind of like changing the keyboard because there is a misspelled word in a document.

Just FYI, I'm using Asterisk 1.4.24 and Commpartner's Broadsoft platform, and DTMF is working fine. I'm using RFC2833. For some reason I have rfc2833compensate=yes in my sip.conf general section, but I think that was for a previous provider where DTMF was not as reliable.

Very interesting. I will give that a shot as well.

Thank you for the information

Michael

rfc2833compensate was supposed to handle an asterisk 1.2 to 1.4 trunk .. i.e. you were buying sip service from a provider who was still using 1.2 .. worth a try assuming it wasnt depreciated in 1.6 :)

Sounds to me like it is time to move on to another provider.
There are far to many good ones that work find with Thirdlane.

It's time to move on to someone else and give the boot to thoes not willing to play nice together with Asterisk. I originally worked with fuse3 and noticed the problem with the DTMF payload and asked them to contact the forum to see if anyone could help. eeman, like always, is impressive with his knowledge and generous with his time and energy that he provides all of us. Thank you Erik.

I think your man is doing you wrong and you need to move on and find a good man that will take care of you and treat you right.
!! Of course I am talking about Ce-Beware :)

It just might be a good idea to let you provider know that you aren't using it... If something as simple as DTMF isn't working for one of your 50 or so customers using a provider who has a bit more....you might want to look into the true root of the issue. Even AsteriskNOW! had issues with the GUI and the end result...so you might want look into the issue more. From what I know, Cbeyond is a SIPconnect provider...which means that they did the testing and have created guides to aid in the turn-up process... while Asterisk, in it's raw form is interoperable, there may be some other factors being overlooked in the Thridlane application. I am looking for a new PBX to sell to my customers, and I know that Ce-Beware... or Cbeyond, is a pretty damned good SIP provider... I think it would be a better idea to find out what the issue is, before slammig a provider as big as the one in this thread... opening doors is a better practice than slamming them shut... besides... WE ARE TALKING ABOUT DTMF... how difficult could it be? Cbeyond has some 30k + customers on their service.... all using SIP... they must be doing something right. Hell...change your box to inband... downgrade to 1.4.26.2... buy another trunk from Brodband.com and see if the issue persists... create a dialplan to use the secondary provider and see if there is a true issue with the primary provider, or just your config.

I don't mean to be bold... like I said, I am looking for a new PBX line to sell, and I come from the land where DTMF is DTMF... If a PBX can't just make the boop beep sounds needed to navigate an IVR, then there are issues. I have heard great things about the Thirdlane, and I am sure that this isn't one of them. I'd hate to have to continue using the Switchvox...those guys just went a bit commie : ) I have yet to find an Asterisk DTMF issue related to Broadsoft... I have seen goofy shit with AsteriskNOW! and other GUI basterds messing with Asterisk... but Asterisk will werk.

Unless a fellow vendor is ripping on AT$T...they shouldn't be ripping on carriers... the carriers are carrying money to our pockets.

Now can some one tell me without a shadow of doubt that there is or is not an incompatability issue with Thirdlane and Broadsoft? If there is an issue... what is Thirdlane doing about it? Broadsoft has the marketshare, and Thirdalane is trying to make a ripple in the SIP pond...so what's it gonna be?
Why is it that this thread is the only thread with DTMF issues and Broadsoft if this is such a known issue? Forgive me for being stupid... I just want to know, as a business owner, trying make a PBX decision... there is a lot of Broadsoft out there....why do I want to use Thridlane as my main product?

Why doesn't FUSE3 try a plain jane Asterisk distro.... if it works...then there is obviously something wrong. I understand that this is a Thridlane forum...but, hell, it might rule out other problems. I can see that the "advice" that fuse was getting was a bit rudimentary... mut maybe the idito was telling him to just use Asterisk... and maybe the idiot didn't know that there were other things at play. Notice the dude didn't say to downgrade your version of Thridlane...but he said to downgrade Asterisk... well whatever... I don't know. I just want to know if I want to give this Thirdlane thing to my techs, and we will be putting this box on Cbeyond trunks (and XO and others) if we do carry it... so please...keep us all posted. Happy hunting!

you absolutely dont know what the hell you are talking about. A gui has NOTHING to do with DTMF... why? BECAUSE THE CALL IS ALREADY ESTABLISHED. That means that its ENTIRELY handled by chan_sip and channel. The calls are set up with ASTERISK options and features. If they are having a DTMF problem, its an interop issue with a specific branch or version of asterisk and their PBX. It wont make a bit of difference which front-end wrote the dial statement. The Cebeyond idiot talked about trixbox working but didnt use his primitive brain to think about the fact that his trixbox was a 1.4 branch and that the customer is attempting a 1.6.0 branch. I'm not saying its a Cebeyond problem, hell it might be an asterisk 1.6.0 problem, but it sure as hell isnt a dialplan issue. next time RTFM before you spout off statistics about how a large company is completely blameless simply because they have a lot of customers. ING and Enron were pretty large companies.. by your measure of evaluation they can do no wrong.

I have asked Cbeyond repeatedly for a version of Asterisk that they recommend or support or know to work. I have tried 4 different 1.6.0.x versions and have said “Tell me the 1.4.x.x version you want me on”. Once I ask that question I never hear from their technician again. We are on our 3rd case, each time they say “try this….” I then respond 10 minutes later and they state the case has been closed. The standard ticket process for them is, case is opened, they get summary, they offer a suggestion and close the case. Each time I have responded within 10-15 minutes advising them it did not resolve the matter. Each time the customer has to open up a new ticket. I have even asked if I can register their trunk over to any of our boxes for an hour and test on all the difference branches we have in our lab, standard no response.
They may have 30k + customers but they won’t for long if this is their standard response anytime they have a problem outside the box.
Michael

with version of 1.4.x.x i would use either 1.4.24 or 1.4.26.2 as anything newer has a dtmf issue backported/merged from 1.6.1 and the 1.4.20-23 and the 1.4.25 have other bugs you cant live with like transfering calls etc.

if you still have a problem with rfc2833 dtmf with those versions its an interop issue with their switches or in rare case a payload problem over bonded t1's doing fragmentation/interleave (which manifest on asterisk detection, not on sending).

Problem Fixed!!!

This is a confirmed interop issue. Just has a temp call from Cbeyond and finally had someone willing to work on the issue. He had me try everything from moving dtmfmode=auto to the top of the peer and down to the bottom (yeah i know). Also had me mis-spell the host= to something else, save and restart asterisk and then rename it back and save and restart (yeah i know).

Resolusion was "Hey, do we have to go through your proxy", he said "Uhh no". I advised him we have had 4 cases all with the same damn things tried. Over and over, add and remove dtmf=auto and dtmfmode=auto. I told him we need to start eliminated parts of their config. So we bypassed the proxy and BAM! we have working tone.

Confirm interop problem with Asterisk 1.6.0.x and the SIP Proxy at Cbeyond (Broadsoft)

Michael

so much for 'they have 30k customers therefore their shit doesnt stink' :-)

know what I was talking about. I am trying to find a PBX line that may suit my companies offerings. I never said that DTMF is effected by the GUI. I stated that the GUI may effect the end result... meaning the GUI may have issue with the interface to the command line... I am not defending any big business, either... I hate the big bos, but I think that there is some merit to the big boys (except AT$T), as they have a helluva lot more customers than I. So I may want to chose a PBX that works with the big boys, as the big boys are going to be around. I don't want my customers using a company that will be here one day, and gone the next... that' snot good business.

I have yet to see a report from Asterisk, that their software will not operate and play nicey nice with the Broadsoft... the Broadsoft is a very commonly used switch. I just wanted to know if the Thirdlane was a PBX that would actually work with Broadsoft. It was an easy question, and it is being avoided. Now, if I was to be the referenced "sales slime" and try to sell this box, I would want to be 100% positive that it would work under the most common circumstances...right out of the box. This doesn't seem to be the case, now does it? If I wanted my techs to go goofin' around in the command line, why wouldn't I just use raw Asterisk? What do I benefit from selling a product that needs to be tweeked with in such a deep manner?

Funny thing is... the fuse dudes resolution was to avoid the Broadsoft all together... now, I know that I am an ignorant fool... but isn't avoiding the proxy opening the PBX up to a possibility of some security issues?

I mean, hell... even you, erik, said that you have never heard of interop issues with Broadsoft, so what gives?

Forgive me if I am not your caliber of genius... but I am just trying to see if this PBX is a good product. You are being very unfriendly to a guy who knows little about a product that is so superior. Snubbing your nose at someone who has no idea about this stuff, looking for answers, is not a good way to make relations, in my opinion.

Does anyone know if this PBX will ever work in a Boradsoft environment? Am I mistaken in thinking that Broadsoft is a widely used switch in the SIP world? Forgive me for not knowing the full geek speak... I am just trying to make the transition from traditional PBX into VoIP.

BTW- I RTFM and read that the tech just wasted a week or so trying to bash the provider when all he had to do was by pass the Broadsoft (cuz he couldn't get his box to work with it) and wham-o..problem solved. While fuse was calling all the people trying to help him names, he wasn't doing his job and that was to make that darned pig werk... so the reason that the big guys have a ton of customers is that they don't waste time whining, they make their shit work....and I bet those big guys aren't on the forums brodcasting how stoopid the techs are that they can't even make their own PBXs work. I'm just sayin' and I am one looking for a good PBX, and yet, here you are slamming me just for asking questions and looking at an issue from a business owner's standpoint...

So in your honest opinion... is this Thirdlane product a good product, and will it work with most providers out there? I think the interface is pretty sexy, and the thing looks to be a pretty damned good solution... but will it work? I sell XO, Paetec, NGT, Cbeyond, and other providers... will this box work with these providers, or not? I think I just named 4 Broadsoft providers... and they are smal time providers, I know...but will this box work with them? Can I start gettin gmy techs to use this Thirdlane...cuz I am tired of Switchvox, Trixbox, and those other Digium "branches".. they are just too damned expensive.

once again your complete lack of knowledge is clouding the truth to you. Your lack of understanding what a proxy is versus a class5 switch led you to ASSume that they bypassed everything broadsoft. The proxy was just an intermediary to the broadsoft class5 switch. Asterisk works in a lot of broadsoft environments, but like cisco or any other technical product, there is always going to be providers who don't keep up with their product software and these issues will always occur. In this case the provider did something with their proxy itself that caused the issue, an issue that currently does not plague PaeTec or CommPartners. Just because your car says BMW doesnt mean that its in good shape, it might be one of those beat-to-hell versions you see people driving just to claim they drive one.

you seriously need to understand SIP and what SIP was (had nothing to do with voice until 2000) and why its currently a bit of a mess. Unlike BGP4, OSPF, RIPv2 there are no tightly controlled set of standards for communication in the SIP RFC. This is why there are always inter-op issues even among class5 switches. A broadsoft and a SONUS switch dont play well togeather at all with SIP. They have to tandem TDM with SS7 signaling to communicate voice traffic to eachother. These are both million dollar devices. I personally don't respect Broadsoft because they insist on P-Asserted-Identity SIP headers based on a DRAFT proposal that has since been shot down. Thats like building a car that requires that Gas-o-hol product from the 70s. The current SIP RFC implementation is more like a target milestone of ideas and every product developer has their own interpretation on how to construct the URI and how to manage messages, why dtmf has issues with rfc2833 with some equipment and not others. There are some SIP switches out there that insist on the TO header to define the DNIS of the call instead of the URI. This required creative dialplan programming to take the call, evaluate the TO header and then re-direct in dialplan to the extension specified in that header. Its 100% completely inoperable without this dialplan trick and yet both devices speak SIP. This is often why on other pbx products you have to select from a list the type of far end device in order to set the trunk up. This would not be necessary on a real standardized protocol. You don't have to define the type of mail servers to conduct SMTP delivery. You don't have to define the type of FTP server to use that protocol or just about any other protocol.

you claim to be RTFMing but you're either not reading the right documentation or you arent absorbing it. You should invest the money and go to the asterisk bootcamp at digium to get you on track with the history of voip, where it evolved from and what the current troubles are in the industry.

If I wanted my techs to go goofin' around in the command line, why wouldn't I just use raw Asterisk?

seriously? your going to go with that? Do I think your techs should learn in detail everything about asterisk.... umm YES! Is it not expected that if you are a cisco shop for routers and switches, that your techs become cisco certified and your hiring requirements reflect that? Is it not expected that you maintain microsoft certified engineers on staff to service your microsoft file servers, exchange servers and MS-SQL servers? Then why the hell would you expect anything less from something as important as being certified not to screw things up on your communications equipment? Getting digium certified is not difficult. It is true that the practical test requires experience, and a lot of practice building a dialplan from scratch in a manner that a marine rifleman practices field stripping his service weapon in order to qualify within the time parameters required. However, unlike many other certification classes, this one does not require endless courses and exams.

Do you know what I do when a customer has me install a PBX and wants to select a vendor and I have not had first hand experience with that provider? I perform a series of inter-op test with the provider doing packet captures to verify the correct sip messages occur when i call a number, when i call a number and that device is busy, when i call outbound to a busy number, when I call outbound to an invalid number, etc. Given the current state of SIP there's no real way around it. At the carrier level its not an option, you can't peer with a carrier like Broadvox, Level3, Verizon, Paetec at the wholesale level without conducting an interop test.

Did you know there are a lot of expensive sip capable pbx's out there (cisco, nortel, avaya) that have to put an asterisk box infront of their PBX just to peer with their providers? For whatever reason they cannot handle an inbound call with a + infront of the number. The telephone E.164 standard is all about the + the same way BIND requires a final . at the end of the name. Yet something so ingrained in the core of the PSTN is not part of their PBXs and therefore they end up building a very basic asterisk box to peer with their provider and strip the + before sending it to their $150k paperweight.

The bottom line is if any of those providers work with the same version of asterisk that you're running, they're going to work with thirdlane even if it does require a few extra changes, the design supports that flexibility. But there is never going to be a plug-n-play SIP phone service until the RFC is amended and re-written to require very specific rules of engagement.

As was stated previously this in is no way a TL issue. This is clearly an issue with Asterisk 1.6.0.x, and now Cbeyond is admitting to that fact. Their solution was always “reload your box with Trixbox CE”.
So to answer your question, yes TL will work fine with Broadsoft if you load it with Asterisk 1.4.x. If you use 1.6.0.x you will need to request to not use their proxy. By the way the proxy setup I was told is “not” their default configuration.
Please take another minute and review all my posts, not once did I “bash the provider” . Cbeyond has in turn admitted this is their problem and now their fault. Their salesman called us yesterday and said “wow you guys really know your stuff”. So putting any of this back on us is a joke.
All Asterisk related DTMF issues were configured correctly, even their technicians who repeatedly told me to enter the same commands said everything was perfect on our end. Requests for escalation were ignored and cases were closed without resolution. If you should be questioning anyone it should be Cbeyond.
Just for your information, I uninstalled TL during the testing and loaded a plain vanilla Asterisk 1.6.0.x setup, same issue.
So as the Cbeyond tech responded yesterday “Well I guess this is a bug in our system, you confirmed that”.
Oh yeah, remember, just because someone has never heard of a problem with a provider doesn’t mean there isn’t one. The tech I worked with yesterday said their number 1 case received is DTMF issues with Asterisk. So yes this is common, what isn’t common is the fact they couldn’t resolve it by following their standard script.
It all comes down to 1.6.0.x vs. 1.4.x

Michael

Guess y'all didn't RMFM... Excuses are a dime a dozen... as a business owner, I don't really care what the problem is- I care if there is a clear path to resolution. Being an old Tip and Ring guy, I can appreciate quirks in technology... try integrating a traditional PBX on a softswtich back in the day- no bueno.

I think that y'all missed my point, though...

In an E&M world, we just fixed the problem... we didn't piss and whine about it, because it was our JOB. We worked with the providers and manufacturers to make a common customer content, or more than. If y'all treat your customers as you have treated this "issue"...well...nuff said. This thread remids me of the SNL skit that had the "IT Guy" with a slight disposition and malcontent towards his customers... sorry to be a traditionalist, but I strongly disagree with your positions towards thos who have only tried to help, and those who have only tried to gain a bit more knowledge on the subject. Infantile and condescending remarks only mar the service and the product offered here... I have asked similar questions in Digium, Paetec, and Cbeyond forums, with no where near the ridicule and slander.

Telecommunications is a business, and I am not so sure that y'all get that. I won't get into Effective Business Communications 101 with y'all...but I surely hope that you folks don't treat your customers, prospects, and lesser technicians with the same disrespect. This is not very encouraging that Thirdlane allows this type of disregard for the true business of telecom... but I am sure that Thirdlane is not monitoring the vile behaviour of it's forum "elite", otherwise this thread would be removed.

Once again- I NEVER CLAIMED TO KNOW MUCH ABOUT THIS! I was asking about the solution. I don't take kindly to punk-ass replies and quips... I can sit back and say that I have been in business for over two decades, and that is most likely longer than y'all have had hair in your armpits, judging by your replies.

I may be wrong about y'all...I am often wrong. It takes a stand-up person to admit their shortcomings..and it looks like you guys are trying to capitalize on folks's shortcomings for your own narcissism- but that is just my opinion. It's easy to point fingers...but a true tech will just fix it!

Get over yourselves and stop blasting the folks who are in the same bizness you are in. Telecom is a very small world... bridges burnt will not be easily re-built. Embrace those who are willing to acknowledge their mistakes; these are the ones who are thinking about the bigger picture.

I am off my soap box... I asked if the Thridlane was a good product, and no one answered... GOOD SELLING POINT!

So there was an issue....the issue was resolved by actually COMMUNICATING....gee, what a novel idea for the world of telecommunications... the folks at Sutus and Epygi and ESI, and even Cisco are more accommodating than the folks here... hell, the folks at Micro$oft are more accommodating... I'd be better off with a Canadian/Israeli product, than the arrogance related to Thirdlane.

Enjoy your half-assed PBX....this is one vendor that will NEVER sell the Thirdlane product... and I will make it well known that the support for Thirdlane is abusive, at best, There will be no need for negative remarks on Fuze3 and Bluegrass...y'all spoke volumes through your arrogance.

This is the WWW.... and folks will easily see that y'll got no respect... I was a guy looking for information, and, well, y'all provided it...I guess... it just goes to show...the internet is great for those of use who have nothing better to do than to bitch, gripe, whine, complain, and excuse our way into complacency. Have fun being a Richard!

Cheers!

Correct, the issue was resolved by communications. After we had opened 4 cases with Cbeyond and received no support, just a simple example config off their script, the customer started calling every number he could within Cbeyond. He ended up in the mailbox of the Vice President of technical support for Cbeyond. He explained how we had opened multiple cases and were given nothing and when we called back to test further they had already closed the case.

This forum post is not about a DTMF issue. It’s about Cbeyonds absolute inability to look outside their script. They constantly pointed at Thirdlane as the problem. Even after I had removed it and was plain vanilla Asterisk they still kept saying it was because I was using Thirdlane. Took two phone calls to even explain I was no longer using Thirdlane at that time.

And to top it off I received a call two days ago from the chronics department telling me the problem was because of Thirdlane. I asked if she looked at a single capture, answer was no. I asked if she looked as the notes that I had removed Thirdlane and left it with just Asterisk, she said no. Just now after advising her we were just running Asterisk did she admit there was a problem and that she would be bringing up a lab server to test this with as they don’t have many customers running 1.6.0.x.

So I stand by our service, our professionalism, and our efforts to service the customer. When you are dealing with a vendor that simply will not return calls, closes cases without resolution, and simply will not test with you, it’s a tad bit difficult to get a resolution.

So again, this is not about DTMF. This is about Cbeyonds unwillingness to provide a competent level of support. Could be a tiny bit about the fact that they don’t conform to standards, but im sure Erik can comment on that part :)

Michael

Ironic how he professes his complete ignorance, yet in the same breath ASSumes someone can just snap their fingers and make things work. Unlike the PSTN, there is not a strict enough standard to SIP. Anyone claiming otherwise has not read the thousand page RFC documents. I highly doubt he has any telecom experience he claims. My 15 years has been full of one vendor blaming the telecom and the telecom blaming the vendor even when cisco is the vendor.

I find it amusing how those who expect free help on public forums have this sense that we were put on this earth to help them for free. Try not Bering a leech and giving back once and a while. That is your MORAL obligation to using open source solutions. It's not all about giving free unlimited support to faxpax... Y'all.

Fuse3: Just wondering if you'd be willing to share your CBeyond trunk configuration?

We are running Asterisk 1.6.2.11 and TL ST 6.1.1.12. I've added the trunks thru the TL GUI using the login/password and destination host name they gave me... but CBeyond says they don't even see the switch attempting to login.

Any insight would be much appreciated.

sip.conf

[general]

register => 4081111111:xxxxxxxxx@sipconnect.sfo0.cbeyond.net/4081111111 ; CBeyond

[CBeyond]
qualify=yes
nat=yes
context=from-outside
insecure=port,invite
canreinvite=yes
fromdomain=sipconnect.sfo0.cbeyond.net
secret=xxxxxxxxx
dtmf=auto
;=description=SIP Service provider
username=4081111111
host=sipconnect.sfo0.cbeyond.net
dtmfmode=auto
type=friend
disallow=all
allow=ulaw

Looks like I'm close. I will give it a try.

Yep, your config is good and I would recommend it to anyone else using CBeyond. The only variant I have is listed here... so we are using the outbound proxy and dtmf seems to work. I called our auto attendant and dialed my extension... rang thru just fine.

[CBeyond]
outboundproxy=sip-proxy.chi0.cbeyond.net

Turns out we had 2 issues. We had the register string right, but in the wrong place... it should be in the [general] area... CBeyond recommended we put it at the bottom of the file. I was pretty sure it didn't go there, but I wasn't positive.

2nd thing... we had a "1" in front of our out-bound caller ID... I removed that and did a reload, first call went thru just fine.

Thanks again.

cbeyond fired every technical person that knew anything.. now its just level 1 and theyre reading from typed notes. I am sure their 'put it at the bottom of the file' comes from their complete lack of knowledge and limited adaptation to other instances such as freepbx. Anyone with 30min of formal asterisk instruction when it comes to registering a sip trunk would know it goes into [general]. Even the sample sip.conf.sample file shows this to be the case. Its no wonder why Ive had a lot of people dump CBeyond and come to us to host their consulting customers.