asterisk users - Mar 2005 - Problems with incoming calls

Hi Everyone,

I have a DID number with livevoip, but I have been experiencing two 
problems that I can't seem to resolve.  I am not sure if they are in any 
way related.  I have other DIDs with iax sixtel but I do not have that 
problem.  Livevoip seem to think that the problem might be with my 
configuration.  Can someone help me figure out this problem please.

1) When an incoming call to my DID number is initiated, a prompt is played 
so that the caller can enter an extension number or zero for the 
operator.  However, at least 30%-50% of the time the digits that are 
entered from the touch tone phone is slightly different from what is 
received by asterisk.  There is usually double digits when only one of 
those digits were entered.  For example I would enter 4071, but asterisk 
would receive 4007 or 4077 etc.

2) If the extension number was correctly received by asterisk and I pass 
the call to a SIP extension I would then lose Audio until the phone is 
answered.  If I simply pass the call to a SIP Extension without playing any 
prompts and I don't use the answer command before I transfer the call, then 
I can hear the ringing audio just fine.

Example [Works Perfect]
exten => 8668600450,2,Dial(SIP/4071,40)

Example [No Ringing Audio]
exten => 8668600450,1,Answer
exten => 8668600450,2,Dial(SIP/4071,40)

Example [No Ringing Audio]
exten => 8668600450,1,Playback(office-menu)
exten => 8668600450,2,Dial(SIP/4071,40)


Thank you for your help.

Joel 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20050323/7c7daadf/attachment.htm

> 1) When an incoming call to my DID number is initiated, a prompt is played
so that the caller
can enter an extension number or
> zero for the operator.  However, at least 30%-50% of the time the digits
that are entered from
the touch tone phone is slightly
> different from what is received by asterisk.  There is usually double
digits when only one of
those digits were entered.  For
> example I would enter 4071, but asterisk would receive 4007 or 4077 etc.
I'm not having the above problem at all; works fine. If you have a dtmf
statement in your incoming iax.conf context, remove it.
> 2) If the extension number was correctly received by asterisk and I pass
the call to a SIP
extension I would then lose Audio
> until the phone is answered.  If I simply pass the call to a SIP Extension
without playing any
prompts and I don't use the answer
> command before I transfer the call, then I can hear the ringing audio just
fine.
This is a known issue with livevoip.com service. It's my opinion this
is really a design issue within asterisk, but Mark disagrees.

The problem is * must answer the incoming iax call from livevoip in
order to execute the IVR menues. When the caller then dials an extension 
number, * responds to livevoip with "ringing" expecting livevoip to
provide the ringing to the caller. Since the call is in "answered"
mode, livevoip is simply ignoring the iax "ringing" command. Its my
opinion the livevoip is properly ignoring that iax function as the
call path has already been cut through, end-point to end-point.

If you analyze this interaction in terms of real telephony standards,
iax should _not_ be issuing the "ringing" function back to livevoip,
but rather providing an inband audio ringback.

So, your only choice is to live with it, or jump through hopps to
play an audio ringback within your extensions.conf context.

> > 1) When an incoming call to my DID number is initiated, a prompt is 
> played so that the caller
>can enter an extension number or
> > zero for the operator.  However, at least 30%-50% of the time the 
> digits that are entered from
>the touch tone phone is slightly
> > different from what is received by asterisk.  There is usually double 
> digits when only one of
>those digits were entered.  For
> > example I would enter 4071, but asterisk would receive 4007 or 4077
etc.
>
>I'm not having the above problem at all; works fine. If you have a dtmf
>statement in your incoming iax.conf context, remove it.
That was the first thing I looked for when I started having that 
problem.  I do NOT have any DTMF statements in my IAX, SIP or Extension 
configuration files in asterisk.  I have gone through all the configuration 
files and have not found anything that may contribute to this 
problem.  However, how would you explain that the fact callers never 
experience that problem with Sixtel DID numbers.  The only difference 
between Livevoip and sixtel DID that I am using is that I am getting 1800 
DIDs from Livevoip and with Sixtel I am using local DIDs for my area.

> > 2) If the extension number was correctly received by asterisk and I 
> pass the call to a SIP
>extension I would then lose Audio
> > until the phone is answered.  If I simply pass the call to a SIP 
> Extension without playing any
>prompts and I don't use the answer
> > command before I transfer the call, then I can hear the ringing audio 
> just fine.
>
>This is a known issue with livevoip.com service. It's my opinion this
>is really a design issue within asterisk, but Mark disagrees.
>
>The problem is * must answer the incoming iax call from livevoip in
>order to execute the IVR menues. When the caller then dials an extension
>number, * responds to livevoip with "ringing" expecting livevoip
to
>provide the ringing to the caller. Since the call is in "answered"
>mode, livevoip is simply ignoring the iax "ringing" command. Its
my
>opinion the livevoip is properly ignoring that iax function as the
>call path has already been cut through, end-point to end-point.
I under what you are saying perfectly.  What I don't understand is why I do 
NOT have that problem with other providers like Sixtel.  Do you think that 
Sixtel responds back providing the ringing to the caller?  Is it possible 
for Sixtel to know that the call was not really answered but was 
transferred to an extension.  I have no idea what Sixtel is doing, but 
maybe Livevoip should look into a way around this issue.