No sound when number unavailable


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.

[Asterisk 15]
[Ubuntu Server 18.04]
[Xlite softphone ver. 3]

You need to call Progress() to pass early media through SIP.

Thank you.
I added Progress() before Dial()

same => n, Progress()
same => n, Wait(1)
same => n, Dial(SIP/${NUM}@trunk,20)

Since I am not at the location to do a live test, the users say there is no difference.

I will be able to test more thoroughly next week.

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.

Get Outl

Is the soft phone on the channel side or the dialplan side of the originate? (Needs to be on the channel side.)

Is there a local channel involved anywhere?

Are you using a codec for which you don’t have a transcoder/licence?

Softphone is on the channel side.

The process of AMI originating call is:

web app initiates call by AMI - this invokes softphone to autoanswer first and then the call follows the dialplan (calling number through sip trunk).

The sip trunk provider prefers g729, but it allows g711, so we are using only ulaw/alaw.

The thing that confuses me is dialing direct via softphone works just fine, yet comparing sip debugging of both AMI or direct call looks the same.

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

There won’t be a 183 on the A side, as this is an originate, so the A side is up before the the B side call is attempted.

Originate has this option

  • EarlyMedia - Set to true to force call bridge on early media…

But I assume it will only affect B side, as A side need to be ANSWERED in order to bridge the call with B side

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_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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.