[Kamailio-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?

[Daniel-Constantin Mierla]

On 12/20/08 13:25, Iñaki Baz Castillo wrote:
> El Sábado, 20 de Diciembre de 2008, Daniel-Constantin Mierla escribió:
>   
>> On 12/20/08 11:55, Iñaki Baz Castillo wrote:
>>     
>>> El Sábado, 20 de Diciembre de 2008, Daniel-Constantin Mierla escribió:
>>>       
>>>>> Yeah. With radius it should be easy, since the SQL query for SOP action
>>>>> will ensure that it wasn't a previous matching BYE.
>>>>>           
>>>> I don't really get it ... would it select the first or last BYE for a
>>>> call? Will it accept many BYEs for same call or will trigger failure?
>>>>         
>>> You can configure the SQL "UPDATE" query for the accounting STOP action
>>> in radius, so for example:
>>> - The first matching BYE will fill a row field "completed" and set it to
>>> "1". - At the same time the SQL query has a "WHERE completed = 0".
>>>
>>> In this way, just the first BYE will trigger an UPDATE SQL query. Any
>>> other BYE will be discarded by MySQL server because doesn't honor the
>>> "WHERE" clausule and will no "re-update" the accounting row.
>>>       
>> But, in this case, the last one should be the right one.
>>     
>
> Well, not sure of which case exactly you mean now. I think that the accounting 
> proxy should ensure that a fraudulent BYE can't not be the first one in 
> triggering the STOP action.
>   
I see the proxy just as a reporting point, sending to accounting system 
all events within a session:
- START (200ok for INVITE, confirmed - ACK)
- UPDATEs (re-INVITE, other in-session requests)
- STOP (good, bad BYEs)

Then it comes the billing application that implements the logic to deal 
with different cases. Easiest one is when you have one STOP event, but 
if you have more, then you have to check for reply code, cseq, etc...

The proxy is critical because of the real-time nature of the 
communication. Billing can sit and digest peacefully, report abnormally 
cases, etc. Many tend to load the proxy with functionalities that don't 
belong there, then start complaining is not doing the job right or fast 
enough ... in every system you have to get to a compromise, not only in 
VoIP.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com