> > > Earlier, when all h323-xxx-time has been sent - these were just filled > > > with some useless values, like copying h323-disconnect-time to > > > h323-connect-time and h323-setup-time. This way, some call flow info > > > has been lost. > > > > This was not correct, in most cases unexpected behavior. Setup time > > should never be overwritten, being the time of ARQ or Setup arrival. For > > cisco boxes connect-time=disconnect-time for unconnected calls, but > > setup-time is kept in. The reason here is to have PDD value (very > > helpfull in troubleshooting). > > h323-setup-time cannot be sometimes ARQ time and sometimes Setup time I mean "being the time of ARQ arrival for registered endpoint and Setup arrival for permanent one"... maybe it should be always the Setup arrival time... I do not use gk functionality, proxy only... > - this way it is useless. It should be a time when Setup message has been > sent. If not Setup has been sent, then there is nothing to measure. Call processing time = Setup received time - ReleaseComplete sent time (for incomplete calls) But accounting dosn't work for incomplete or unathorized calls... so the discussion is a sort of flame in the context... ;) Michal, do you plan to implement incomplete or unathorized calls accounting? > If the call is not connected then we have both h323-setup-time and > h323-disconnect-time. I agree that this is _logically_ correct... again it's all about macro language for substitutions (CDR output format, Acct-Request templates etc)... The problem here is that we do not have easy to use and unified framework (Get/SetCallParameter1,2,...), but lots of if/else checks to get smth... > We cannot rely on connect-time=disconnect-time because we do not have > subsecond accuracy, so it is possible to have connect-time=disconnect-time > for a connected call. if AcctSessionTime is null it makes no sense to know if the call was or was NOT connected. Unless you charge for the fact of connect message arrival from network even when user has released the call before it ;) (this can't occur in end-to-end ISDN call, but in H.323 environemnt this is not a rare case...) > PDD is calculated as a time between Setup and Alerting message - we do not > send the second one, so what is your definition of PDD? Such a "correct" PDD definition is useless in real world ;) We may receive RBT just after CallProceeding (in FastStart mode) and not receive Alerting at all. I used to mean by PDD the time between Setup received from calling party and Connect received from called party for successful calls and Setup time minus ReleaseComplete time for unconnected calls. I don't see any sense in measuring time between Setup sent and Alerting received, basically because calling party usually disconnects not receiving Alerting in 3,5-4 secs. CallProceeding may be received/sent before Alerting, but T30x timer conditions are not usually implemented as per specs... :( > --- > Zygmuntowicz Michal -- Best regards, Andrey S Pankov. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ List: Openh323gk-users@lists.sourceforge.net Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
