[Serdev] Radius stop record delay

[Dan Pascu]

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.

>
> 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

-- 
Dan