OCS的前世今生

   你还是没有搞清楚问题的重点在哪啊。用你的例子
1、  你打进一个电话
2、  交换机告诉 OCS 系统（或者是通过智能网系统转发）通话的详细情况
3..............
其实关键就在1、2两步之间，“你打进一个电话”后，交换机是在你摘机后就“诉 OCS 系统”，还是等你挂机后再“诉 OCS 系统”。这才是问题的关键！
   拿最普遍的cc08来说，9到14字节是摘机时间，15到20字节是挂机时间。那么既然话单里都有挂机时间这项，那么可以简单的推理出这条话单是在客户挂机后产生的，那么任何上层系统最早都得在客户挂机后才能得到这条话单的信息，这样的话何来“实时控制”？
   所以说，ocs是建立在智能网交换机所提供的摘挂两单的功能上的，没有这一功能ocs根本无从谈起。所以ocs的核心其实是能对摘机事件及时响应的话单采集系统，这涉及到去重、长单合并、高密度采集等等方面。而真到了余额限制这一步的算法相对来讲是很简单的。

“你打进一个电话”后，交换机是在你摘机后就“诉 OCS 系统”，还是等你挂机后再“诉 OCS 系统”。

——这个问题我应该说清楚了吧。挂机是在后面步骤啊。


在我曾经开发过的INGW——智能网网关——系统里面，你的电话一接通，前端就会把开始通话时间，主叫号码，发话地点等信息发过来。挂机后，前端再把结束时间发过来。两个消息组成一个完整的话单。

当时的前端是改造后的智能网系统。

在我们那个系统里面剃重并不是重点，长单和密集采集是对系统要求比较高的地方。同时，要在比较快的时间能响应前端，对于后台计费系统的处理速度也是一个考验。