<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I beg to differ, but this is just my humble opinion based on my experience with my particular customers.<div><br></div><div>The most economic and future-proof way to perform accounting for SIP sessions is the SIP Proxy server alone.</div><div><br></div><div>My personal experience is that gateways come and go in a provider configuration and they are in many cases under the control of a third-party that provides the PSTN termination service. When you do LCR across many different gateways, which are not even yours the only aggregation point for traffic is the SIP proxy that authenticates and authorizes the requests. Over time, the gateways change hands, get upgraded or removed much more often then the proxy itself, which maintains its central role over time. Secondly, once you do more the voice like video and other services that require billing and are not PSTN related, the SIP Proxy is the only network element that has access to the signalling and is able to generate accounting tickets.</div><div><div><br></div><div><div>Solving the accounting related problems at the SIP Proxy level is a worthwhile investment while other options are just temporary fixes that work in a particular case for a limited amount of time and that is a waste of money.</div><div><br></div><div>Adrian</div><div><br></div><div><div><div><div><div><div>On Jan 7, 2009, at 2:25 AM, Jiri Kuthan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>authentication does not provide actually value here. dialog would not <br>either, since<br>the same trick can be achieved for example by low max-forwards. IMO the <br>proper<br>choice is accounting from the gateway, which provides the actual service.<br>A proxy can only provide an approximation which is inherentely to some <br>extent<br>more error-prone than the box doing the actual job.<br><br>-jiri<br><br>Bogdan-Andrei Iancu wrote:<br><blockquote type="cite">Hi Iņaki,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Have you consider requesting auth for the BYE ? from SIP point of view <br></blockquote><blockquote type="cite">is perfectly valid....<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regards,<br></blockquote><blockquote type="cite">Bogdan<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Iņaki Baz Castillo wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Hi, I'm thinking in the following flow in which the caller/attacker<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would get an unlimited call (but a limited CDR duration):<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--------------------------------------------------------------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">attacker OpenSIPS (Acc) gateway<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">INVITE (CSeq 12) ------><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><-------- 407 Proxy Auth<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">INVITE (CSeq 13) ------><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> INVITE (CSeq 13) ------><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> <------------------- 200 Ok<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><------------------- 200 Ok<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> << Acc START >><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ACK (CSeq 13) -----------><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> ACK (CSeq 13) -----------><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><******************* RTP ************************><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"># Fraudulent BYE !!!<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">BYE (CSeq 10) -----------><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> << Acc STOP >><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> BYE (CSeq 10) -----------><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> <-- 500 Req Out of Order<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><-- 500 Req Out of Order<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--------------------------------------------------------------------------<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The call hasn't finished, but OpenSIPS has ended the accounting for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this call since it received a BYE. And this BYE will generate a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">correct ACC Stop action (since it matches From_tag, To_tag and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Call-ID).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I think this is *VERY* dangerous and I hope I'm wrong.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Would help the dialog module here? does the dialog module check the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">CSeq of the BYE in some way and could it prevent OpenSIPS from<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">generating the ACC STOP action? (I don't think so).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Any idea?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Users mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote><blockquote type="cite"><br></blockquote><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></div></blockquote></div><br></div></div></div></div></div></div></body></html>