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

[Klaus Darilion]

Steve Underwood schrieb:
> Klaus Darilion wrote:
>> Atis Lezdins schrieb:
>>   
>>> 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.
>>>     
>> That's not the problem. Asterisk should just relay back the 488 so that 
>> Faxing happens with g.711.
>>   
> 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.

regards
klaus