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

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?

and if there are retransmissions of the INVITE the AVPs disappear - where exactly on the path?

can pin point? and if there are no retransmissions, everything is ok?

by the way we are talking about ACK or INVITE?

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.