[Serdev] Radius stop record delay

[Bogdan-Andrei IANCU]

Dan Pascu wrote:

>On Wednesday 18 August 2004 03:07, Jiri Kuthan wrote:
>  
>
>>At 10:31 AM 8/17/2004, Jan Janak wrote:
>>    
>>
>>>On 17-08 10:19, Adrian Georgescu wrote:
>>>      
>>>
>>>>If a received BYE is not OK-ed the radius accounting record is
>>>>generated at BYE moment + fr_timer. In my opinion this is wrong, the
>>>>accounting is incorrect.
>>>>
>>>>- INVITE can generate START after OK
>>>>- BYE must generate STOP without waiting for OK
>>>>
>>>>Is this correct?
>>>>        
>>>>
>>> No. A user-agent might refuse a BYE and in that case you do not want
>>> to generate STOP. BYE/408 is used to detect a dead phone -- in that
>>> case we consider the BYE successful and generate OK.
>>>      
>>>
>>There are two issues here. The first is the BYE time -- I think that
>>reporting tge request receipt timestamp would be good for accuracy.
>>That takes a moderate change to the acc module.
>>    
>>
>
>An absolute timestamp is problematic if the ser machine and the radius machine 
>are in different timezones. You can only send delta times without problems.
>  
>
use unix timestamps (no TZ dependent) and ntpd to synchronize your 
machines. You don't need more.
bogdan

>  
>
>>The second issue is how to handle negative BYEs. I think that's back-ends
>>decision how to interpret these. Clearly, there may be some ambiguous
>>cases. A phone for example generates a BYE, which is either syntactically
>>incorrect or the receiver consideres it incorrect. The receiver generates a
>>negative reply. The receiver thinks the call is over. The BYE sender is
>>confused -- the handset has been hung up but a negative reply came back...
>>    
>>
>
>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.
>
>  
>
>>-jiri
>>
>>_______________________________________________
>>Serdev mailing list
>>serdev at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serdev
>>    
>>
>
>  
>