I underestand your meaning.
Thank you.
On Mon, Jul 9, 2018 at 1:54 PM, Pawel Kuzak wrote:
> Hi,
>
> You can. For every new call a new connection is established using the UNIX
> socket. So different connections means different calls.
>
> Regards,
> Paul
>
>
>
> Am 09.07.2018 um 10:43 schrieb Mojta
Hi,
You can. For every new call a new connection is established using the
UNIX socket. So different connections means different calls.
Regards,
Paul
Am 09.07.2018 um 10:43 schrieb Mojtaba:
Hello,
In RTPEngine recording-daemon, I enabled "forward-to" option to
unix_socket. All things work ri
Hello,
In RTPEngine recording-daemon, I enabled "forward-to" option to
unix_socket. All things work right, I got metadata at first, then
media packets (RTP-UDP-IP).
The metadata for each calls is received just at first packet, but i
want to know, if i have more than one concurrent active call in
RT
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:
>>
>
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~
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-iptabl
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-kern
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/rtpen
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"
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
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
On 12/08/17 03:49 PM, Alex Balashov wrote:
Also, the "proc" recording method has an interesting pipeline, involving
an ephemeral metadata file and a memory sink exposed through /proc, and
a userspace daemon picking up the data and writing it to disk (if this
doesn't happen, audio frames going int
Also, the "proc" recording method has an interesting pipeline, involving
an ephemeral metadata file and a memory sink exposed through /proc, and
a userspace daemon picking up the data and writing it to disk (if this
doesn't happen, audio frames going into the sink are discarded).
This pipeline le
I have succeeded in prototyping a recording setup using the 'proc'
method.
However, I've got one issue I can't seem to figure out. On inbound calls
only, the inbound (caller) leg on the PSTN side seems to show up
interleaved/stuttered in the recording, and also slowed down
considerably. This does
On 10/08/17 12:23 PM, Alex Balashov wrote:
On Thu, Aug 10, 2017 at 12:22:32PM -0400, Richard Fuchs wrote:
There's actually two distinct recording methods implemented. The one you're
describing simply outputs pcap files containing the raw packets involved in
the call. The other method involves t
On Thu, Aug 10, 2017 at 12:22:32PM -0400, Richard Fuchs wrote:
> There's actually two distinct recording methods implemented. The one you're
> describing simply outputs pcap files containing the raw packets involved in
> the call. The other method involves the aforementioned external recording
> d
On 10/08/17 11:40 AM, Alberto Llamas wrote:
Hi Alex,
I had the opportunity to play around with this recording and it works
very well. We have it implemented on production by the way.
The information about how it works, recording formats you can find in
the README here (https://github.com/sip
On Thu, Aug 10, 2017 at 11:40:28AM -0400, Alberto Llamas wrote:
> Once you have the recording you need a third-party tool to convert those
> files to a wav format for instance. It depends on the codec the call is
> being recorded the convert tool you have to use like ffmpeg.
Thank you for your fe
Hi Alex,
I had the opportunity to play around with this recording and it works very
well. We have it implemented on production by the way.
The information about how it works, recording formats you can find in the
README here (https://github.com/sipwise/rtpengine).
Once you have the recording you
I have gathered that RTPEngine has recently, or perhaps some time ago,
evolved a recording feature set:
https://kamailio.org/docs/modules/5.0.x/modules/rtpengine.html#rtpengine.f.start_recording
Does anyone have any experience using it with Kamailio? How does it
work? Any gotchas or pitfalls?
It
20 matches
Mail list logo
