Skip to content
Success

Changes

Summary

  1. ttcn3-asterisk: Configure asterisk for initial SIP register on IMS side (details)
  2. ttcn3-docker-run.sh: Fix dumpcap failing to access /data inside docker (details)
Commit f9c8ed8de78b7f6641c9802be2d0cdd2488295fb by Pau Espin Pedrol
ttcn3-asterisk: Configure asterisk for initial SIP register on IMS side

This set of pjsip config requires work done by jolly in our fork of
asterisk adding IMS features.

Depends: osmo-ttcn3-hacks.git Change-Id Idb3b19ccd82cad25948106b2c72aa424d7f79cd8
Change-Id: I66d128192146ad600203ea2a41b8bf019311d603
The file was modifiedttcn3-asterisk-ims-ue-test/asterisk/pjsip.conf
The file was modifiedttcn3-asterisk-ims-ue-test/Asterisk_Tests.cfg
Commit 2b9c8e3db8cf77c5ce5c3f888365f983f3ee8d76 by Pau Espin Pedrol
ttcn3-docker-run.sh: Fix dumpcap failing to access /data inside docker

In docker, the /data dir is mapped to $VOL_BASE_DIR, which is created by
docker-playground.git jenkins-common.sh, hence as the user running
jenkins.sh in the host system.
As a result, when the dir is mapped to /data, inside the container it
will have the UID:GID of the outter user, not the one inside docker.

Before this patch, if a ttcn3 container was started in jenkins.sh with
--cap-add=NET_ADMIN, then osmo-ttcn3-hacks.git/ttcn3-tcpdump-start.sh
would select dumpcap instead of tcpdump, to attempt to record a pcap
file to /data/$testcase.pcap.
Due to some unknown way of dropping privileges done by dumpcap though,
it was unable to open the /data/$testcase.pcap due to /data being owned
to another user (tcpdump doesn't have this problem).

This patch fixes the above scenario by making sure /data is chowned to
the user running stuff inside docker. This is already kinda expected
since there's a fix_perms() script in jenkins-common.sh reverting files
created during the test so that they can be accessible by outter user
once everything is finished.

Change-Id: I1229a91cdbb1aa73fd94f1bf7e26f34086f06b25
The file was modifiedcommon/ttcn3-docker-run.sh