I do not say there is no penalty, but so far nobody was able to actually detect it (comparing with the rest of the load). Just be sure you enable the avp_onreply_mode param in TM
Regards, Bogdan Brett Nemeroff wrote: > Bogdan, > Thanks. got this working already. very nice! Question tho.. what kind > of performance hit should I expect by allowing avps to be available in > onreply route? > > -Brett > > > On Thu, Mar 26, 2009 at 8:17 AM, Bogdan-Andrei Iancu > <[email protected] <mailto:[email protected]>> wrote: > > there is a $Ts pseudovariable to get the current time from the > script. > > > Regards, > Bogdan > > Brett Nemeroff wrote: > > Oh cool.. I didn't know there was a timestamp method.. neato.. > thanks for the tip, I'll give it a shot. > -Brett > > > On Thu, Mar 26, 2009 at 7:43 AM, Bogdan-Andrei Iancu > <[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > hi Brett, > > well, this is a different story and you do not need acc . > what you > can do is to use onreply_route to catch the received 100 trying > and to save the current timestamp into an avp. in the same > route > catch the 180 also and make the diff and place this result into > another avp - account this avp via extra_accounting stuff. > > regards, > bogdan > > Brett Nemeroff wrote: > > Ah, I'm trying to capture the one from the UAS (far end). > > Really, I'm trying to, best I can, capture signalling > PDD. I > understand that this is probably subject to interpretation, > but in general, I measure PDD as the time between the first > 100 code and a 18X reply. Yes, admittedly a totally false > expectation. However, in my limited environment for this > application, I always get a 100 before a 18X and I'd > like to > be able to log the time delay in acc. > > I'd be interested in hearing other ways of doing what I'm > attempting.. Maybe something more sane.. > -Brett > > > On Wed, Mar 25, 2009 at 1:07 PM, Bogdan-Andrei Iancu > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > Hi Brett, > > You do not get it because the 100 Trying is locally > generated. The > callback you tried to change is called for replies > that were > received and fwded to the UAC. > > But the 100 is not fitting here because it is going > hop by > hop - > one locally generated and sent to UAC and the one > received from > UAS is discarded (not fwded). > > Regards, > Bogdan > > Brett Nemeroff wrote: > > Hey All, > I'm trying to log the 100 Trying in the acc > module. I tried > the acc_db_request, but it can't be called from > onreply. > > So I tried editing acc_logic.c, but that isn't > working > either?! :/ Any ideas? Maybe I should edit > acc_db_request so > it can be called from ONREPLY? > > > static inline int should_acc_reply(struct > sip_msg > *req,struct sip_msg *rpl, > > > int code) > { > /* negative transactions reported > otherwise only if > explicitly * demanded */ > if (code == 100) > return 1; > if ( !is_failed_acc_on(req) && code >=300 ) > return 0; > if ( !is_acc_on(req) ) > return 0; > if ( code<200 && !(early_media && > parse_headers(rpl,HDR_CONTENTLENGTH_F, > 0)==0 && > rpl->content_length && > get_content_length(rpl)>0 ) ) > return 0; > > return 1; /* seed is through, we will account > this reply */ > } > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
