千家论坛_智能建筑与智能家居技术交流社区

标题: To Petermk 2000IPS LAN SMDR 用过吗？ [打印本页]

作者: pabxman 时间: 2009-6-3 14:23
标题: To Petermk 2000IPS LAN SMDR 用过吗？
rt

目前市场上有什么软件适用？

作者: petermk 时间: 2009-6-3 15:51

没有！这块小卡片实在太贵了！只有做VOIP才会有人用！但是SMDR on IP要到R10以后的版本才开始支持，目前做过的用VOIP的客户都是R8之前的版本！

而且大陆NEC新版本出的好像很迟。

个人觉得，计费软件应该不是什么问题。因为不管是串口还是IP，SMDR输出的数据格式只有2400IMS和1400IMS2种。只要用超级终端能收到正确的码就行，软件所谓的“支持”也就是格式对应而已。

[此贴子已经被作者于2009-6-3 15:51:58编辑过]

作者: pabxman 时间: 2009-6-3 16:13
好像 2000IPS LAN SMDR 对计费软件的匹配还是有问题，因为PBX 与外设（PC）之间的信息传输要握手，类似 PMS的传输。

作者: petermk 时间: 2009-6-3 16:47

手上只有R8版本的SMDR/MCI/PMS接口手册，不知道详细信息！

如果真的需要握手的话我估计，大陆目前应该不会有软件能支持，虽然只要知道格式，对软件厂商来说修改很容易！

作者: petermk 时间: 2009-6-3 17:20

汗！刚才找了下资料，确实是要握手的！不过在R14版的手册中也只是给出了流程并没有握手的数据！[attach]39543[/attach]

我之前有接触过一款台湾的PBX也是需要握手的，用梓博的计费软件！他们可以改软件的，关键是握手的数据！

作者: pabxman 时间: 2009-6-4 09:54
收到的记录：

<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 33
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 33
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 33
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 33
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 33
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 32 30 30 31 33 35 30 30 31
0!KA000000001300...04081121420408112156..........001000000000200.............................0000..................09090..........
<- : 16 34 30 30 30 30 34 30 30 31 6 0
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 32 30 30 31 33 35 30 30 32
0!KA000000001300...04081126460408112658..........00100000000013912345678.....................0000..................09090..........
<- : 16 34 30 30 30 30 34 30 30 32 6 0
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 32 30 30 31 33 35 30 30 33
0!KA000000001300...04081129260408112938..........00100000000061234567........................0000..................09090..........
<- : 16 34 30 30 30 30 34 30 30 33 6 0
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 31 30 30 30 30 32 30 30 0
->: 16 33 30 30 30 30 33 30 30 31
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
->: 16 33 30 30 30 30 33 30 30 32
<- : 16 36 30 30 30 30 33 30 30 6 0

作者: petermk 时间: 2009-6-4 11:57

除SMDR数据段以外的，应该是16进制的ASIIC码吧！

昨天晚上又研究了下手册后半部分的PMS on IP，对握手的数据做了一些说明。再对照版主的实际数据，上图中的握手数据应该就是PC>1xxxxx, PBX>2xxxx1xxxx、DATA, PC>4xxxx1xxxx,......。这个可以从SMDR数据段前后的数据能看出来！问题是相对串口的PMS握手，后面的内容好像有点复杂，并且有一点点对应不上。

一大疑问就是PC>PBX的数据，版主怎么送出去的？还是已经有软件可以用，版主抓的数据？

[此贴子已经被作者于2009-6-4 11:59:16编辑过]

作者: pabxman 时间: 2009-6-4 13:02
这是 ascii 码转换来的 HEX 码，为了查看方便。

这是用测试软件抓下来的，我用 Procomm 也试过，将握手定义做在键上发送，效果也一样

作者: petermk 时间: 2009-6-4 13:29

奥！你是说有SMDR的测试软件？我说怎么知道正确的请求数据格式。

刚才又整理、简化了一下，应该看的清楚点，不过还是有疑问，不完全吻合。

另外我觉得应该可以不用做的如此全面，仅仅发送请求SMDR数据的握手数据，根据返回的数据来判断是否为有效的SMDR信息。

这一段应该是状态监视的数据，手册给出的格式是：
<- : 5（identifier）00（client device information）
->: 3（identifier）2（response No.)
------------------------------------
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
SYN 5000050000 ACK NUL
->: 16 33 30 30 30 30 33 30 30 33
SYN 300003003
......

这一段应该是正常的数据请求和发送数据，
<- : 16 31 30 30 30 30 32 30 30 0
SYN 10000200 NUL
->: 16 32 30 30 31 33 35 30 30 31
SYN 200135001
0!KA000000001300...04081121420408112156..........001000000000200.............................0000..................09090..........
<- : 16 34 30 30 30 30 34 30 30 31 6 0
SYN 400004001 ACK NUL

这一段应该是奇偶错误（Partity Error -Server Side）
<- : 1（text identifier）
->: 3（text identifier）3（sequence NO.)
------------------------------------
<- : 16 31 30 30 30 30 32 30 30 0
SYN 10000200 NUL
->: 16 33 30 30 30 30 33 30 30 31
SYN 300003001
......

这一段应该是正常的数据请求和发送数据
<- : 16 31 30 30 30 30 32 30 30 0
SYN 10000200 NUL
->: 16 32 30 30 31 33 35 30 30 32
0!KA000000001300...04081126460408112658..........00100000000013912345678.....................0000..................09090..........
<- : 16 34 30 30 30 30 34 30 30 32 6 0
SYN 400004002 ACK NUL
<- : 16 31 30 30 30 30 32 30 30 0
SYN 10000200 NUL
->: 16 33 30 30 30 30 33 30 30 31
SYN 300003001
......
->: 16 32 30 30 31 33 35 30 30 33
0!KA000000001300...04081129260408112938..........00100000000061234567........................0000..................09090..........
<- : 16 34 30 30 30 30 34 30 30 33 6 0
SYN 400004003 ACK NUL
<- : 16 31 30 30 30 30 32 30 30 0
SYN 10000200 NUL
->: 16 33 30 30 30 30 33 30 30 31
SYN 300003001
......
<- : 16 35 30 30 30 30 35 30 30 30 30 6 0
SYN 5000050000 ACK NUL
->: 16 33 30 30 30 30 33 30 30 32
SYN 300003002
......

这个手册上没有，是不是关闭连接的信息？
<- : 16 36 30 30 30 30 33 30 30 6 0
SYN 60000300 ACK NUL

作者: pabxman 时间: 2009-6-4 13:40
你分析的对，最后的那个是 disconncet

作者: petermk 时间: 2009-6-4 13:51

关键是版主能否测试一下，如果只送这个：

<- : 16 31 30 30 30 30 32 30 30 0

PBX能否正常给出SMDR数据：

->: 16 32 30 30 31 33 35 30 30 31 + SMDR数据

然后再送以下数据清除PBX的缓存

<- : 16 34 30 30 30 30 34 30 30 31 6 0

如果可以计费软件改动实现的可能性应该就比较大了！

作者: pabxman 时间: 2009-6-4 13:55
这样我找找写的Procomm 脚本，这脚本没测试

作者: petermk 时间: 2009-6-4 13:56

奥！有点小问题。

->: 16 32 30 30 31 33 35 30 30 31 + SMDR数据

<- : 16 34 30 30 30 30 34 30 30 31 6 0
在一次连接中，红字部分应该是要递增的，并且回应的时候要对应。那么是不是麻烦一点，每请求一次数据之后成功之后，就要关闭连接再重新请求。

作者: pabxman 时间: 2009-6-4 13:58
PROCOMM PLUS Aspect
; CONSTANTS
#define Identifier1 "^V10000200^@"            ; PC to PBX SMDR记录请求
#define Identifier2 "^V20013500X-132smdrrec-" ; PBX to PC SMDR记录发送
#define Identifier31 "^V300003001"             ; PBX to PC 无SMDR记录
#define Identifier32 "^V300003002"             ; PBX to PC 监视状态
#define Identifier33 "^V300003003"             ; PBX to PC 校验错
#define Identifier35 "^V300003005"             ; PBX to PC 收到信息非法
#define Identifier4 "^V40000400X^F^@"         ; PC to PBX 收到SMDR记录确认
#define Identifier5 "^V5000050000^F^@"        ; PC to PBX 监视保持
#define Identifier6 "^V60000300^F^@"          ; PC to PBX 断开连接
#define ACK          "^F^@"

; GLOBAL VARIABLES
string szSmdrRecNo                            ; 0-9

作者: pabxman 时间: 2009-6-4 14:01
其中 X =szSmdrRecNo

作者: petermk 时间: 2009-6-4 14:04
晕死！这个比手册清楚、全面的多！

作者: petermk 时间: 2009-6-4 14:08

以下是引用pabxman在2009-6-4 14:01:00的发言：
其中 X =szSmdrRecNo

也就是1次只能请求10条记录？

作者: pabxman 时间: 2009-6-4 14:48
循环的

作者: pabxman 时间: 2009-6-4 15:38
难就难在 X =szSmdrRecNo PC 确认要对应，否则下次请求还是这条数据，PBX没有删除这条已送出的数据。

所以 X 是变量，这个变量要从 Identifier2 取出，在 Identifier4 返回。

欢迎光临千家论坛_智能建筑与智能家居技术交流社区 (http://bbs.qianjia.com/)