Re: [Serusers] Re: [Users] AVPs are lost on relayed INVITE errors

Bogdan-Andrei Iancu wrote: Yes. Actually, the from mangling is done in the route, the auth mangling in the failure_route. They are still there at the end of the route (after the final t_relay), before and after the corresponding onreply_route and failure_route. But they are not there when the accounting is done. Yes, with no retrasmission I never found that they disappear. Moreover I was able to reproduce the problem only when the UAC module is used. I'm talking about the INVITE. I'm not an expert of SER internals, but I have a suggestion: could it be related to the way the uac_auth() function (in modules/uac/auth.c) chooses the branch to use when there is a retrasmit? Thanks. > Federico Giannici wrote: > >> The problem is surely related to the retrasmission of the INVITEs >> and probably to the UAC module. >> >> I was able to reproduce the problem (AVPs vanishing) by adding a >> delay of 3 seconds for every message received. In this way a caused >> a couple of retrasmission for each message. Moreover that occurred >> only to the calls to a PSTN gateway using by the UAC module for >> authenticatuion and From substitution. >> >> In this case the INVITE's AVPs are no more present when the INVITE >> is logged by the ACC module (even if they were present before >> entering the transaction engine). >> >> If calls are made to other voip users (not using the UAC module) or >> if there is non INVITE retrasmission, the AVPs are correctly found. >> >> BTW, I used the t_lookup_request() function to test if the message >> is a retrasmission. It turned out that that INVITE and BYE >> retrasmissions are correctly identified, but not the ACK >> retrasmission. I don't know if this is the correct behaviour. >> >> I hope this information can be useful to find the problem. >> >> Thanks. >> >> >> >> Federico Giannici wrote: >> >>> The mistery keeps increasing! >>> >>> I have found that if I set an AVP in an INVITE message, then the >>> same AVP is logged in the ACCOUNTING of the corresponding ACK >>> message! >>> >>> But it is NOT in the ACK message before it enters the transaction >>> engine (with a t_relay()). So it is the transaction engine that >>> "copies" the INVITE AVPS to the ACK. Or the accounting routines >>> use the AVPs from the corresponding INVITE instead of the ACK ones. >>> >>> Is this the expected behaviour? >>> Why this happens? >>> >>> Thanks. >>> >>> >>> >>> Federico Giannici wrote: >>> >>>> I'm still not able to make these errors reproducible. >>>> >>>> Now I found that the "AVPs vanishing" occours with 200 OK >>>> situations too. It seems to be related to packets retransmission. >>>> They occur when the following errors are logged: >>>> >>>> Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: t_newtran: >>>> transaction already in process 0x502bbc58 >>>> Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: sl_reply_error used: >>>> I'm terribly sorry, server error occurred (1/SL) >>>> >>>> These are generated by this classic code: >>>> >>>> if ( !t_relay() ) >>>> { >>>> sl_reply_error(); >>>> } >>>> >>>> Now I'm asking myself: is it correct to reply to a message that >>>> is a retrasmission? Shouldn't we simply ignore it? Couldn't it >>>> confuse the UAs? >>>> >>>> Thanks. >>>> >>>> >>>> >>>> Federico Giannici wrote: >>>> >>>>> Bogdan-Andrei Iancu wrote: >>>>> >>>>>> Hi Federico, >>>>>> >>>>>> use avp_print() (works only with debug=9) in failure_route to >>>>>> inspect the list of present AVP. maybe you do not have the AVPs >>>>>> you are trying to log. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> But I set those AVPs in EVERY message received by the server. >>>>> Moreover, I'm SURE they are there because before forwarding >>>>> those INVITEs with t_relay() I log the messages to syslog and >>>>> the AVPs ARE THERE. >>>>> >>>>> Then, when some kind of errors are received (488, 422, etc.) it >>>>> seems that those AVPs are "lost" by the transaction engine... >>>>> But I'm not sure what conditions cause this lost. >>>>> >>>>> Bye. >>>>> >>>>> >>>>>> Federico Giannici wrote: >>>>>> >>>>>>> Daniel-Constantin Mierla wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> have you set the flag to log missed transaction? >>>>>>>> http://openser.org/docs/modules/1.0.x/acc.html#AEN407 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> No, I set the following: >>>>>>> >>>>>>> modparam("acc", "db_flag", 1) >>>>>>> modparam("acc", "failed_transaction_flag", 1) >>>>>>> >>>>>>> But no "db_missed_flag". >>>>>>> Anyway: >>>>>>> >>>>>>> 1) I don't want to log missed calls in a separate table. >>>>>>> >>>>>>> 2) The failed INVITEs are actually logged in the normal table, >>>>>>> but the AVPs I set are not logged (it seems that they are not >>>>>>> found). >>>>>>> >>>>>>> In normal cases the AVP are correctly logged. Even in many >>>>>>> error cases (404, and so on) they are logged too. But in some >>>>>>> cases, with strange errors (488, 422), the AVPs are NOT logged >>>>>>> (accounting is done, but AVPs are "n\a")! >>>>>>> >>>>>>> Any explanation of this? >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> >>>>>>>> Or is that the some avps are not any more stored for failed >>>>>>>> transaction? Maybe some snippets of your config will give us >>>>>>>> more hints about what happens there. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Daniel >>>>>>>> >>>>>>>> On 11/26/05 14:04, Federico Giannici wrote: >>>>>>>> >>>>>>>>> I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64. >>>>>>>>> >>>>>>>>> I have a strange problem with the accounting: I set a couple >>>>>>>>> of AVPs for every message that arrives at the server. I'm >>>>>>>>> sure they are there because they are written in the syslog >>>>>>>>> logging. Sometimes, when an INVITE is relayed (with >>>>>>>>> transactions) and receives an error (488, 422, etc.), in the >>>>>>>>> SQL logging there is no more presence of the AVPs! >>>>>>>>> Is this a known problem? >>>>>>>>> How can I avoid this? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>