On Thu, 2008-12-18 at 18:57 +0100, Alex Hermann wrote: > On Thursday 18 December 2008 18:38:53 Paul Kyzivat wrote: > > You are tying this to the GW because the GW has a cost to you? > > If so, then why isn't it the GW that is generating the accounting? > > > > Or are you saying that you are routing the call to a GW, not controlled > > by you, that will bill you? And you want to generate your own accounting > > so you can bill back *your* customer? > > > Why would I let a GW do accounting? The GW is just a dumb device and not all > GW's are the same brand/type. To get them to do accounting requires a lot of > work and post-processing as they can't do rating realtime because of all the > different rateplans and other client specific stuff. > > All logic, accounting and rating is done in the proxy. It's a logical place > to > also do the accounting there. No need to do post-processing or jumping > thriough hoops to get the GW to do what I want.
Let's not make the situation more confusing than it already is. First off, doing quality accounting requires a considerable amount of care. For example, this case is one where one UA issues a BYE that is rejected by the other UA. So even with completely legitimate UAs, the call remains set up. But it is easy for a sloppily-designed accounting system to *think* that the BYE has taken effect and terminate charging. This is less a matter of "being vulnerable to fraud" than "handling an exceptional case incorrectly". You must think through all possible exceptional cases. Second, the "philosophical" difficulty posed in the original message doesn't really exist -- charging is inherently dialog-stateful, so whatever system component is calculating the charges must be dialog-stateful. But that component need not be the proxy. For example, the proxy can dialog-statelessly log "call state events" (e.g., "INVITE" and "BYE"), which a post-processor can then assemble into call records. In regard to what to charge for -- Of course, in the long run, competition will eliminate charging for any activity which is not costing money. However, in many SIP systems, while the proxy is effectively free, the proxy is used to control and account for network elements that are not free. But to make that work, one has to pay attention to "control" and "account". First, there must be appropriate measures to ensure that the proxy controls (or at least knows of) every protocol action that can affect the costly actions of the expensive element. Second, the charging system should be focused not on SIP abstractions like "dialog state" but rather on the actual expensive activities like "gateway channel usage". E.g., in the original case, if the proxy data collection were architected from this point of view, what to do is obvious: "BYE goes to gateway, gateway responds with failure response, hence there has been no change to gateway usage that needs to be logged". Clearly, our data-collection activity must watch both requests and responses to/from the gateway, or it cannot monitor what the gateway is doing. -- Because we have focused on the important factors, it is easy to see what the proxy must do. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
