OCS的前世今生
<p>????? 后记：我以前做c++时做过一个话单采集的项目，那时还是59字长，摘挂一单的时代了，过时很多年了，呵呵。</p> 9 楼 tower 2009-06-19 ubotutwin，你说的简单的摘挂，那是智能网就能做的。你还是好好看看我最后面说的那个例子，我觉得说的还是比较清楚。OCS在业务发生的过程中是有交互的。
例子一：
1、 你打进一个电话
2、 交换机告诉 OCS 系统（或者是通过智能网系统转发）通话的详细情况
3、 OCS 系统发现账户余额为 50 块，你打的又是市话的话，则给你做 6 块钱的授权，告诉交换机，先给你接续 10 分钟。此时，你账户可用余额还有 44 块钱，这时你就可以干点别的业务了（视频点播等）——如果只是支持摘挂，这里是实现不了的，至少不同的业务之间不能共用余额。
4、 10 分钟后你还没挂机，交换机在来找 OCS 系统在申请时长，依次反复，直到你主动终止业务或者是余额不足接续业务为止。
再补充一个例子：
例子二：
1、 你打进一个电话
2、 交换机告诉 OCS 系统（或者是通过智能网系统转发）通话的详细情况
3、 OCS 系统发现账户余额为 1 块，你打的又是市话的话，则给你做 6毛钱的授权，告诉交换机，先给你接续 1 分钟。此时，你账户可用余额还有 4毛钱
4、 在这一分钟内，你通过网上缴费或者其他方式，给你的手机充了50块钱
5、 一分钟到了，前端再来申请时长，OCS系统就可以给再做6块钱的授权，再给交换机10分钟通话
4、 5分钟后，你挂机了，前端告诉OCS系统，此次通话结束，结束时间是什么。
在这里要说明一下的是，在中国移动的INGW中，INGW系统和交换机（端局）之间是通过智能网设备转发交互信息的，其他的系统我也就不大清楚了——因为我已经不做这个行业了。
最近的OCS的情况，gainfirst应该比较清楚 10 楼 ubotutwin 2009-06-22 你还是没有搞清楚问题的重点在哪啊。用你的例子
1、 你打进一个电话
2、 交换机告诉 OCS 系统（或者是通过智能网系统转发）通话的详细情况
3..............
其实关键就在1、2两步之间，“你打进一个电话”后，交换机是在你摘机后就“诉 OCS 系统”，还是等你挂机后再“诉 OCS 系统”。这才是问题的关键！
拿最普遍的cc08来说，9到14字节是摘机时间，15到20字节是挂机时间。那么既然话单里都有挂机时间这项，那么可以简单的推理出这条话单是在客户挂机后产生的，那么任何上层系统最早都得在客户挂机后才能得到这条话单的信息，这样的话何来“实时控制”？
所以说，ocs是建立在智能网交换机所提供的摘挂两单的功能上的，没有这一功能ocs根本无从谈起。所以ocs的核心其实是能对摘机事件及时响应的话单采集系统，这涉及到去重、长单合并、高密度采集等等方面。而真到了余额限制这一步的算法相对来讲是很简单的。 11 楼 tower 2009-06-22 “你打进一个电话”后，交换机是在你摘机后就“诉 OCS 系统”，还是等你挂机后再“诉 OCS 系统”。
——这个问题我应该说清楚了吧。挂机是在后面步骤啊。
在我曾经开发过的INGW——智能网网关——系统里面，你的电话一接通，前端就会把开始通话时间，主叫号码，发话地点等信息发过来。挂机后，前端再把结束时间发过来。两个消息组成一个完整的话单。
当时的前端是改造后的智能网系统。
在我们那个系统里面剃重并不是重点，长单和密集采集是对系统要求比较高的地方。同时，要在比较快的时间能响应前端，对于后台计费系统的处理速度也是一个考验。 12 楼 calatustela 2009-10-13 学习了。楼主讲得不错