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

[Iñaki Baz Castillo]

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ñaki Baz Castillo