[Serusers] Re: [Users] AVPs are lost on relayed INVITE errors
Federico Giannici
giannici at neomedia.it
Thu Dec 1 20:22:38 CET 2005
Bogdan-Andrei Iancu wrote:
> 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.....
Nice to hear you, Bogdan.
I looked at the source of uac_replace_from() and cannot see anything
related to AVPs. Probably the real problem is in the TM engine, and
uac_replace_from() simply "trigger" it.
Anyway, you will surely be better than me to find the real cause...
> regards,
> bogdan
>
> PS: what from_restore_mode are you using?
I'm using "auto".
Bye.
> 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.
--
___________________________________________________
__
|- giannici at neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________
More information about the sr-users
mailing list