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

Federico Giannici giannici at neomedia.it
Thu Dec 1 17:57:08 CET 2005 

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.


-- 
___________________________________________________
     __
    |-                      giannici at neomedia.it
    |ederico Giannici      http://www.neomedia.it
___________________________________________________

More information about the Users mailing list