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

Federico Giannici giannici at neomedia.it
Wed Nov 30 17:43:26 CET 2005


Hi, Bogdan.
No suggestion for this problem?

Today I made some other debugging and found that the AVP is still 
correctly set at the start and at the end of the onreply_route and 
failure_route corresponding at the INVITE.

And I still confirm you that the AVP is "lost" when there is a 
retrasmission and the message if forwarded with the autentication and 
from-modify by means of the UAC module.

No problem when there is no retrasmissin or for forwarding without the 
UAC module.

What else I can try?
What other information I can provide you?

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

         Presidente del cda - NEOMEDIA srl
___________________________________________________




More information about the Users mailing list