1

I am using seagull as a diameter server. I am trying to simulate an IMS 3GPP Cx traffic scenario like this: >MAR, SAR,

Note-1: ">" indicates receive, "<" indicates send. Note-2: MAR and SAR have different Session-Ids.

For this, I have the scenario file structure like the following.

<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 responds to the MAR received with an MAA. But, when SAR is received, it throws an below error. I guess, it's because session-id doesn't match. 

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

Is there anyway out of this. I checked the correlation-id usage, but couldn't figure out how to use it in the above scenario. Any suggestions would be of great help.

Thanks

bilalmetla
  • 155
  • 12

3 Answers3

1

If I understand your question you are trying to send SAR without sending MAR first. Seagull can support commands only in the same order your scenario describes. It expects MAR as the first message.

If you to start with SAR build a new scenario.

Oded Itzhaky
  • 445
  • 5
  • 16
1

Actually I was finding how to implement multiple diameter requests and responses but seagull was sending me the above error with above multiple diameter requests and responses.

But later on I have found solution how to write multiple diameter requests and responses. Just put each request and response in a separate <default> ... </default> section under scenario.xml file.

Like.. 

<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>
Mr Lister
  • 45,515
  • 15
  • 108
  • 150
bilalmetla
  • 155
  • 12
1

I am not familiar with packets you specifically used in question, but in general, I think seagull works in this way, and there are 3 reasons that cause a message rejected (marked as Unexpected message received in seagull).

  1. the rejected message is defined after another message which was not received (for receive section) or timeout (usually for send section) first. For example in your case, if seagull works as a server and it does not receive a MAR first (if you also define init section the one in init must be first satisfied), then an arriving SAR would cause this error.
  2. the rejected message has a Session-Id that is not acceptable. If you didn't define out-of-session-id field for this message, seagull would expect it has a same Session-Id as that in other messages. This is because seagull treats every message transition in a scenario traffic section as a same session. Meaning that SAR must have a Session-Id that is in the former MAR. core doc:

When receiving a message, Seagull tries to find the session-id in the list of its known session-ids. If the parameter corresponding to the session-id (as indicated in the dictionary) is not found, then Seagull will look at parameters indicated by "out-of-session-id" parameters in the dictionary.

In your case, the following procedure should work:

packets

  1. command section in dictionary should be identical to that in packets. flags, command code, application id, etc.

At last, using default section indeed would make the error seem to be solved , but I would not recommend, as default is supposed to be solutions for unrecognized received packets which in your case an out-of-session-id field is more appropriate and matching your system logic.

Tiina
  • 4,285
  • 7
  • 44
  • 73