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

Hi Federico, thanks for troubleshooting it so far..really helpful . I will start looking what might be the impact of uac_replace_from() over the avps.....

regards, bogdan PS: what from_restore_mode are you using?

Federico Giannici wrote: > Hi, Bogdan. > > I have found the exact situation and function that cause the problem: > it is the uac_replace_from() function when called by an INVITE > retrasmission! > > I discovered this because I found that I can avoid the problem simply > testing if an INVITE is a retrasmission (with the t_lookup_request() > function) and in this case immediatly execute an "exit". In this way > the AVPs no longer disapper from the accounting. > > If I position this test immediately before the call to > uac_replace_from(), then the AVPs are still present. If I position > this test immediately after the call to uac_replace_from(), then the > AVPs disappear from the accounting! > > Now, I think that you should intervene because I think that I don't > have the "know how" to fully understand the internal functioning of > the uac_replace_from()... > > Tell me if you need any more information. > > > Bye. > > > > Federico Giannici wrote: > >> Bogdan-Andrei Iancu wrote: >> >>> Hi Frederico, >>> >>> it;s not sure for me what the scenario is: you have calls to PSTN >>> which hits failure_route in order to perform auth and from mangling >>> via UAC module, right? >> >> >> >> >> Yes. >> >> Actually, the from mangling is done in the route, the auth mangling >> in the failure_route. >> >> >>> and if there are retransmissions of the INVITE the AVPs disappear - >>> where exactly on the path? >> >> >> >> >> 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. >> >> >>> can pin point? and if there are no retransmissions, everything is ok? >> >> >> >> >> 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. >> >> >>> by the way we are talking about ACK or INVITE? >> >> >> >> >> 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.