I am using AMI for originating outbound calls through SIP trunk. So AMI originates call through softphone to the outbound number.
When outbound number is temporary unavailable (like GSM number), there is no sound.
If I call the same number directly through softphone, I can hear “the number you are calling is temporary unavailable,…”
I compared SIP debugging for both direct softphone call and AMI call, and there seems to be no difference at all. Same codecs are used (ulaw, alaw, gsm).
Whenever there is some sort of answering machine on the other side, there is no sound in softphone,(using AMI originate).
Any idea what might be a problem?
Thank you.
System:
[Asterisk 15]
[Ubuntu Server 18.04]
[Xlite softphone ver. 3]
Are the users remote? Most service providers will not allow a non-service provider to originate early media. If that is the issue, you will need to replace Progress with Answer and accept that your callers will get billed for the announcements.
No, users are in local internet with Asterisk. They are making outband calls only.
But when using AMI (to make a call via web app), there is no sound/voice when “the number is unavailable at the moment”. If the same number is called directly via (same) softphone, the sound/voice is normal.
You should make a SIP trace on both scenario, and verify if the 183 Session Progress response is available on both cases also the codec used in both cases
That 's a new option (I also note there are new options on the application, as well, that allow the channel to be manipulated before the call).
As far as I can tell it ends up with this:
ast_verb(4, "Treating progress as answer on '%s' due to early media option\n",
ast_channel_name(channel));
ast_queue_control(channel, AST_CONTROL_ANSWER);
Which looks like it is faking an answer on the A side, so will consider the A side up whilst it is still in early media. I’m not sure what the use case is, as I can’t imagine many cases where sending early media to a called party is useful, and I don’t think it is relevant here, unless the OP: has specified it, in error.
(One rare use case may be calling a freephone service on the A side, but typical click to call would put that on the B side.)
Sorry for late response,…
After many hours,… lots of hours spending on debuging, the solution was UDP ports on one of our routers!
I got mislead by the fact, that normal call works, so should these anouncements.
Appreciate all your efforts.