asterisk users - Jun 2009 - T.38 pass-through 488 handling problem

Hi!

I have the following problem with Asterisk 1.4.23:


ATA w/ T.38             Asterisk          ATA w/o T.38
     --------INVITE-------->
                             --------INVITE-------->
                             <-------200OK----------
     <-------200OK----------
     --------ACK----------->
                             --------ACK----------->


     --------INVITE w/T.38->
                             ------INVITE w/ T.38-->
                             <-----488--------------
                             ------ACK------------->
                             ------BYE------------->
                             <-----200--------------

Asterisk does not forward the 488 back to the caller, but hangs up the 
callee's call leg. Further, the caller's call leg will not be hung up.

Is somebody aware of this problem and a fix?

thanks
klaus

On Mon, Jun 8, 2009 at 2:06 PM, Klaus
Darilion<klaus.mailinglists at pernau.at> wrote:
> Hi!
>
> I have the following problem with Asterisk 1.4.23:
>
>
> ATA w/ T.38 ? ? ? ? ? ? Asterisk ? ? ? ? ?ATA w/o T.38
> ? ? --------INVITE-------->
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? --------INVITE-------->
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? <-------200OK----------
> ? ? <-------200OK----------
> ? ? --------ACK----------->
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? --------ACK----------->
>
>
> ? ? --------INVITE w/T.38->
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ------INVITE w/ T.38-->
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? <-----488--------------
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ------ACK------------->
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ------BYE------------->
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? <-----200--------------
>
> Asterisk does not forward the 488 back to the caller, but hangs up the
> callee's call leg. Further, the caller's call leg will not be hung
up.
>
> Is somebody aware of this problem and a fix?
>
T.38 passthrough is possible if BOTH devices support T.38, so Asterisk
don't have to transcode anything.

You could try 1.6 with some gateway app (don't remember if there
exists any and in what state), or just write a RxFax which would then
generate call with TxFax.

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

Klaus Darilion <klaus.mailinglists at pernau.at> writes:
> Asterisk does not forward the 488 back to the caller, but hangs up the 
> callee's call leg. Further, the caller's call leg will not be hung
up.
>
> Is somebody aware of this problem and a fix?
This should be fixed in 1.6.x. At least I had pretty much that scenario
break on me in 1.4.2x, and 1.6.0.5 worked.


/Benny

> Klaus Darilion wrote:
>> Steve Underwood schrieb:
>>   
>>>     
>>> There seems to be a common misconception about 488. It represents
an
>>> irrevocable failure of the call. Once a 488 is sent the call is
>>> essentially dead. A number of systems are able to continue beyond a
488,
>>> and allow further renegotation to another codec, but that it
>>> non-standard behaviour. The correct thing is to offer the options
of
>>> T.38, u-law and A-law. If the other side can't do T.38, it
should accept
>>> u-law or A-law. If it says 488, your dead.
>>>     
>> 
>> I tend to disagree. From RFC 3261, page 16:
>> 
>>   
>>>    ...The requestor responds to the 200 (OK) with an ACK.  If the
other
>>>    party does not accept the change, he sends an error response
such as
>>>    488 (Not Acceptable Here), which also receives an ACK.  However,
the
>>>    failure of the re-INVITE does not cause the existing call to
fail -
>>>    the session continues using the previously negotiated
>>>    characteristics.  Full details on session modification are in
Section
>>>    14.
>>>     
> I thought the same thing at one point, and kept complaining about things
> like Audiocodes, which just dump the call after sending a 488, and
> various other things which either dump the call or let the call continue
> but refuse to accept any further re-invites. Then someone pointed me to
> a later document that basically reverses what RFC3261 says. Right now I
> can find which document that was. Either way, its the real world that
> matters most. In the real world a lot of equipment will not behave well
> after a 488. We've had lots of experience with this in T.38 testing.
I'm chasing this very issue with Audiocodes on a Mediant 1000 right now.  Is
there any way to work around this?  Is there a way in asterisk to intercept
the 488/486 and suppress it's behavior to dump the call?

peter