[asterisk-users] T.38 pass-through 488 handling problem

[Peter Eisch]

> 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