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

[Adrian Georgescu]

On Jan 7, 2009, at 2:28 PM, Klaus Darilion wrote:

>
>
> Adrian Georgescu schrieb:
>> I beg to differ, but this is just my humble opinion based on my  
>> experience with my particular customers.
>> The most economic and future-proof way to perform accounting for  
>> SIP sessions is the SIP Proxy server alone.
>> My personal experience is that gateways come and go in a provider  
>> configuration and they are in many cases under the control of a  
>> third-party that provides the PSTN termination service. When you do  
>> LCR across many different gateways, which are not even yours the  
>> only aggregation point for traffic is the SIP proxy that  
>> authenticates and authorizes the requests. Over time, the gateways  
>> change hands, get upgraded or removed much more often then the  
>> proxy itself, which maintains its central role over time. Secondly,  
>> once you
>
> That's why I prefer a "virtual" gateway which is hosted myself. The  
> proxy does not send the calls directly to the gateway providers, but  
> to the "virtual" gateway, which does LCR, accounting ....
>
> These virtual gateway can either be a B2BUA (in the simplest case  
> Asterisk) or a SIP proxy with media relay or any other technique to  
> make sure that the CDRs are correct.

Right, this is more or less what I had in mind. For the sake of  
simplicity I would do this without duplicating the proxy but this is  
just a detail. The key is to have something in the media path, having  
it you can always take the right decision, account for the right  
duration and terminate calls whenever is considered appropriate. Now,  
with the advanced capabilities of the dialog module I am not sure what  
more functionality related to accounting an external B2BUA can provide  
that cannot be provided by this tandem with the dialog module and the  
right server logic.

With the risk of stating the obvious here is what I mean:

http://cdrtool.ag-projects.com/attachment/wiki/WikiStart/OpenSIPS-accounting.png

Adrian


> regards
> klaus
>
>
>> do more the voice like video and other services that require  
>> billing and are not PSTN related, the SIP Proxy is the only network  
>> element that has access to the signalling and is able to generate  
>> accounting tickets.
>> Solving the accounting related problems at the SIP Proxy level is a  
>> worthwhile investment while other options are just temporary fixes  
>> that work in a particular case for a limited amount of time and  
>> that is a waste of money.
>> Adrian
>> On Jan 7, 2009, at 2:25 AM, Jiri Kuthan wrote:
>>> authentication does not provide actually value here. dialog would  
>>> not
>>> either, since
>>> the same trick can be achieved for example by low max-forwards.  
>>> IMO the
>>> proper
>>> choice is accounting from the gateway, which provides the actual  
>>> service.
>>> A proxy can only provide an approximation which is inherentely to  
>>> some
>>> extent
>>> more error-prone than the box doing the actual job.
>>>
>>> -jiri
>>>
>>> Bogdan-Andrei Iancu wrote:
>>>> Hi Iñaki,
>>>>
>>>> Have you consider requesting auth for the BYE ? from SIP point of  
>>>> view
>>>> is perfectly valid....
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> Iñaki Baz Castillo wrote:
>>>>> Hi, I'm thinking in the following flow in which the caller/ 
>>>>> attacker
>>>>> would get an unlimited call (but a limited CDR duration):
>>>>>
>>>>> --------------------------------------------------------------------------
>>>>> attacker                     OpenSIPS (Acc)                     
>>>>> gateway
>>>>>
>>>>> INVITE (CSeq 12)  ------>
>>>>> <-------- 407 Proxy Auth
>>>>>
>>>>> INVITE (CSeq 13)  ------>
>>>>>                                             INVITE (CSeq 13)   
>>>>> ------>
>>>>>                                             <-------------------  
>>>>> 200 Ok
>>>>> <------------------- 200 Ok
>>>>>                         << Acc START >>
>>>>> ACK (CSeq 13) ----------->
>>>>>                                             ACK (CSeq 13)  
>>>>> ----------->
>>>>>
>>>>> <******************* RTP ************************>
>>>>>
>>>>> # Fraudulent BYE !!!
>>>>> BYE (CSeq 10) ----------->
>>>>>                         << Acc STOP >>
>>>>>                                             BYE (CSeq 10)  
>>>>> ----------->
>>>>>                                             <-- 500 Req Out of  
>>>>> Order
>>>>> <-- 500 Req Out of Order
>>>>> --------------------------------------------------------------------------
>>>>>
>>>>> The call hasn't finished, but OpenSIPS has ended the accounting  
>>>>> for
>>>>> this call since it received a BYE. And this BYE will generate a
>>>>> correct ACC Stop action (since it matches From_tag, To_tag and
>>>>> Call-ID).
>>>>>
>>>>> I think this is *VERY* dangerous and I hope I'm wrong.
>>>>>
>>>>> Would help the dialog module here? does the dialog module check  
>>>>> the
>>>>> CSeq of the BYE in some way and could it prevent OpenSIPS from
>>>>> generating the ACC STOP action? (I don't think so).
>>>>>
>>>>> Any idea?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090107/4e0c5fd5/attachment-0001.htm