[Users] Accounting wrong BYEs

[Klaus Darilion]

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.

regards
klaus

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