[Users] Accounting wrong BYEs

Klaus Darilion klaus.mailinglists at pernau.at
Tue Jul 18 15:47:36 CEST 2006

Bogdan-Andrei Iancu wrote:
> Hi Dimo,
> I'm afraid there is no solution for you at the moment - probably the 
> best way is :
> 1) do not use that UAC since sending BYE before 200 OK is not RFC compliant

It is complient. If the call is forked and the UAC want to cancel only 
one of the branches it should send a BYE within the respective dialog.

> 2) configure your billing system to ignore BYEs without INVITE record.
> maybe in the future we will extend the dialog module to have a new 
> function to check if the BYE matches a current dialog or not.

But this will cause problems for real long call which have timed out in 
the dialog module.


> regards,
> bogdan
> Dimo wrote:
>> 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
>>> >
>> ------------------------------------------------------------------------
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users

More information about the sr-users mailing list