On Thu, 2008-10-16 at 11:14 -0400, Raymond Dans wrote: > 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?
That seems reasonable. I think we could still not log a CSE for the 407 challenges, but it's not a big difference so if you'd rather just log them all, go ahead. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
