When I use the “VOLUME” function, I would get this error:
translate.c:405 framein: no samples for ulawtolin
I used as "Set(VOLUME(TX,p)=-5)
I tried without p, same issue.
I am running Asterisk 16
By the way anyone knows what the option “p” does? I know it says "enable DTMF volume control. But that does that really mean?
Thank you!
That’s a warning, not an error. Are you actually experiencing a problem as a result of it?
Hello jcolp,
thank you very much for the reply. It seems to be working. But the main issue I am using this function is that I am having issue with “alarm panel” calls.
This is a VERY weird problem. So our current call flow is:
Alarm panel --> 8xx --> Verizon --> our company --> alarm receiver (our customer)
We are a carrier which supply our customer with toll free number. Part of our customer are alarm monitoring center.
So, they (our customer) have a lot of alarm panel that calls our toll free number (which we have DS3, 28 T1s with both Verizon and Century Link). These calls will get pass to us via T1 (PRI) and go to Audiocode M2000 (SIP gateway) which will convert these PRI to SIP and then gets pass to Asterisk. Asterisk then will pass the call to the monitoring center.
The problem comes, if we get rid of the DS3 (PRI) and have the call comes directly to Asterisk (bypass the Audicode TDM to SIP converter gateway), we will have issue with the call. It seems that the alarm panel will not able to talk to the monitoring center’s receiver correctly.
By just listening to the “tones”, it sounded pretty much the same, maybe just a tiny bit different. I tried to use the volume function to adjust the volume because when it come directly to the asterisk it sounded fairly loud.
But either way, I am not having any luck to get this to work.
Do you know anyone has this type of problem? By the way, I am not talking about using the Alarm Reciever application, I am just talking about Asterisk hand the call out to the alarm monitoring center. We are just the middle man, we DO NOT use asterisk to answer any alarm panel calls.
Thank you.
Just to clarify, we also have SIP trunk setup directly with Verizon and Century Link now. That is how calls are getting handed to us (bypassing the DS3).
So either way, it seems when alarm calls come in via DS3 and then gets converted to ASterisk SIP, everythign works fine. But if the call comes in directly SIP from the carrier to our Asterisk, calls would not work.
Now the weird thing is that a Modem call (data call) would work fine. I would think a modem call would be much more complicated tone then an alarm panel. So, anyway, this alarm panel calls are a headache now…
Are you using A-law or mu-law, based on your geographic location? Alarm panels are unlikey to be compatible with more sophisticated codecs. You also want to do your best to disable DTMF decoding on those lines
I am using mu-law, G711, no compression. How do you “disable DTMF decoding”?
The other issue with alarm panels is that the modems may not be able to cope with the high latency associated with SIP. I remember testing them against latency specification was part of the move to 21st Century Networks in the UK (using VoIP for the PSTN back bone).
the issue that puzzle me is that the ONLY DIFFERENCE is that the calls that works, comes in TDM (PRI) but it gets converted to SIP before it gets to Asterisk. So why that works, but yet when calls comes in from the carrier directly SIP trunk (vs comes in PRI), it would not work? If is a “codec” issue, it should not work in both cases, no?
DTMF decoding could happen in the gateway, so I can’t answer for that. Specifing dtmfmode as anything other than inband should stop it being decoded within Asterisk, but won’t prevent the gateway trying to decode it. I’m not sure whether or not Asterisk only inserts a decoder if you have features that need DTMF enabled. That’s quite possible, given that they are basically the same conditions for permitting external bridging.
That’s the only thing I was thinking too, the latency. Because the only difference between coming in TDM PRI vs the SIP trunk is that inbound latency is much bigger on SIP. But at most 30ms… gee… that really sux though…
If they are coming in by SIP, all of the potential damage to the signalling may have happened upstream to you.
ya, probably… well, thank you very much for the information David!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.