> 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 _______________________________________________ -- 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
