IVR and Sipstation Trunks

Using Freepbx 2.7 with Elastix 2.0 and same problem occured with Freepbx 2.8

We have 2 SIP trunk vendors Sipstation and Vitelity. for no apparent reason IVR is not recognizing any options and continues to play only on Sipstation trunks and they provide no help. All Vitelity Trunks work well.

Is anyone else having this issue. We are temporarily bypassing IVR on those inbound trunks and going to a Ring Group.




You are the best! I will sing your praises to all who can listen.

Thanks again for all you efforts



I have tried clicking on your name in different os’s Linux Winxp and different browser’s Firefox, Chrome, Opera even IE with all the same behavior. the 2 click here lines below your name are clickable but your name is not. I even tried to copy your name to the Private message area in My account with variations on your name but no luck. Can you send a private message to me?

Any Ideas?

It sounds like you are on to something and it seems to be related to subtle modifications to FreePBX instead of mod’s to our firewall.

Thanks again for your help and patience



shouldn’t matter the browser, you are probably not seeing it.

If you can post here then you can PM.

Try another route, have a look at the very bottom of this page, far right colums of options (5th column), at the very bottom. There should be a “My inbox” link, you can try from there and then PM my user name.

btw - I sent you a PM in case that help you see how to get to it.


just click on my name on this post an there will be an option to write a Private Message.

The audio issues you are having are due to your PBX/Firewall configuration. The default settings for SIPSTATION are to run media direct to the media servers. This results in the lowest latency and thus the highest call quality. Many other carriers route direct to their SIP gateway and from there send the media to the their media servers. This eliminates most one way/no way audio issues at the expense of call quality. SIPSTATION can do that if absolutely required (there are some VERY problematic firewalls out there) but the default behavior is to maximize call quality.

Anyhow - PM me per the above instructions and I will see if I can’t help you further along.


Thanks for your help and suggestions. An additional problem has been identified and we are unable to complete outbound calls to anyone using the Sipstation trunk. Below is a copy of the email sent to Sipstation Support.

We are enclosing 2 log files for inbound calls. All log files have accurate time stamps.

One that works (capturegood.log) and is using a Vitelity Inbound number 800 xxx 7087.

The one to xxx-219-0099 a Sipstation trunk fails (capturebad.log).

xxx-937-3635 is the number calling both inbound calls.

We are also enclosing 2 log files of outbound calls

Both calls were made to xxx-937-3635 from an internal extension.

The call using Sipstation fpbx-1-8ed1dxxx trunk (captureoutboundbad.log) dials and the external phone rings and is answered and the person answering the phone can hear the calling party but is not to be heard by the calling party when talking back. This is consistent with all outbound calls.

The call using Vitelity vitel-outbound trunk (captureoutboundgood.log) dials and when answered normal conversation takes place.

These logs were taken using tcpdump in front of our Asterisk server. We are doing this type of log due to the suggestion of the product lead at FreePBX.

This is the exact same problem we had in early December and reinstalled to fix it.

Also I have looked up how to make a PM but it does not seem to be working. Is it browser specific option?

Thanks for all your help



I guess the first piece of feedback is they are right that what they need is an RTP trace and not an Asterisk log file which is not going to help.

There are a number of reasons for dtmf issues and with Asterisk it gets a bit more difficult because of the problems that Asterisk itself has had in the past and even sometimes currently.

This requires the analysis of an RTP trace to see what is going on and in particular have a look a the inband digital signals (which is what rfc2833 is) to see if there are issues with them or if they are being set properly.

I realize they are asking for the capture on the outside of the firewall however if that is not something easily feasible, you could do a capture form the Asterisk box using tcp dump raw mode and it is very likely they can make use of that to have a look.

What is particularly surprising though is you say you switched to inband from rfc2833 and there was no difference. Did you confirm conclusively that it was switched, applied and the call was in fact negotiated with inband? (you would have to have a look a the channel information at the CLI while the call is up). I ask this because it is rare that a dtmf problem would exist in both modes. If anything, switching to inband has the potential to be ‘flakey’ if the line happens to have some jitter or large latencies, but otherwise, at that point the dtmf is being sent 100% as audio and it is actually asterisk who is listening and decoding to see if it hears the pure tones and thus interprets them. I would check that one a bit more carefully to see if something else is not going on, and then otherwise I would get the rtp traces to the sipstation engineers so they can have a look at it closer to see if they see anything in the rtp stream that would lend a clue as to what is going on.

If you do find after assuring that you were in inband mode that it really didn’t work, PM me on the forums as I have another thing you can do but will need to ask you some more ‘sensitive’ information which wouldn’t be something to put on the public forum.


can you elaborate about ‘they provide no help’

also, what version of Asterisk are you running? There are some settings they can enable of you are having problems recognizing dtmf, though often it can be related to your Asterisk version even if you have the issue with one provider and not another.

Another thing, try setting dtmfmode=inband on the sipstation trunks (and ignore the warning the module may give you) and see if that addresses the issue.

Asterisk (Ver. is our current version.

Enclosed is a copy of email conversation between me and SipStation Tech Support

subject: Re: FW: RE: Re: Sipstation lines not working


I apologize for any confusion you have regarding our request. The information in your last email is not what we requested.

What we are looking for is a SIP capture from in front of your PBX’s public IP address (173.164.x.xx). This capture needs to contain the SIP messaging and RTP stream of a bad call. The information you sent in your last email is a .txt file with string characters representing data between two private IPs.

Our intention is not to be difficult, but the issue you are experiencing is not a wide spread issue, and therefor is most likely isolated to your site. If you can provide us with the above mentioned capture, we can determine if you are not getting the correct RTP from us, and why.



2010/12/8 Andy Pilkington [email protected]


I am enclosing one set of data (Asterisk Logs and SIP/RPT Logs) for a good out bound call using the Vitelity Trunk (Labeled Good) and another set using the Sipstation Trunk (Labeled bad).


I am also including the asterisk log file for an inbound call from xxx-905-8888 to xxx-777-8939 with the destination as our normal IVR, this call connects to our IVR but we are unable to transfer to any extension. This is true for all Sipstation trunk Phone numbers. So IVR is useless.


The 2nd asterisk log file for an inbound call from xxx-905-8888 to xxx-230-7087 with the destination as our normal IVR, this call connects to our IVR we are able to transfer normally. This is a Vitelity hosted number and therefor acting normally as are all our other Vitelity Phone numbers.  

Thia conversation happened over a month ago. I installed the latest version of Elastix 2.0 early Dec. and no problems until this morning. and the same issue is occurring.

I changed the dtmfmode to inband and it had no affect.