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