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

[Steve Underwood]

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.

Regards,
Steve