[Serdev] Radius stop record delay

[Jan Janak]

I was thinking about the following case:

UA              acc Proxy              UA
--              ---------              --
|     BYE           |                   | 
|------------------>|     BYE           |
|                   |------------------>|
|                   |  401 Unauthorized |
|  401 Unauthorized |<------------------|
|<------------------|                   |
|                   |                   |
|      BYE          |                   |
|------------------>|       BYE         |
|                   |------------------>|
|                   |      200 OK       |
|       200 OK      |<------------------|
|<------------------|                   |
|                   |                   |

Where the first transaction is challenged by one of the user agents and
the other user agent creates the second transaction. 

My common sense tells me that the first transaction would not terminate
the session, the 2nd transaction would. I am thinking about SIP devices
that might not have receivers -- you click a button to terminate
the session, it pops up a window "Terminating session" and considers the
session terminated when the BYE transaction times out or is confirmed.
During this period you can still send/receive media.

But because it is hard to use common sense when thinking about SIP I looked 
into the  RFC3261 and indeed -- it reads in section 15.1.1:

   Once the BYE is constructed, the UAC core creates a new non-INVITE
   client transaction, and passes it the BYE request.  The UAC MUST
   consider the session terminated (and therefore stop sending or
   listening for media) as soon as the BYE request is passed to the
   client transaction.  If the response for the BYE is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
   response at all is received for the BYE (that is, a timeout is
   returned by the client transaction), the UAC MUST consider the
   session and the dialog terminated.

Since the UAC terminates the session immediately, it makes sense not to wait 
for the final reply and account BYE transaction immediately.

You are right, we will change the behaviour of acc, thanks for the
notification.

  Jan.

On 17-08 11:16, Adrian Georgescu wrote:
> Jan, do you have an example or reference documentation of how can one 
> refuse a BYE? If I hang up the phone, the call is physically dropped 
> and personally (me paying the bill) I don't care what the other party 
> does (like not wanting to hang up). If the other party does not 
> acknowledge the call must end does it mean the accounting will go on 
> because is syntactically correct?
> 
> On Aug 17, 2004, at 10:31 AM, 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.
> >
> >    Jan.
>