Steve Underwood schrieb: > Klaus Darilion wrote: >> Atis Lezdins schrieb: >> >>> On Mon, Jun 8, 2009 at 2:06 PM, Klaus >>> Darilion<[email protected]> 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 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
