On Fri, 2009-06-12 at 09:27 -0400, Gertsvolf, Mark (CAR:9D30) wrote: > Scott Lawrence wrote: > > > Then just resolve the issue as External System Error (with > > all the good > > documentation of how it happened from this thread). We don't want to > > add psychic interpretation to the CDR mechanism - if we don't > > have evidence, we should not come to any conclusion. > > > > The one way we could possibly improve accuracy would be to > > require that the call resolver see _both_ the 2xx response > > _and_ the ACK before concluding that the call is In Progress, > > but I don't see how that would really make the user situation > > much better in this case - you'd just be stuck in that new > > state rather than the current one. The possibility of > > endpoints that drop calls without sending proper signaling > > will always be there, and they _should_ look odd in CDRs, > > because they _are_ odd. > > > I think we are focusing on the wrong side of the problem. > There are situations, where ACK from call originator does not make it to > the callee. In such cases CDR mechanism relies on the callee to > disconnect the call by sending a BYE.
Correct, and for the time being at least I think that dependency is fine. I'd rather focus our efforts on making it easy to diagnose and correct any problems with the delivery of signaling than to try to make CDRs look normal when the signaling is broken. > We have an endpoint, which is used > in many of our deployments, that for whatever reason does not send the > BYE. > I would like to understand whether the endpoint is obligated to send a > BYE. This should tell us whether decision in CDR to rely on BYE in this > case makes sense. I think that Raymond correctly documented that an endpoint that does not receive a timely ACK is required to send the BYE to clean up. > At the same time if the gateway does not behave as prescribed we should > alert the gateway vendor and pressure him to resolve the issue. I've asked Raymond to open issues with them on both of the problems seen in that issue. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
