[Users] Accounting wrong BYEs

Dimo begeragus at gmail.com
Tue Jul 18 15:05:07 CEST 2006


Hi,
The INVITE is still in processing (no OK received) when the BYE
arrives. I relay the BYE to my Asterik which replies with 487
transaction canceled (see attachment).
I am accounting INVITES after i receive their OK.
So i do not account a call start on the INVITE because it is not
OK-ed, but I want in such cases not to account the BYE which cancels
the invite in progress.
I am relaying messages statefully.
Is there any way I can distinguish that the BYE is for a transaction
in progress and not flag it for accounting? I think, that when I
receive a BYE I can use t_check_trans() and if there is a transaction
in progress I will not flag it for accounting.
However, if the INVITE is OK-ed and the BYE comes shortly after, will
there still be a transaction in memory (waiting for wt_timer) and will
the t_check_trans() report the transaction as finished or ongoing? If
it says ongoing then i will not account a BYE I should.
Any possible way I can distinguish a "BYE which cancels an INVITE"
from "a real BYE for an end of call" works for me. Is there any way to
detect that?

Best,
Dimo

On 7/18/06, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> Hi,
>
> what happens with the INVITE transaction? how does it end from reply
> code point of view?
> If it is ok, there is nothing you can do - from SIP point of view, it
> will be a short call.
> If negative, depends of your acc config if the INVITE records is logged
> or not
>
> regards,
> bogdan
>
>
> Dimo wrote:
>
> > Hi all,
> > I have a problem with accounting wrong BYEs:
> > I have noticed that some UAs like the spa are sending BYE to cancel an
> > INVITE instead of a CANCEL message. Now openser is interpreting this
> > correctly, but the problem is with accounting which will account this
> > BYE as call stop. Since there was never OK to the invite, there is no
> > call start and just a call stop which makes my billing very unhappy.
> > Is it possible to have something in the accounting module that will
> > prevent such "fake" byes of being accounted?
> > I am also thinking how to script it in my config, what i have thought
> > of so far is when receiving a BYE to check if there is ongoing
> > transaction  and if there is, do not flag the BYE for accounting. This
> > however will probably result in some real BYEs not being accounted
> > too, because (correct me if wrong) the transaction will still exist in
> > mem for some short time after the OK is received.
> > Any help or suggestions will be greatly appreciated.
> >
> > Best,
> > Dimo
> >
> > _______________________________________________
> > Users mailing list
> > Users at openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrong-BYE.jpg
Type: image/jpeg
Size: 77633 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060718/dff71c29/attachment.jpg>


More information about the sr-users mailing list