Seagull Error Unexpected (no scenario found) call with session-id答案

【问题标题】：Seagull Error Unexpected (no scenario found) call with session-idSeagull Error Unexpected (no scenario found) call with session-id
【发布时间】：2015-10-09 12:45:25
【问题描述】：

我使用 seagull 作为直径服务器。我正在尝试模拟这样的 IMS 3GPP Cx 流量场景：>MAR, SAR,

注1：“>”表示接收，“

为此，我有如下的场景文件结构。

<traffic>
<receive channel="channel-1">
<command name="MAR">
....
</receive>
<send channel="channel-1">
<command name="MAA">
....
</send>

<receive channel="channel-1">
<command name="SAR">
....
</receive>
<send channel="channel-1">
<command name="SAA">
....
</send>
</traffic>

Seagull 使用 MAA 响应收到的 MAR。但是，当接收到 SAR 时，它会引发以下错误。我猜，这是因为 session-id 不匹配。

2009-04-07.13:57:33.001|E|Unexpexted message that doesn't match the    scenario.
2009-04-07.13:57:33.001|T|Unexpected (no scenario found) call with session-id [ 30 30 30 31 2d 61 61 61 6d 67 72 2e 73 74 31 36 2e 73 74 61 72 65 6e 74 6e 65 74 77 6f 72 6b 73 2e 63 6f 6d 3b 32 30 30 30 33 3b 31 33 35 38 38 34 30 38 33 33 3b 66 64 65 38 30 31 ] 2009-04-07.13:57:33.001|T|Unexpected message received [ [SAR

反正还有这个。我检查了相关 ID 的使用情况，但无法弄清楚如何在上述场景中使用它。任何建议都会有很大帮助。

谢谢

【问题讨论】：

标签： diameter-protocol

【解决方案1】：

如果我理解您的问题，您正在尝试发送 SAR 而不先发送 MAR。 Seagull 只能以您的场景描述的相同顺序支持命令。它期望 MAR 作为第一条消息。

如果你从 SAR 开始构建一个新场景。

【讨论】：

我随机发送 SAR 和 MAR

【解决方案2】：

实际上，我正在寻找如何实现多个直径的请求和响应，但 seagull 向我发送了上述多个直径请求和响应的错误。

但后来我找到了如何编写多个直径请求和响应的解决方案。只需将每个请求和响应放在单独的 <default> ... </default> 部分中即可。

喜欢..

<default>

    <receive channel="channel-1" >
        <command name="AAR">
        </command>
        <action>
            <store name="HbH" entity="HbH-id"></store>
            <store name="E2E" entity="EtE-id"></store>
            <store name="sid" entity="Session-Id"></store>
        </action>
    </receive>
    <send channel="channel-1" >
        <action>
            <restore name="HbH" entity="HbH-id"></restore>
            <restore name="E2E" entity="EtE-id"></restore>
            <restore name="sid" entity="Session-Id"></restore>
        </action>
        <command name="AAA">
            <avp name="Session-Id" value="$(sid)" type="string"></avp>
            <avp name="Result-Code" value="2001" type="number"></avp>
            <avp name="Reply-Message" value="Success" type="string"></avp>

        </command>
    </send>
</default>

<default>

    <receive channel="channel-1" >
        <command name="PUR">
        </command>
        <action>
            <store name="HbH" entity="HbH-id"></store>
            <store name="E2E" entity="EtE-id"></store>
            <store name="sid" entity="Session-Id"></store>
        </action>
    </receive>
    <send channel="channel-1" >
        <action>
            <restore name="HbH" entity="HbH-id"></restore>
            <restore name="E2E" entity="EtE-id"></restore>
            <restore name="sid" entity="Session-Id"></restore>
        </action>
        <command name="PUA">
            <avp name="Session-Id" value="$(sid)" type="string"></avp>
            <avp name="Result-Code" value="2001" type="number"></avp>
            <avp name="Reply-Message" value="Success" type="string"></avp>

        </command>
    </send>
</default>

【讨论】：

【解决方案3】：

我不熟悉您具体使用的数据包，但总的来说，我认为 seagull 是这样工作的，导致消息被拒绝的原因有 3 个（标记为 Unexpected message received在海鸥）。

被拒绝的消息是在另一条未收到（对于接收部分）或超时（通常对于发送部分）的消息之后定义的。例如，在您的情况下，如果 seagull 作为服务器工作并且它没有首先收到MAR（如果您还定义了 init 部分，则 init 中的部分必须首先满足），那么到达的 SAR 将导致此错误。李>
被拒绝的邮件有一个不可接受的Session-Id。如果您没有为此消息定义out-of-session-id 字段，seagull 会期望它具有与其他消息中相同的Session-Id。这是因为 seagull 将场景流量部分中的每个消息转换都视为同一个会话。这意味着 SAR 必须具有在前 MAR 中的 Session-Id。 core doc:

收到消息时，Seagull 会尝试在其已知会话 ID 的列表。如果参数对应 session-id（如字典中所示）未找到，然后 Seagull 将查看由“out-of-session-id”指示的参数字典中的参数。

在您的情况下，以下过程应该有效：

字典中的命令部分应与数据包中的相同。标志、命令代码、应用程序 ID 等。

最后，使用默认部分确实会使错误似乎得到解决，但我不建议，因为默认应该是unrecognized received packets 的解决方案，在你的情况下是@987654329 @ 字段更合适并匹配您的系统逻辑。

【讨论】：