[Users] Accounting wrong BYEs

Klaus Darilion klaus.mailinglists at pernau.at
Tue Jul 18 16:26:03 CEST 2006

Bogdan-Andrei Iancu wrote:
> 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.

Not sure about this, but what about:

If it receives several 180/183 with different to-tags, the client has to 
maintain several dialogs in "early-dialog" state.

If the UAC sends the BYE in-dialog, it gets routed to the proper UAS, 
which will response to the INVITE dialog with 487 Request terminated. 
This should cancel this single branch inside the proxy.


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