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

Federico Giannici giannici at neomedia.it
Wed Nov 30 18:16:00 CET 2005 

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 sr-users mailing list