发送submit_sm请求时，Restcomm SMSC持续引发ActivityAlreadyExistsException

Question

我使用的是Restcomm SMSC的最新版本(SMSCGATEWAY-7.3.153)（可在以下站点获得：https://github.com/Restcomm/sMSCGATEWAY/releases/tag/7.3.153)。我使用的是二进制版本，而不是源代码。

我已经启动并运行了它与卡珊德拉通信，卡珊德拉适当地托管在不同的机器上。

我正在附加一个。pcap文件，它显示了我通过Wireshark捕获的数据包。所有的请求和响应数据包都将在那里。我也会附上服务器日志。

我在互联网上找不到任何关于这个的帮助，所以如果你们中的任何人能在这里指导我，我将非常感激。请标记开发人员，如果你知道他们。请随时询问更多信息。

Wireshark捕获文件

下面是一个例外：

11:26:53,196信息[SmppServerConnector]（SmppManagement）新通道来自[192.168.1.173:34034]11:26:53,215信息[UnboundSmppSession]（SmppManagement.unboundsession.192.168.1.173:34034)接收PDU:(Bind_Transceiver:0x000000250x000000090x0000000000)（正文:systemId[test5]密码[test5]systemType[]interfaceVersion[0x34]地址范围(0x01](SmppManagement.unboundsession.192.168.1.173:34034)创建的会话:name=test5 systemId=test5 11:26:55,504错误[SmppSessionHandlerInterfaceImpl](test5)处理PDURequest=(submit_sm:0x0000002f 0x00000004 0x00000000000x0000002)时出错（正文:(serviceType[]sourceAddr[0x01 0x01[6666]]destAddr[0x01 0x01 f21])(opts:)javax.slee.resource.activityalreadyexistsexception:ra:smppserverra:smpptransactionhandle[smppsessionconfigurationname=test5,smpptransactiontype=incommary,seqNumnber=2]在org.mobicents.slee.runtime.activityContextFactoryImpl.createActivityContext（ActivityContextFactoryImpl.java:157)在org.mobicents.slee.runtime.activity.createActivityContextFactoryImpl.java:57)在org.mobicents.slee.resource.sleeEndPointPl._startActivity(SleeEndPointPl.java:312)在63）在org.mobicents.slee.resource.sleeendpointimpl.startactivity(Sleeendpointimpl.java:176)在org.restcomm.slee.resource.smpp.smppserverresourceadaptor.startNewsMppServerTransactivity(SmppServerresourceadaptor.java:277)在org.restcom.slee.resource.smpp.smpsessionSimpl$smppsessionHandlerimpl.firepduRequestReceived el.smppSessionWrapper.MessageReceed（SmppSEssionWrapper.java:52)在org.jboss.netty.channel.simpleChannelHandler.handleUprist(SimpleChannelHandler.java:88)在org.jboss.netty.channel.defaultChannelPipeline.sendupstream(DefaultChannelPipeline.java:564)在org.jboss.netty.channel.defaultChannelPipeline.java:564)在在org.jboss.netty.handler.codec.frame.frameDecoder.calldecode（frameDecoder.java:443)，在org.jboss.netty.handler.codec.frameDecoder.messageReceed（frameDecoder.java:303)，在org.jboss.netty.channel.simpleChanneLupStreamHandler.java:70，在org.jboss.netty.channel.defaultChannelPipeline.sendupStream（AultChannelPipeline$DefaultChannelHandlerContext.SendupStreamnnelPipeline.java:791)在com.cloudhopper.smpp.channel.smpsessionLogger.handleUpper(smppsessionLogger.java:104)在org.jboss.netty.channel.defaultChannelPipeline.sendupstream(DefaultChannelPipeline.java:564)在org.jboss.netty.channel.defaultChannelPipeline.java:564)在s.netty.channel.defaultChannelPipeline.SendupStream(DefaultChannelPipeline.java:564)在org.jboss.netty.channel.defaultChannelPipeline.defaultChannelPipeline$DefaultChannelHandlerContext.SendupStream(DefaultChannelPipeline.java:791)在org.jboss.netty.channel.SimpleChannelPipeline.messageReceed(SimpleChannelUpstream.java:124)在位于org.jboss.netty.c的SendupStream(DefaultChannelPipeline.java:564)hannel.defaultchannelpipeline.sendupstream（defaultchannelpipeline.java:559)在org.jboss.netty.channel.channels.firemessageReceed（channels.java:268)在org.jboss.netty.channel.channels.firemessageReceed（channels.java:255)在org.jboss.netty.channel.firemessageReceed（channels.java:255)在nioselector.run(abstractnioselector.java:318)在org.jboss.netty.channel.socket.nio.abstractnioworker.run(abstractnioworker.java:89)在org.jboss.netty.channel.socket.nio.nioworker.run(nioworker.java:178)在org.jboss.netty.nocket.nio.nioworker.run(nioworker.java:178)tor.runworker（未知源）位于java.util.concurrent.ThreadPoolExecutor$worker.run（未知源）位于java.lang.thread.run（未知源）

Answer 1

我相信这是在这里回答的，对吗？