I have a problem with Asterisk 126.96.36.199 and a Thai ITSP. When someone makes a call, the caller can’t hear ring tone, just silence. As soon as an extension pick the call up, the communication is fine.
The outgoing calls are fine, only inbound have this problem.
Because I got the message “NOTICE: rtp.c:1057 process_rfc3389: Comfort noise support incomplete in Asterisk (RFC 3389)” from ITSP, I tried to set on SIP.CONF:
together and many combinations of that, but still the same problem.
I also captured packets and I noticed that I can’t see any messages 183 ring progress, just 200 OK.
With other ITSP no problems at all.
Thanks for any help!
You can try with R and r option in your dial command.
Hello and thank you for your reply. I tried to use R and r options, but it does not work. My dial option:
(ring) it is a directory with ring audio files (with ring tone) inside, played on a loop.
Last, even if I used:
I always get that error message. I noticed HOLD music has very low quality (like it is still enable).
Also, even if I don’t pick the phone up when ringing, the timer on caller’s phone start to count and drain money.
Thanks for any help!
It sounds like you are answering the call early. You need to provide the dialplan, and probably verbose level 3 CLI output.
Why are you only just reporting a problem on an Asterisk version that has been end of life for a couple of years?
The m and r options are mutually exclusive (m takes precedence).
m appears to cause a Progress indication. Note that most ITSPs will not pass the resulting early media, because it would allow free information calls. However, from your description, something is forcing an answer.
Poor quality music on hold seems to be a different issue. It could be a poor codec convertor, but it could be network problems, or use of a VM on a loaded host.
Yes, you are right, the IPPBX answers the call as soon as the call arrive, but I don
t know why, because with other ITSPs it is fine. The only difference of this ITSP is the protocol alaw, the other are all ulaws. I am using this Asterisk version because it is still working to customers place, I didn
t know it was so obsolete, but I cant upgrade actually.
Poor quality MOH is present only with this provider, and pushing the HOLD button makes the error message “NOTICE: rtp.c:1057 process_rfc3389: Comfort noise support incomplete in Asterisk (RFC 3389)” to appear, not before. I am going to try getting the information you want, in the meanwhile, any other ideas?
Thank you very much.
A- versus Mu-law won’t make a difference. However if all the ITSPs break out to the PSTN in the same part of the world, some will be using the wrong codec. A-Law is used by the European PSTN, and Mu-Law by the US one. I don’t know what Thailand uses.
Hello. The Thai ITSP told me they use alaw codec.
Using alaw codec only it is possible to talk.
The actual problem if an ITSP negotiates Mu-Law but then breaks out to an A-Law network is that the audio will be slightly more noisy because transcoding from Mu- to A-Law is lossy. The same happens if a UK subscriber calls a US one, purely on the PSTN.
In the UK, a lot of people seem to have Cisco systems set for Mu-Law, even though we use A-Law, but they don’t realise the audio is degraded.
If you actually feed Mu-Law into an A-Law network, it is severely distorted, but I don’t think your ITSPs will do that.
Hello. After many tests I got the problem, and now I can focus on its solution.
Using another version of Asterisk (188.8.131.52), when someone makes an incoming call, the call is NOT ANSWERED until someone pick the phone up, and in the meanwhile I can hear the RingBack tone.
If I use Asterisk 184.108.40.206, as soon as the call arrives, it is automatically ANSWERED and I can see the timer on my cellphone run until one of the extensions start ringing. Probably the ITSP accept RingBack tone only when ringing (183 Ring in progress). Other ISTPs seem to accept it in any conditions.
By the way, now I need to look for a solution to avoid the incoming call is answered, where I can start looking for it? Any suggestions?
It was clear that it was answering. The question is why is it answering. You need to do Answer(), or some application that explicitly answers before an answer is generated, unless that specific version of Asterisk is broken.
Ringback tone in audio is not special, unless the ITSP is doing something very unusual to detect and suppress it.
Re: your proposed trace, to be really safe I would remove the response parameters in the Authorisation headers, but the data looks reasonably sanitised to me. I don’t intend to make a habit of pre-vetting traces, though.
Thank you very much for your kind support!
Hi. Accordingly to my tests, I am thinking this device has an incomplete support to FAX DETECTION that force it to answer to all the incoming calls. I will check for it doing more tests.
Hi. Finally I fixed the problem. The solution is to insert on SIP.CONF these options:
and modify the dialing options deleting “H” and “h”, changing from:
Ttm(ring) or Ttr
Thank you very much to everyone who supported me.