1

I am working in seagull diameter, This is my scenarios for seagull server and seagull client

Client Server

   ---- CER ----> 
   <--- CEA ----
   ---- AAR ---->
   <--- AAA ----
   ---- STR  --->
   <--- STA  ----

But the Result: enter image description here So that it's not follow my scenario, please help me how to config something in to both server and client could synchronize?

Here is Client Scenario

<?xml version="1.0"?><scenario>

<init>

<send channel="channel-1">
<command name="CER">
</command>
</send>

<receive channel="channel-1">
<command name="CEA"> </command>
</receive>
</init>

<traffic>

<send channel="channel-1">
<command name="AAR">
<avp name="Session-Id" value="trandeptrai"> </avp>
</command>
</send>

<receive channel="channel-1">
<command name="AAA"> </command>
</receive> 

<send channel="channel-1">
<command name="STR">
<avp name="Session-Id" value="trandeptrai"> </avp>
</command>
</send>

<receive channel="channel-1">
<command name="STA"> </command>
<action>
<store name="Session-Id" entity="Session-Id"> </store>
</action>
</receive> 

</traffic>
</scenario>

Client config:

<?xml version="1.0"?>
<configuration name="jpT DIAMETER client">
<define entity="transport" name="trans-ip-v4" file="libtrans_ip.so" create_function="create_cipio_instance" delete_function="delete_cipio_instance" init-args="type=tcp"> </define>
<define entity="channel" name="channel-1" protocol="diameter-v1"  transport="trans-ip-v4" open-args="mode=client;dest=134.138.249.41:12340"> </define>
<define entity="traffic-param" name="call-timeout-ms" value="10000"> </define>
<define entity="traffic-param" name="files-no-timestamp" value="true"> </define>
<define entity="traffic-param" name="call-rate" value="1"> </define>

</configuration>

Server Scenario:

<?xml version="1.0"?><scenario>
<init>
<receive channel="channel-1">
<action>
 </action>
<command name="CER">
</command>
</receive>

<send channel="channel-1">
<command name="CEA"> </command>
<action>
 </action>
</send>
</init>
<traffic>

<receive channel="channel-1">
<command name="AAR"> </command>
<action>

<store name="Session-Id" entity="Session-Id"> </store>
</action>
</receive>

<send channel="channel-1">
<action>
<restore name="Session-Id" entity="Session-Id"> </restore>
</action>
<command name="AAA">
<avp name="Session-Id" value="1"> </avp>
</command>
</send>

<receive channel="channel-1">
<command name="STR"> </command>
<action>
<store name="Session-Id2" entity="Session-Id"> </store>
</action>
</receive>

<send channel="channel-1">
<action>
<restore name="Session-Id2" entity="Session-Id"> </restore>
</action>
<command name="STA">
<avp name="Session-Id" value="1"> </avp>
</command>
</send>

<!-- <wait-ms value="100"> </wait-ms> -->

</traffic>

</scenario>

Server config:

<?xml version="1.0"?>
<configuration name="jpT DIAMETER client">
<define entity="transport" name="trans-ip-v4" file="libtrans_ip.so" create_function="create_cipio_instance" delete_function="delete_cipio_instance" init-args="type=tcp"> </define>
<define entity="channel" name="channel-1" protocol="diameter-v1"  transport="trans-ip-v4" open-args="mode=client;dest=134.138.249.41:12340"> </define>
<define entity="traffic-param" name="call-timeout-ms" value="10000"> </define>
<define entity="traffic-param" name="files-no-timestamp" value="true"> </define>
<define entity="traffic-param" name="call-rate" value="1"> </define>

</configuration>
Kevin
  • 37
  • 1
  • 6

2 Answers2

2

Both E2E and H2H must be unique to a host that sends request (answer contains the same E2E and H2H). Taking this official guide for example (you may find it in scenario/sar-saa.client.xml):

<traffic>
  <send channel="channel-1">
    <action>
      <!-- For each new call, increment the session-ID counter -->
      <inc-counter name="HbH-counter"> </inc-counter>
      <inc-counter name="EtE-counter"> </inc-counter>
      <inc-counter name="session-counter"> </inc-counter>
      <set-value name="HbH-id" 
                 format="$(HbH-counter)"></set-value>
      <set-value name="EtE-id" 
                 format="$(EtE-counter)"></set-value>
      <set-value name="Session-Id" 
                 format=".;1096298391;$(session-counter)"></set-value>
    </action>
    <command name="SAR">
      <avp name="Session-Id" value="value_is_replaced"> </avp>
      <avp name="Vendor-Specific-Application-Id">
        <avp name="Vendor-Id" value="11"></avp>
        <avp name="Auth-Application-Id" value="167772151"></avp>
        <avp name="Acct-Application-Id" value="0"></avp>
      </avp>
      <avp name="Auth-Session-State" value="1"> </avp>
      <avp name="Origin-Host" value="seagull"> </avp>
      <avp name="Origin-Realm" value="ims.hpintelco.org"> </avp>
      <avp name="Destination-Realm" value="ims.hpintelco.org"> </avp>
      <avp name="Server-Name" value="seagull"> </avp>
      <avp name="Server-Assignment-Type" value="3"> </avp>
      <avp name="User-Data-Request-Type" value="0"> </avp>
      <avp name="Public-Identity" value="sip:olivierj@ims.hpintelco.org"> </avp>
      <avp name="Destination-Host" value="hss.ims.hpintelco.org"> </avp>
    </command>
    <action>
      <start-timer></start-timer>
    </action>
  </send>
  
  <receive channel="channel-1">
    <action>
      <stop-timer></stop-timer>
    </action>
    <command name="SAA">
    </command>
  </receive>
</traffic>

There are two actions before and after command which would be run before and after send SAR. Now you are having these terms the same, which would cause 'corruption' and hard to read/identify from package capture, and I believe this is the reason their sequence is disordered. And this is my experience to use SEAGULL:

  1. One can always look up seagull log, whose path is defined in server/client's description file in conf folder, for what might go wrong.

  2. whatever command is defined in <init> will only run once. It means that for receive, the second time a packets is received would cause unrecognized xxx in log. For example in the example, if a second CER is received, log says received unrecognized CER. If this happens, I usually reboot ksh or put receive CER in traffic.

  3. scenario is run with a sequence. For example, if a scenario defines in sequence receive CER send CEA receive DWR send DWA, a DWR without a proceeding CER would cause received unrecognized DWR. And this would be the most often case, when one looks for reason why a DWA is not received from seagul server.

    BTW, it deserves to mention that unless a send or receive is defined in init, otherwise it continues to "ping-pong".`

Community
  • 1
  • 1
Tiina
  • 4,285
  • 7
  • 44
  • 73
1

You could try setting the simultaneous calls to 1, that way your client will wait until the current call is over to start another one. Add this line to your server and client configuration:

<define entity="traffic-param" name="max-simultaneous-calls" value="1"></define>

The default value for this property is 100, so surely that's why your capture shows mismatched requests and answers.

delephin
  • 1,085
  • 1
  • 8
  • 10
  • Thanks delephin, but i think that it's seem not match with my question, we have 3 mated pairs commands – Kevin Jun 14 '17 at 07:42
  • You're right. I should have re-read the question before answering. Let me get back to you later. – delephin Jun 14 '17 at 14:24
  • thank so much for you efforts, Delephin, the process run orderly, but do you know how can the flow reaches to STR <---> STA? – Kevin Jun 20 '17 at 02:48
  • Can you explain further? – delephin Jun 22 '17 at 18:37
  • For example the order is: Client Server ---- CER ----> <--- CEA ---- ---- AAR ----> <--- AAA ---- ---- STR ---> <--- STA ---- – Kevin Jul 01 '17 at 03:59
  • Your flow is not exchanging SessionTermination avps? You can always edit the question to add more info, the comment box is quite restrictive. – delephin Jul 03 '17 at 16:28