After https://gerrit.mgm.sipwise.com/c/templates/+/43662
we are getting:
> proxy[21449]: ERROR: <null> cfgt [cfgt_int.c:413]: cfgt_save_node(): failed to make directory: Permission denied
Change-Id: I88781316d416595cdcac06e363ffa93703f79684
The names of the NCOS levels assigned in the scenarios_lnp:
* invite_ncos_black
* invite_ncos_white
were too long (more than the 30 allowed chars) preventing the
correct provisining of the scenarios.
Change-Id: Iec5ad8b7a8d051a56c6ab91a53877fd0587c5d60
It's been noticed that during nightly Jenkins runs,
scenarios LNP keep on failing because of: 'invite_ncos_black' and
'invite_ncos_white' scenarios.
Jenkins runs a mass configuration of the whole bunch of scenarios,
and then starts running them one by one.
The issue happens because of the same NCOS level names used by both
'invite_ncos_black' and 'invite_ncos_white' scenarios.
First Jenkins configures 'invite_ncos_black' and all needed NCOS
levels are added. Then Jenkins deletes and creates again the same
NCOS levels (which share the same names) for the 'invite_ncos_white'.
This leads to the fact, that NCOS levels exist,
but are not set for 'invite_ncos_black' in domain preferences.
Another problem is, that mass configuration of LNP scenarios
leads to the problem with lnp carrier id and lnp numbers during
the run, and Proxy component thinks that there are no entries
for certain scenarios or uses the wrong lnp entry. Same problem,
scenarios share the same name space for part of the objects.
This commit concerns change of the name space for NCOS levels.
Change-Id: I851e5a81384e46972996d93b7d03657fd1c6c63d
play_announce_before_recording is now a quad state and no more
a boolean, changing user preference to the correspondant value.
Change-Id: I3da961d428a2e1c6f10957ba53ce1bf3ba200d35
Fix scenario invite_force_outbound_calls_to_peer to work without
ROUTE_SET_CALLEE_DIALOG being executed.
Change-Id: I67579b590fc6d87766b10151a77c601b3f123eb2
no longer support of parsing of the kamailio log to produce flow info
* remove ulog_parser.pl, no longer used
* graph_flow.pl: remove -j option
* check.py: remove --yaml/--json options
* check.sh: remove SKIP_PARSE and JSON_KAM options
Change-Id: I0df00ffff3e7d8c2129cbbce12652ddff9730821
Lowered the rtpengine cancel delay from 2 to 1 second
Lowered the sleep time of the script check.sh from 5 to 2 seconds
Removed sleep time before check CDRs
This should speed up the test of basic scenarios of 4/5 minutes
Change-Id: I4f5fb539f7ab704f1aca6ddd2abf64db54b27ef1
Tests has to be updated if they have to be activated but they can
be useful to test some customer issue
* 181 reply tests (invite_181, invite_181_callforward)
* call forward with source definition (invite_callforward_sources)
* diversion validation tests (invite_diversion_*)
* 301 redirection tests (invite_redirect_error_*)
Change-Id: Ib6ddf6f50e5de238faa85c5ca1a8916a2821644d
We need to update a list of scenarios for k-c-t in the master repo, in order to let CE-trunk nightly runs (by Jenkins) be working again.
For now Jenkins marks CE-trunk build as failed, reason - not actual k-c-t scenarios.
Change-Id: I1a5152149b3bb066574655c74fff162a82ebc20b
Even if the video support is disabed by the callee, a codec has to be
provided in the reply. Addin coded 34 equel to the one received in the
initial INVITE.
The missing codec was causing SEMS to add an empty line after the
sdp m= line causing rtpengine to return:
error: Failed to parse SDP
Change-Id: I80227c9dd9a34a21b278d9b069d5af88eb504655
* cseq: use \d+ since sems can use random and CE/PRO are different
* support alias_numbers
* numbers on display names
Change-Id: I7f94718cd9363a20124baae51347763dbd3fb234
* Makefile: add missing test_generate_test rule
* remove yaml.dump and build directly the simple YAML
output ourselfs. It was generating strange indentation
even with indent=None with using [% %] for some cases
Change-Id: Iacf927cf21b5d127c625168a049d6a1bd9606fc3
* when reading yaml, that value became hex
* lint yaml using visual code plugin
* TODO: introduce pre-commit and create rule for avoid this
issue in the future
Change-Id: I866024ba51b6bbec7449275bb6ea56e2f7e6bb4d
> root@09127d41b4c6:/code# ./bin/check_sip.py
> Traceback (most recent call last):
> File "/code/./bin/check_sip.py", line 259, in <module>
> args = parser.parse_args()
> File "/usr/lib/python3.9/argparse.py", line 1830, in parse_args
> args, argv = self.parse_known_args(args, namespace)
> File "/usr/lib/python3.9/argparse.py", line 1863, in parse_known_args
> namespace, args = self._parse_known_args(args, namespace)
> File "/usr/lib/python3.9/argparse.py", line 2100, in _parse_known_args
> self.error(_('the following arguments are required: %s') %
> File "/usr/lib/python3.9/argparse.py", line 2585, in error
> self.print_usage(_sys.stderr)
> File "/usr/lib/python3.9/argparse.py", line 2555, in print_usage
> self._print_message(self.format_usage(), file)
> File "/usr/lib/python3.9/argparse.py", line 2521, in format_usage
> return formatter.format_help()
> File "/usr/lib/python3.9/argparse.py", line 295, in format_help
> help = self._root_section.format_help()
> File "/usr/lib/python3.9/argparse.py", line 226, in format_help
> item_help = join([func(*args) for func, args in self.items])
> File "/usr/lib/python3.9/argparse.py", line 226, in <listcomp>
> item_help = join([func(*args) for func, args in self.items])
> File "/usr/lib/python3.9/argparse.py", line 333, in _format_usage
> action_usage = format(optionals + positionals, groups)
> File "/usr/lib/python3.9/argparse.py", line 408, in _format_actions_usage
> start = actions.index(group._group_actions[0])
> IndexError: list index out of range
Change-Id: I8cc8d73a785fb164ff7b9568076eab10bd53f77d
* sipp_scenario00.xml => sipp_scenario00.msg
sipp_scenario_responder00.xml => sipp_scenario_responder00.msg
so sipp_scenario00_test.yml.tt2 and sipp_scenario_reponder00_test.yml.tt2
makes more sense
Change-Id: Iab9db5122774dbc32101195e639ab6fef9b23236
We are adding a new approach/tool used to check out SIP messages
received, and unlike the existing way of doing that (using what has come/gone in front of the Proxy),
the usage of sipp logs will be introduced.
The idea is that we are looking for received SIP messages at both
the originator(s) and recipient(s) side, and then using what we've gotten,
run checks based on _test.yml.tt2 templates prepared in advance for each scenario, example:
* sip_messages00_test.yml.tt2
* sip_messages_responder00_test.yml.tt2
- add missing options to help command
- bin/check.sh: use T option to select what to do with checks
- get_results.sh: remove deprecated -P -T options
Change-Id: I2d0084fa59694ffd009736205a092a35f6864669
Victor Seva
Marco Capetta
Alessio Garzi
Sipwise Jenkins Builder
Guillem Jover
Donat Zenichev