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. 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. 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. Thanks, Mark. _______________________________________________ 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/
