Kamailio configuration tests
----------------------------

Requeriments:
-------------
 - A working NGCP
 - sip-tester. sipp with ssl enabled ( needed for auth ).
   We provide a version backported to wheezy
 See debian/control for the actual list of dependences

Usage:
------
  # cd /usr/share/kamailio-config-tests

  We support groups of scenarios. Each group can have different configs, see
  $BASE_DIR/$GROUP/config.yml. The default GROUP is 'scenarios'. Set GROUP to
  scenarios_XXX in order to run/test that group.

  If you are using the git version and not in /usr/share/kamailio-config-tests
  you need to set BASE_DIR environment variable accordingly:
  # export BASE_DIR=`pwd`
  This is not needed if you are using the Debian packaged version.

  PROFILE: "CE" the default
           "PRO"
  #bash ./run_tests.sh [-p PROFILE ] [-K]

  This will create:
    - $BASE_DIR/log
      with a directory per test with:
      - kamailio.log
      - kamailio-lb.log
      - sems.log
      - parsed messages (XXXX.json)
      - sipp error logs
      - a pcap file for each interface

  #bash ./get_result.sh [-p PROFILE ] [-g]

  This will create:
    - $BASE_DIR/result
      with a directory per test with:
      - a tap file ( test results )
      - a png file ( routes flow ) If you use -g option

 If you want to run test manually just exec this onces:
  #./bin/config_debug.pl on
  #ngcpcfg apply 'cfgtest'
 and run the check that you want:
  #PERL5LIB="$$(pwd)/lib" ./bin/check.sh <checkname>
 this will run the test and the result taps
 or run all the tests as many times you want with:
  #./bin/bench.sh $NUM

If you want to test just a set of scenarios, set the SCENARIOS
environment var.

#bash SCENARIOS="invite invite_callforward" ./run_tests.sh -c
#bash SCENARIOS="invite invite_callforward" ./get_results.sh

Development:
------------

Every test has to be located at the scenarios directory. It must include:

 - scenario.yml
 - XXXX_test.yml.tt2
   XXXX indicates the number of kamailio parsed msg XXXX.json to test
 - sipp_scenarioXX.xml

And can optionally include:
 - sipp_scenario_responderXX.xml
 - prefs.json
 - callforward.yml
 - speeddial.yml
 - peer.yml

Test file syntax:
-----------------

The test file is divided in tree different parts:
 - flow:
  Array of routes with a possible list of pseudo-variables values to test.
  If the value is a string it will be treated as a regular expression rule[0].

  Example:
  flow:
    - start|MAIN:
        $avp(val): [1, "test"]
    - start|ROUTE_NET_INFO:
        $avp(val): [2,1]
    - end|ROUTE_NET_INFO:
        $avp(val): None
    - start|ROUTE_PRX_REQUEST:
        $xavp(caller_peer_prefs[0]=>concurrent_max): '\d+'
    - start|ROUTE_INVITE:
        $xavp(caller_peer_prefs[0]=>concurrent_max[*]): [1]
    - start|ROUTE_LOAD_CALLEE_DOMAIN_PREF:
    - start|ROUTE_CLEAR_CALLEE_DOMAIN_PREF:
    - end|ROUTE_CLEAR_CALLEE_DOMAIN_PREF:
    - end|ROUTE_LOAD_CALLEE_DOMAIN_PREF:
    - start|ROUTE_FIND_CALLER:
    - start|ROUTE_AUTH:
    - exit|ROUTE_AUTH:
        $fU: testuser

 - sip_in:
  Array of regular expresion rules[0] to match in the sip messsage. If the rule
  starts with '_:NOT:_' it will fail if the rule matches.

  Example:
  sip_in:
    - '^INVITE'
    - 'Contact: sip:testuser1002@'
    - 'CSeq: 2 INVITE'
    - 'Max-Forwards: 16'
    - 'Content-Type: application/sdp'
    - 'Proxy-Authorization: Digest username="testuser1002"'
    - '_:NOT:_Contact: <sip:testuser1003@127.126.0.1:6666;ob>;expires=\d+',

 - sip_out:
  Array of lists of regular expression rules[0] to match the array of sip messages
  send out. If the rule starts with '_:NOT:_' it will fail if the rule matches.

  Example:
  sip_out:
  - [
      '^SIP/2.0 100 Trying',
      'Content-Length: 0'
    ]
  - [
      '^SIP/2.0 403 Unauthorized IP detected',
      'Content-Length: 0',
      'P-NGCP-Authorization: testuser1003@',
      'P-NGCP-Authorized: 1'
    ]

 [0] http://docs.python.org/2/library/re.html#regular-expression-syntax

scenario.yml file syntax:
-------------------------

  This file is divided in two sections: subscribers and scenarios. In subscribers
  we put the info and alias numbers. In scenarios we put the info needed to run the
  sipp scenarios.

  The check.sh script will start all the responders in the background in order and then
  any sipp_scenarioXX.xml one by one.

  If the responder has register: yes a sipp_scenario_responderXX_reg.xml will be created
  and run it before the correspondent responder.

  If active: no then no sipp_scenario_responderXX.xml exists for that responder. It's just
  info of the callee.

  If foreign: yes then sipp_scenario_responderXX.xml will be run with 5060 port.

  If password_wrong: yes then the caller is going to use 'wrongpass' as password.

  Example:

  test_uuid: lock_ported
  domains:
    'spce.test':
      reseller_id: 1
  customers:
    'customer.test':
      contacts:
        - email: "customer.test@spce.test"
          reseller_id: 1
      details:
        status: 'active'
        type: 'sipaccount'
        billing_profile_id: 1
        reseller_id: 1
  subscribers:
    spce.test:
      testuser1003:
        customer: 'customer.test'
        password: testuser
        cc: 43
        ac: 1
        sn: 1003
      testuser1002:
        customer: 'customer.test'
        password: testuser
        cc: 43
        ac: 1
        sn: 1002
      testuser1001:
        customer: 'customer.test'
        password: testuser
        cc: 43
        ac: 1
        sn: 1001
      testuser1004:
        customer: 'customer.test'
        password: testuser
        cc: 43
        ac: 1
        sn: 1004
  scenarios:
    - ip: 127.126.0.1                    --> sipp_scenario00.xml
      username: testuser1002
      domain: spce.test
      proto: tcp
      responders:
        - ip: 127.1.0.1                  --> sipp_scenario_responder00.xml
          username: testuser1003
          domain: spce.test
          register: yes
          proto: udp
    - ip: 127.1.0.1                      --> sipp_scenario01.xml
      username: testuser1003
      domain: spce.test
      proto: udp
      password_wrong: yes
      responders:
        - ip: 127.126.0.1                --> sipp_scenario_responder01.xml
          username: testuser1002
          domain: spce.test
          register: yes
          proto: tcp
        - ip: 127.0.2.1                  --> sipp_scenario_responder02.xml
          number: 004321001
          username: 004321001
          domain: spce.test
          peer_host: peer_00_host0
          register: no

peer.yml file syntax:
---------------------

Peer group definition:

peer_00:
  contact:
    company: peer_00
    email: peer_00@host0.not
  contract:
    billing_profile_id: 1
    status: active
    type: sippeering
  groups:
    - name: peer_00_group
      priority: 1
      description:
  rules:
    - group_id: peer_00_group
      callee_prefix: ""
      callee_pattern: ''
      caller_pattern: '^sip:.+@spce.test'
      description: ""
  inboundrules:
    - group_id: peer_00_group
      field: "ruri_uri"
      pattern: '.*'
      priority: 50
      enabled: 1
  hosts:
    - group_id: peer_00_group
      name: peer_00_host0
      ip: 127.0.2.1
      port: 50602
      host:
      transport: 1
      weight: 1

prefs.json file syntax:
----------------------

{
    "@spce.test": {                            --> domain prefs
        "allow_out_foreign_domain": true
    },
    "testuser1002@spce.test": {                --> subscriber prefs
        "allowed_clis": [
            "43110029*",
            "43110021*"
        ],
        "user_cli": 43122122,
        "inbound_upn": "from_display",
        "extension_in_npn": true
    },
    "peer_00_host0": {                         --> peer prefs
        "rewrite_rule_set": "rw_00",
        "concurrent_max": 1
    }
}

 Preferences must match REST definition [1]

 [1] https://localhost:1443/api/
--
Victor Seva <vseva@sipwise.com>