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

[Bogdan-Andrei Iancu]

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.
>>>>>>>>>>
>
>