Re: [SR-Users] RTPEngine Recording does not work
I solved it, it just update kernel module.
apt-get install -t jessie-backports linux-image-amd64
Thanks
On Sun, Jul 1, 2018 at 2:37 PM, Mojtaba wrote:
> What do you mean?
>
> On Sun, Jul 1, 2018 at 2:27 PM, Domenico Briganti wrote:
>> ll
>>
>> Il 01 lug 2018 11:48 AM, "Mojtaba" ha scritto:
>>
>> I have strange issue,
>> the output of of `uname -r` command is "3.16.0-4-amd64", while all the
>> debs file are "4.9.0-0.bpo.6-amd64".
>> ngcp-rtpengine_6.4.0.0+0~mr6.4.0.0_all.deb
>> ngcp-rtpengine-daemon_6.4.0.0+0~mr6.4.0.0_amd64.deb
>> ngcp-rtpengine-iptables_6.4.0.0+0~mr6.4.0.0_amd64.deb
>> ngcp-rtpengine-kernel-dkms_6.4.0.0+0~mr6.4.0.0_all.deb
>> ngcp-rtpengine-kernel-source_6.4.0.0+0~mr6.4.0.0_all.deb
>> ngcp-rtpengine-recording-daemon_6.4.0.0+0~mr6.4.0.0_amd64.deb
>> ngcp-rtpengine-utils_6.4.0.0+0~mr6.4.0.0_all.deb
>> Is it the reason of my issue?
>>
>> On Fri, Jun 29, 2018 at 9:57 PM, Aqs Younas wrote:
>>> you can check by starting your rtpengine with this parameter "--table=0".
>>> If
>>> kernal modules is properly installed you will not face any error.
>>>
>>> Best Regards,
>>>
>>> Aqs Younas
>>>
>>>
>>>
>>> On Fri, 29 Jun 2018 at 03:33, Mojtaba wrote:
Thank you. I installed RTPEngine from git
(https://github.com/sipwise/rtpengine).
Let me know how can i be sure kernel module is loaded? and how can i
load
it?
Thanks
On Thu, Jun 28, 2018 at 6:20 PM, Richard Fuchs
wrote:
> Looks like you haven't set up the kernel module properly. For the
> "proc"
> method of recording to work, the kernel module must be loaded and in
> use.
>
> Cheers
>
>
> On 2018-06-28 05:47, Mojtaba wrote:
>>
>> Hi all,
>> I installed RTPEngine (Version: 6.4.0.0+0~mr6.4.0.0
>> git-master-4eb80da) in my VM machine (Debian GNU/Linux 8 (jessie), i
>> also installed kamailio 5.1.
>>
>> In kamailio routes, i have:
>> route {
>> ...
>> #rtpengine_manage("record-call")
>> rtpengine_manage();
>> start_recording();
>> ...
>> }
>> Here is all other configuration files:
>>
>> In /etc/default/ngcp-rtpengine-daemon file:
>> RUN_RTPENGINE=yes
>> CONFIG_FILE=/etc/rtpengine/rtpengine.conf
>> CONFIG_SECTION=rtpengine
>> PIDFILE=/var/run/ngcp-rtpengine-daemon.pid
>> MANAGE_IPTABLES=yes
>> TABLE=0
>>
>> In /etc/default/ngcp-rtpengine-recording-daemon file:
>> RUN_RTPENGINE_RECORDING=yes
>> CONFIG_FILE=/etc/rtpengine/rtpengine-recording.conf
>> CONFIG_SECTION=rtpengine-recording
>> PIDFILE=/var/run/ngcp-rtpengine-recording-daemon.pid
>> MUST_NFS=no
>> NFS_HOST=192.168.1.1
>> NFS_REMOTE_PATH=/var/recordings
>> NFS_LOCAL_MOUNT=/var/lib/rtpengine-recording # must match output-dir
>> if
>> used
>> NFS_OPTIONS=hard,intr,tcp
>>
>> In /etc/rtpengine/rtpengine.conf file:
>> [rtpengine]
>> table = 0
>> interface = 192.168.122.200
>> listen-ng = 127.0.0.1:2223
>> recording-dir = /var/spool/rtpengine/
>> recording-method = proc
>>
>> In
>> [rtpengine-recording]
>> table = 0
>> # output-storage = db (use default)
>> # output-format = mp3 (use default)
>> # output-mixed = 1
>> spool-dir = /var/spool/rtpengine/metadata
>> output-dir = /var/spool/rtpengine/recording
>>
>> But the recording is not work, I have these issues in syslog:
>> [1530178531.860171] INFO:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Received command
>> 'start recording' from 127.0.0.1:38654
>> [1530178531.860191] NOTICE:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Turning on call
>> recording.
>> [1530178531.860239] WARNING:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Call recording through
>> /proc interface requested, but kernel table not open
>> [1530178531.860262] ERR:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Failed to open
>> recording metadata file '(null)' for writing: Bad address
>> [1530178531.860269] ERR:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Failed to open
>> recording metadata file '(null)' for writing: Bad address
>> [1530178531.860275] ERR:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Failed to open
>> recording metadata file '(null)' for writing: Bad address
>> [1530178531.860281] ERR:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Failed to open
>> recording metadata file '(null)' for writing: Bad address
>> [1530178531.860287] ERR:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Failed to open
>> recording metadata file '(null)' for writing: Bad address
>> [1530178531.860292] ERR:
>> [MWFhMWM4MmVhYjFmYjY3MzVlZDlmZWMyYjNmNGVhNmY.]: Failed to open
>> recording metadata file '(null)
Re: [SR-Users] rtpengine installation dependencies
In regard of my last post, If you have issue about kernel module, run this command to update it: apt-get install -t jessie-backports linux-image-amd64 Thanks On Tue, Jun 26, 2018 at 1:43 PM, Mojtaba wrote: > Thank you, I do it successfully. > I use these commands to install all dependencies: > apt-get -t jessie-backports install debhelper libmysqlclient-dev > iptables-dev libavcodec-dev libavfilter-dev libcurl4-openssl-dev > libevent-dev libglib2.0-dev libhiredis-dev libjson-glib-dev > libpcap0.8-dev libssl-dev libxmlrpc-core-c3-dev markdown > > apt-get -t jessie-backports install dkms module-assistant > With Regards. Mojtaba > > On Mon, Jun 25, 2018 at 7:01 PM, Aqs Younas wrote: >> Hello, Mojtaba. >> >> I don't remember the exact setups and unfortunately don't have access to >> server. But let me write few things I did which may help you. >> Added below line in source.list. >> 1. deb http://ftp.debian.org/debian jessie-backports main >> 2. apt-get update >> 3. apt-get -t jessie-backports install debhelper >> 4. Installed latest version of ffmpeg from source >> >> I was not able to successfully create .deb files but i was able to compile >> it manually. >> These links might help you. >> >> https://voipmagazine.wordpress.com/2015/02/17/rtpengine-compilation-and-installation-in-fedora-redhat/ >> http://hrhashmi.blogspot.com/2016/06/rtpengine-installation-on-amazon-ami.html >> >> Br, Aqs >> >> >> >> >> On Mon, 25 Jun 2018 at 14:19, Mojtaba wrote: >>> >>> Hi, >>> Please share the source.list for getting the lasted version of debhelper. >>> Thanks >>> >>> On Sat, Apr 7, 2018 at 2:45 AM, Aqs Younas wrote: >>> > Thanks for the answer. >>> > >>> > I had installed debhelper from Debian package but it had Version: >>> > 9.20150101+deb8u2. >>> > >>> > root@debian-769mb-miami-01:/usr/src/rtpengine# dpkg -s debhelper | grep >>> > '^Version:' >>> > Version: 9.20150101+deb8u2 >>> > >>> > Whereas rtpengine demands debhelper (>= 10~) >>> > >>> > That is why i was trying to install it from debs. >>> > >>> > Anyway, I updated my source.list and was able to get the lasted version >>> > of >>> > debhelpler. >>> > >>> > Thanks for your help. >>> > >>> > >>> > >>> > >>> > On 6 April 2018 at 20:45, Ulrich Henning wrote: >>> >> >>> >> Hi Aqs, >>> >> >>> >> >>> >> >>> >> just use the corresponding build flag ‘export >>> >> DEB_BUILD_PROFILES="pkg.ngcp-rtpengine.nobcg729"’ as stated in the >>> >> readme >>> >> (https://github.com/sipwise/rtpengine) and your issue should be fixed. >>> >> >>> >> >>> >> >>> >> BR, >>> >> >>> >> Henning >>> >> >>> >> >>> >> >>> >> Von: sr-users [mailto:sr-users-boun...@lists.kamailio.org] Im Auftrag >>> >> von >>> >> Aqs Younas >>> >> Gesendet: Freitag, 6. April 2018 17:31 >>> >> An: Kamailio (SER) - Users Mailing List >>> >> Betreff: [SR-Users] rtpengine installation dependencies >>> >> >>> >> >>> >> >>> >> Greetings list. >>> >> >>> >> >>> >> >>> >> This might not be related to Kamailio but I thought someone would be >>> >> able >>> >> to give a hand in resolving dependency during the installation of >>> >> rtpengine >>> >> on Debian 8 Jessie. >>> >> >>> >> >>> >> >>> >> It is complaining about below dependencies. >>> >> >>> >> >>> >> >>> >> root@debian-769mb-miami-01:/usr/src/rtpengine# dpkg-buildpackage >>> >> >>> >> dpkg-buildpackage: source package ngcp-rtpengine >>> >> >>> >> dpkg-buildpackage: source version 6.3.0.0+0~mr6.3.0.0 >>> >> >>> >> dpkg-buildpackage: source distribution unstable >>> >> >>> >> dpkg-buildpackage: source changed by Sipwise Jenkins Builder >>> >> >>> >> >>> >> dpkg-buildpackage: host architecture amd64 >>> >> >>> >> dpkg-source --before-build rtpengine >>> >> >>> >> dpkg-source: info: using options from rtpengine/debian/source/options: >>> >> --extend-diff-ignore=.gitreview >>> >> >>> >> dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 10~) >>> >> libbcg729-dev >>> >> >>> >> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; >>> >> aborting >>> >> >>> >> dpkg-buildpackage: warning: (Use -d flag to override.) >>> >> >>> >> >>> >> >>> >> I tried to install debhelper from deb but complained from dh-autoreconf >>> >> and that itself complained abount debhelpler. So, no one is being >>> >> installed. >>> >> >>> >> Also, If someone can help me how to resolve dependency for >>> >> libbcg729-dev >>> >> too. >>> >> >>> >> Any pointer or hint or link to some installation guide would be more >>> >> than >>> >> welcome. >>> >> >>> >> >>> >> >>> >> Br, Aqs. >>> >> >>> >> >>> >> ___ >>> >> Kamailio (SER) - Users Mailing List >>> >> sr-users@lists.kamailio.org >>> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> >>> > >>> > >>> > ___ >>> > Kamailio (SER) - Users Mailing List >>> > sr-users@lists.kamailio.org >>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> > >>> >>> >>> >>> -- >>> --Mojtaba Esfandiari.S >>> >>> __
[SR-Users] The problem of get_aor_hash function
Dear all, I'm trying Kamailio 5.1.4 and IMS module. When registering to Kamailio IMS using the same ip and port for 30 users (different contact user part), the P-CSCF get the same hash number and aor value. The function get_aor_hash(_d, &_ci->via_host, _ci->via_port, _ci->via_prot) in ims_usrloc_pcscf pcontact.c seems the problem. Because hashing with host, port, prot will get the same hash value. Anyone can help this ? ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] DMQ problems
On Mon, Jul 2, 2018 at 2:55 PM Charles Chance wrote: > Hi Aleksandar, > [...] > You do not, in fact, need to maintain a dedicated node who's only role is > "DMQ server" as you have described it. I would recommend removing it > completely and allowing your other nodes to discover/communicate between > themselves. Ok Thanks for your inputs, seems a good idea and I think we're on a good path to solve our issues. > Omitting the notification address should not cause an issue - what error do > you see in your log when it fails to start? If you get rid of the "DMQ > server' node as suggested above, though, this should be a none-issue. It does cause an issue: ``` 0(51) DEBUG: [core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <> (0) 0(51) ERROR: dmq [dmq.c:218]: mod_init(): notification address invalid 0(51) ERROR: [core/sr_module.c:990]: init_mod(): Error while initializing module dmq (/usr/lib/x86_64-linux-gnu/kamailio/modules/dmq.so) ERROR: error while initializing modules ``` Maybe a feature request could be to just start kamailio even if it does not resolve a dns record for the dmq notification_address? This would solve us some problems in a highly mutable infrastructure like ours: ``` 0(88) ERROR: dmq [notification_peer.c:336]: add_server_and_notify(): error adding notification node 0(88) ERROR: dmq [dmq.c:304]: child_init(): cannot retrieve initial nodelist from sip:proxy-service:5061 0(88) ERROR: [core/sr_module.c:944]: init_mod_child(): error while initializing module dmq (/usr/lib/x86_64-linux-gnu/kamailio/modules/dmq.so) (idx: 0 rank: 0 desc: [main]) 0(88) ERROR: [main.c:1711]: main_loop(): error in init_child``` So just to recap: - Not specifying a notification_address DOES give issues - Having a DNS record for the notification_address that does not resolve makes kamailio to crash Any possibility to have this solved/enhanced? Thanks, -- Aleksandar Sosic mail: alex.sosic@evosip.cloud ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] DMQ problems
I'll take a look - which version are you using? Cheers, Charles On 5 July 2018 at 11:17, Aleksandar Sosic wrote: > On Mon, Jul 2, 2018 at 2:55 PM Charles Chance > wrote: > > Hi Aleksandar, > > [...] > > You do not, in fact, need to maintain a dedicated node who's only role > is "DMQ server" as you have described it. I would recommend removing it > completely and allowing your other nodes to discover/communicate between > themselves. > > Ok Thanks for your inputs, seems a good idea and I think we're on a > good path to solve our issues. > > > Omitting the notification address should not cause an issue - what error > do you see in your log when it fails to start? If you get rid of the "DMQ > server' node as suggested above, though, this should be a none-issue. > > It does cause an issue: > ``` > 0(51) DEBUG: [core/parser/parse_uri.c:1254]: parse_uri(): uri > too short: <> (0) > 0(51) ERROR: dmq [dmq.c:218]: mod_init(): notification address invalid > 0(51) ERROR: [core/sr_module.c:990]: init_mod(): Error while > initializing module dmq > (/usr/lib/x86_64-linux-gnu/kamailio/modules/dmq.so) > ERROR: error while initializing modules > ``` > > Maybe a feature request could be to just start kamailio even if it > does not resolve a dns record for the dmq notification_address? This > would solve us some problems in a highly mutable infrastructure like > ours: > > ``` 0(88) ERROR: dmq [notification_peer.c:336]: > add_server_and_notify(): error adding notification node > 0(88) ERROR: dmq [dmq.c:304]: child_init(): cannot retrieve initial > nodelist from sip:proxy-service:5061 > 0(88) ERROR: [core/sr_module.c:944]: init_mod_child(): error > while initializing module dmq > (/usr/lib/x86_64-linux-gnu/kamailio/modules/dmq.so) (idx: 0 rank: 0 > desc: [main]) > 0(88) ERROR: [main.c:1711]: main_loop(): error in init_child``` > > So just to recap: > - Not specifying a notification_address DOES give issues > - Having a DNS record for the notification_address that does not > resolve makes kamailio to crash > > Any possibility to have this solved/enhanced? > > Thanks, > -- > Aleksandar Sosic > mail: alex.sosic@evosip.cloud > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] sdpops / keep_codecs_by_name not modifying sdp unless i call msg_apply_changes
Hi, I'm encountering an issue where calling keep_codecs_by_name does not modify the SDP on the INVITE unless I call the "evil function" msg_apply_changes Any help is welcome, Thanks, Enrico. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] RFC: database unsigned number types
Hello, starting here a discussion about an issue with the database API and signed/unsigned number type to see how to address it. So far, the database API supported only signed types for numbers, respectively DB1_INT (int in c) and DB1_BIGINT (long long in c). However, many database table columns are defined as UNSIGNED INT or UNSIGNED BIGINT. The database connector modules are mapping UNSIGED values retrieved from database over signed fields in DB API structure. The other way around is done as well: signed values are the inserted in the unsigned columns. There is no issue if the value in C is a positive number, however, if the value goes over MAX_UINT/2 (over 2147483647), it becomes negative and inserting the value in database results in an exception and 0 being stored instead. So far, I guess the issue was rarely exposed, if at all, because no report on it, even these data types for DB1 are since the SER project was started in 2001. As I looked at database definition schema, most of unsigned columns are for internal flags or ids (e.g., lcr_id), where I guess no large values were used or needed so far. However, it can bite at any time and needs to be addressed. So far, two solutions come in mind: 1) drop using UNSIGNED INT for those db columns, use only INT and do unsigned cast in the C code when reading and cast to int when writing. 2) update the db connector modules to support unsigned types -- I added support for them in DB API, but each db_* module has to be updated. The also each module that uses UNSIGNED DB columns must be updated 1) should be simpler, 2) more work but better in long term Any other ideas? Which of the options you prefer to go for? Not to forget: somehow related, probably we have to switch from int to long for PV number values, otherwise timestamp variables can go negative once unix timestamp approaches MAX_UINT/2 (still plenty of time, but should not be delayed for long ...). Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
