Asterisk Bridging/Answering Late Causing Failure w/AMD

My problem is that Asterisk seems to be answering the phone just a bit too late after the “Hello?” for the AMD functionality to work right, i.e. the AMD comes in on the silence and the person has to say hello again for it to know there’s a person there.

We’ve tested it using IAX via a softphone and see more or less the same delay upon answering so we’re assuming it’s the Asterisk configuration.

I have more or less a vanilla Asterisk install. We are initiating outbound calls via SIP through a local provider. I’m using the “Manager” portion of the Java Asterisk API to tell Asterisk to make the call and then the Java Agi API to deal with it.

The SIP portion of the config looks like this (sip.conf):

[my-sip-trunk]
disallow=all
allow=ulaw
allow=alaw
allow=gsm
host=<ip to our provider>
type=peer
canreinvite=no
nat=never

The data I send via the Manager to Asterisk looks something like this:

Channel:  SIP/<phonenumberhere>@my-sip-trunk
Context:  MyContext
Extension:  100
Priority:  1
Caller ID:  <caller's caller ID>

In my extensions.conf I have the appropriate info and-- solely for the purpose of this demonstration-- only a couple of commands:

[MyContext]
exten => 100,1,Answer()
exten => 100,n,Background(beep)

What I see I can literally pick up the phone, say, “Hello?” and then I hear the beep at the tail-end.

With a call to AMD() behind this we have a huge failure rate of detecting HUMAN vs. MACHINE.

Does anyone have any ideas where/how I’ve misconfigured Asterisk to have this delay?

That doesn’t prove anything; it is normal for VoIP, because of the non-trivial round trip time.

Also, although probably irrelevant, Answer serves no useful purpose on in the B side of an originate.

[quote][quote=“david55”]That doesn’t prove anything; it is normal for VoIP, because of the non-trivial round trip time.

Also, although probably irrelevant, Answer serves no useful purpose on in the B side of an originate.[/quote][/quote]

You’re saying this amount of lag/latency is normal. How do you handle late AMD, then?

AMD isn’t done at the end with the answering machine. All I was saying is that your test is not a valid test, because it was done at that end.

I’m not sure I really want to go further with this thread as all the calls I get with AMD seem to be from boiler room scammers or people trying to sell Disneyland tickets - the latter actually looking for a positive AMD.

Maybe I didn’t make the post clear enough.

I make a call, I play a beep, I end the call. I know by when the beep happens that-- had I used AMD() instead of playing a sound file-- it’s at this moment that AMD() would have started to do its analysis and this would have occurred several moments after picking up the phone receiver, i.e. missing their initial “Hello?” altogether.

You’re telling me that this delay is normal. If it’s normal then people either don’t detect answering machines at all or they somehow detect differently, i.e. later on in the call, by different methods; I don’t know-- that’s why I came to the forums.

Why delegitimize the post? If it helps you feel better, we’re sending reminder messages about people’s appointments so they don’t miss them (beneficial to business and customer) and we don’t want to sound like amateurs when we play three rounds of an IVR menu on their answering machine because we can’t detect it.