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
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 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.
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Hi Dimo,
I'm afraid there is no solution for you at the moment - probably the best way is :
- 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.
- 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 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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 :
- 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.
- 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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 :
- 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
- 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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus,
it does sounds like a realistic scenario.
First of all the UAC may not discover all the branches based on To-tag - there might be branches that haven't sent any reply, or replies were absorbed by the forking server (ex: 180 after 183 will not be relayed).
Even so, when the BYE is generated, you cannot route it properly to the callee set because you do not have a unique routing set for the path. Different sets may be returned by each branch; also until the final reply the mirroring of RR hdrs is not mandatory. So there is the problem how to deliver the BYE to all the branches.
Even so, it suppose that the UAS understands a BYE before 200 OK and is able to f proper filtering based on the to tag parameter. Not sure how many clients will do this.
again, I do not say is not possible, but I find it highly unrealistic.
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
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.
Bogdan-Andrei Iancu wrote:
Hi Klaus,
it does sounds like a realistic scenario.
First of all the UAC may not discover all the branches based on To-tag - there might be branches that haven't sent any reply, or replies were absorbed by the forking server (ex: 180 after 183 will not be relayed).
Really? Why not? This is strictly valid and make sense. All gateways does this: INVITE --> SETUP ... 183 <-- PROGRESS w/ inband audio 180 <-- ALERTING
Even so, when the BYE is generated, you cannot route it properly to the callee set because you do not have a unique routing set for the path.
The client will have a route set for each early dialog.
Different sets may be returned by each branch; also until the final reply the mirroring of RR hdrs is not mandatory. So there is the problem how to deliver the BYE to all the branches.
This might be a problem. But it is mandatory for 18x: Record-Route 2xx,18x mr
Even so, it suppose that the UAS understands a BYE before 200 OK and is able to f proper filtering based on the to tag parameter. Not sure how many clients will do this.
This will be a problem too.
regards klaus
again, I do not say is not possible, but I find it highly unrealistic.
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
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.
was referring to a forking scenario:
UAC P UAS <----------------- 180 from UAS1 <-------------- <----------------- 183 from UAS1 <-------------- <----------------- 180 from UAS2 <---x---x---x-- this will not be relayed to UAC since a higher reply code was already sent, so the UAS2 will not be visible
regards, bogdan
Klaus Darilion wrote:
First of all the UAC may not discover all the branches based on To-tag - there might be branches that haven't sent any reply, or replies were absorbed by the forking server (ex: 180 after 183 will not be relayed).
Really? Why not? This is strictly valid and make sense. All gateways does this: INVITE --> SETUP ... 183 <-- PROGRESS w/ inband audio 180 <-- ALERTING
Bogdan-Andrei Iancu wrote:
was referring to a forking scenario:
UAC P UAS <----------------- 180 from UAS1 <-------------- <----------------- 183 from UAS1 <-------------- <----------------- 180 from UAS2 <---x---x---x-- this will not be relayed to UAC since a higher reply code was already sent, so the UAS2 will not be visible
regards, bogdan
Klaus Darilion wrote:
First of all the UAC may not discover all the branches based on To-tag - there might be branches that haven't sent any reply, or replies were absorbed by the forking server (ex: 180 after 183 will not be relayed).
Is this standard conform? What about
UAC P UAS <----------------- 183 from UAS1 <-------------- ???? 180 from UAS1 <--------------
Will this be forwarded?
klaus
Really? Why not? This is strictly valid and make sense. All gateways does this: INVITE --> SETUP ... 183 <-- PROGRESS w/ inband audio 180 <-- ALERTING
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
was referring to a forking scenario:
UAC P UAS <----------------- 180 from UAS1 <-------------- <----------------- 183 from UAS1 <-------------- <----------------- 180 from UAS2 <---x---x---x-- this will not be relayed to UAC since a higher reply code was already sent, so the UAS2 will not be visible
regards, bogdan
Klaus Darilion wrote:
First of all the UAC may not discover all the branches based on To-tag - there might be branches that haven't sent any reply, or replies were absorbed by the forking server (ex: 180 after 183 will not be relayed).
Is this standard conform? What about
UAC P UAS <----------------- 183 from UAS1 <-------------- ???? 180 from UAS1 <--------------
Will this be forwarded?
no, it will not be forwarded.
regards, bogdan
Bogdan-Andrei Iancu wrote:
Klaus Darilion wrote:
Is this standard conform? What about
UAC P UAS <----------------- 183 from UAS1 <-------------- ???? 180 from UAS1 <--------------
Will this be forwarded?
no, it will not be forwarded.
IMO this is not good. Lots of gateways (asterisk, Cisco) send first 183, and then 180, which is typical as all the ISDN lines I worked with send PROGRESS, and after that an ALERTING message.
regards klaus
-
Bogdan-Andrei Iancu -
Dimo -
Klaus Darilion