XECS-1680 deals with Call records still showing active in the GUI after the call has been abandoned.
This issue has opened up other potential problems with how Call State Events (CSE) are being generated in the Proxy. The CSE generation in the Proxy is stateless so it only relies on the information in the current SIP message to determine whether or not to generate a new CSE. At present, for SIP errors (i.e. >= 400), it will only generate a failure CSE if the error is from an INVITE and the error is not 401 (Unauthorized), 407 (Proxy Authorization Required) or 408 (Request Timeout). Although this does trap most of the cases, it will not properly generate CSEs for errors that are important in the case of a re-Invite which will affect the call. In RFC 3261 section 12.2.1.12, it states that on requests within a dialog that receive a 408 (Request Timeout) or 481 (Transaction doesn't exist), the dialog should be terminated (i.e. the call torn down). In this particular case a call failure CSE should be generated but it isn't because we are stateless and we can't tell whether or not we're in a dialog. I would like to propose that for CSE generation, that if we get any SIP error (i.e. >=400) from an INVITE (or re-invite), that we generate a CSE. Determination (from the point of view of CDR records) of how this affects the call will then be handled in the CDR record generation which does maintain state information on the call (based on all of the CSEs for that call). This would then allow CDR to generate failure records in cases when no dialog existed (i.e. call not established) and in cases when the call was established and failed on a re-invite. FYI - the negative impact to this proposal is that more CSEs will be generated but because its only on error conditions that are from INVITEs, I don't believe it would be much of a database or processing hit. Any objections to adding some smarts in the CDR area to examine and understand SIP error messages as opposed to the Proxy CSE doing it? Thanks in advance Raymond _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
