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