[Serdev] Radius stop record delay

[Jiri Kuthan]

At 05:06 PM 8/19/2004, Dan Pascu wrote:
>On Thursday 19 August 2004 17:02, Jiri Kuthan wrote:
>> >I think this is an issue only when viewed from a technical point of view.
>> > From the end user point of view is a non-issue. The user paying the bill
>> > for his call, will surely want the call ended when he hangs up the phone,
>> > no matter what the other party wants or believes about the validity of
>> > the BYE message. I'm sure none wants to pay extra bills just because the
>> > other party refuses to close a phone conversation.
>>
>> That does not seem to me so clear. For example, it would then to easy for
>> me to generate a BYE which gets denied by UAS and will be taken as input
>> for your accounting. What I am telling is I suggest that accounting module
>> provides objective, accurate and detailed reports (no special-casing) and
>> the back-end systems interpets them. Rating, fraud-detection and other
>> billing functionality is a back-end responsibility and should IMHO stay
>> there.
>
>This can be seen the other way around too. It would be easy for me to have a 
>modified SIP client that refuses any BYE message it receives. Then you call 
>me from PSTN and when you hang up, my phone will keep the conversation open 
>for days and you receive a huge bill from your PSTN provider and you can do 
>nothing about it.

Sure -- there is fairly large grey zone and it is a matter of proper interpretation 
of what is going on. My architectural preference is NOT to introduce billing 
interpretation to SER and let its role of an objective reporter instead. 


>I see little reason to deny a BYE message (one is to avoid someone willing to 
>tamper with someone's else conversation by closing it with a faked BYE 
>request), but I see much more dangerous exploits that can arise from denying 
>BYE messages. Probably the issue here is to correctly be able to determine if 
>the BYE comes from the one of the 2 parties. In such a case I see no real 
>reason for one party to keep the connection open once the other party has 
>asked for it to be closed.
>
>Anyway, regarding the accounting stuff I don't think we disagree. I'm not 
>locked on the idea that accounting should be sent when BYE arrives, but only 
>that I would like to know when BYE has arrived. Sending an absolute timestamp 
>is problematic (depends on ser and radius being in the same timezone and 
>being time synchronized). But we can send the time difference between the BYE 
>request and the moment the stop accounting message is sent and use that to 
>compute the real time of the BYE request arrival.

That's a possible design option. We can send also both timestamp for receipt
of request and reply. I don't have any strong preferences on these. Maybe I like
timestamps generated by SER on receipt of SIP message better than timestamps
generated by RADIUS server on receipt of RADIUS message -- it is yet another
communication link which can affect accuracy.

-jiri

-jiri