[Users] Accounting wrong BYEs

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Jul 18 15:57:44 CEST 2006

Klaus Darilion wrote:

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

not sure if this makes sends - how the UAC is aware of the parallel 
forking? the fork is transparently done by the proxy and it is the only 
one to manage the branches.

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

by default the timeout is almost a day - I do not thing that realistic 
calls exceed this value. Also the time out timer is reset by any 
sequential requests.


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