I tried to issue mtree.list command using xmlrpc query that would result
in large response, and got error
Aug 15 18:12:07 char /usr/bin/sip-proxy[10348]: ERROR: <core> [core/tcp_main.c:618]: _wbufq_add(): (221375 bytes): write queue full or timeout (0, total 0, last write 55534052 s ago)
Aug 15 18:12:07 char /usr/bin/sip-proxy[10348]: ERROR: xmlrpc [xmlrpc.c:811]: send_reply(): Error while sending reply
Aug 15 18:12:07 char /usr/bin/sip-proxy[10367]: ERROR: <core> [core/tcp_main.c:3551]: handle_ser_child(): received CON_ERROR for 0x7f112ad22be0 (id 5), refcnt 3, flags 0x4018
I though that perhaps I could get rid of the error by increasing value
of core var tcp_conn_wq_max. Description of the var tells:
Maximum bytes queued for write allowed per connection. Attempting to
queue more bytes would result in an error and in the connection being
closed (too slow). If tcp_write_buf is not enabled, it has no effect.
What is tcp_write_buf and how to enable it? I could not find anything
about it in core cookbook.
-- Juha
Hello,
Before i used RTPEngine (6.4.0.0+0~mr6.4.0.0) without any problem,
Nowday i install RTPEngine from git. I notice that it's varsion is
changed to 6.5.0.0+0~mr6.5.0.0. When i want install
ngcp-rtpengine-recording-daemon, I have this issue:
Failed to start ngcp-rtpengine-recording-daemon.service: Unit
rpcbind.socket failed to load: No such file or directory.
invoke-rc.d: initscript ngcp-rtpengine-recording-daemon, action "start" failed.
dpkg: error processing package ngcp-rtpengine-recording-daemon (--install):
subprocess installed post-installation script returned error exit status 6
Processing triggers for systemd (215-17+deb8u7) ...
Errors were encountered while processing:
ngcp-rtpengine-recording-daemon
Please let me what is this issue?
--
--Mojtaba Esfandiari.S
I have installed kamailio 5.1.4 version in ubuntu server. I need to route
RTP packets through kamailio with SIP packets. I will explain the way i
have set up everything.
I have installed rtpproxy by apt-get install rtpproxy.
i have edited "/etc/default/rtpproxy" file with the line 'EXTRA_OPTS="-F -s
udp:127.0.0.1:7722 -l 34.201.122.249 -d DBUG:LOG_LOCAL0"'
i have edited "/etc/init.d/rtpproxy" file as follows,
DAEMON=/usr/bin/$NAME
PIDFILE="/run/$NAME/$NAME.pid
I have provided "#!define WITH_NAT" and "modparam("rtpproxy",
"rtpproxy_sock", "udp:127.0.0.1:7722")" in my cfg file.
started rtpproxy "service rtpproxy start"
when i try "netstat -tulpn | grep rtp" it shows
udp 0 0 127.0.0.1:7722 0.0.0.0:*
1437/rtpproxy
So i think the rtpproxy is currently running fine.
Now we can go to kamailio part.
I have gone through the document "
https://www.kamailio.org/docs/modules/5.0.x/modules/rtpproxy.html" to set
up rtpproxy in the cfg file.
checking the rtp ports "kamcmd rtpproxy.list" showing
{
setid: 0
url: udp:127.0.0.1:7722
index: 0
disabled: 0
weight: 1
recheck: 0
}
I have enabled rtp proxy using "kamcmd rtpproxy.enable udp:127.0.0.1:7722
1".
So i think ports are ready for rtp proxy.
Now i will explain the call flow. I have enabled log using L_BUG.
when i try a call from hangout number through my twilio trunk to my
asterisk freepbx extension,
set_rtp_proxy_set("1"); giving true value. But rtpproxy_offer(); giving -1
as result. syslog shows some errors like below,
Aug 13 10:28:57 ip-172-30-0-10 rtpproxy[1437]: DBUG:handle_command:
received command "1934_4 Uc0,8,3,111,9,101
52001b5b71435b1c5392b39f2f6c975b@asterisk_ip:5060 asterisk_ip 14540
as4083c85f;1"
Aug 13 10:28:57 ip-172-30-0-10 rtpproxy[1437]: INFO:handle_command: new
session 52001b5b71435b1c5392b39f2f6c975b@asterisk_ip:5060, tag as4083c85f;1
requested, type strong
Aug 13 10:28:57 ip-172-30-0-10 rtpproxy[1437]: ERR:create_twinlistener:
can't bind to the IPv4 port 47926: Cannot assign requested address
Aug 13 10:28:57 ip-172-30-0-10 rtpproxy[1437]: ERR:handle_command: can't
create listener
Aug 13 10:28:57 ip-172-30-0-10 rtpproxy[1437]: DBUG:doreply: sending reply
"1934_4 E10#012"
And also my header is not changed. As a result actuall rtp is going end to
end between asterisk and twilio not through kamailio. Please help me with
the details.
Hi,
We have a scenario like this:
ITSP -----> Kamailio -----> Endpoint
(UDP) (TLS)
So, TLS is only being used on the last hop, and the upstream interaction
with the ITSP is plain-old UDP.
Kamailio has the following listeners:
listen=udp:1.1.1.1:5060
listen=udp:1.1.1.2:5060
listen=tcp:10.0.0.1:5060
listen=tls:1.1.1.1:5061
At some point, 'Endpoint' sends a reinvite which has the following RURI:
INVITE sip:1.1.1.1:5061 SIP/2.0
This is clearly improper, and caused a loop that led to the rtpengine
SDP loop issue I previously reported in another thread.
So, in an effort to stop this, I added the following:
if(has_totag()) {
if(loose_route()) {
...
if(is_method("INVITE")) {
xlog("L_INFO", "[R-MAIN:$ci] Re-INVITE received from $si:$sp to RURI $ru\n");
xlog("L_INFO", "[R-MAIN:$ci] Reinvite body: $mb\n");
if(!is_method("ACK") && uri == myself) {
sl_send_reply("400", "Bad Request");
exit;
}
}
}
But it doesn't work. It appears that the '400 Bad Request' rejection
never happens, presumably because the this domain doesn't match
'myself'.
Another perplexing mystery: the log message containing the reinvite's
'$ru' does not show a RURI of 'sip:1.1.1.1:5061', but rather the remote
target in the initial inbound INVITE, which we also logged:
Contact: "Anonymous" <sip:Restricted@3.3.3.3:5060>
The log message says:
[R-MAIN:...] Re-INVITE received from 4.4.4.4:5060 to RURI sip:Restricted@3.3.3.3:5060;lr.
Note a subtle detail here: the ';lr' parameter is present, which is an
attribute of the Record-Route inserted by the sending ITSP (3.3.3.3).
It's at the bottom of the Route set, of course, below Kamailio's two RRs
(inserted for the ingress UDP interface and the egress TLS interface):
Route: <sip:Restricted@3.3.3.3:5060;lr>
This leads to two questions whose causes seem to be related:
1. Why does Kamailio think the request URI of this re-invite is
something other than what $mb reveals it to be?
2. Is that, presumably, why it does not match 'myself'?
3. Why would Kamailio think it is actually set to the far-end
Record-Route URI?
This is version: kamailio 4.4.5 (x86_64/linux) d48094.
Thanks,
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Good Morning everyone,
Has anyone ever gotten rtpproxy/rtpengine to work with Kamailio and Asterisk?
I have tried both, and even though I see no errors with either, and when I make calls I see rtpproxy/rtpengine traffic, I am still seeing media traffic go directly to and from Asterisk. I just can't get the media packets to not go directly from Asterisk to the Callee and visa-versa.
Any ideas on where I am messing up in my kamalio.cfg file?
Thank you!,
-Steve
Hello,
I migrated from Rtp_proxy module to Rtp_Engine.
Everythings works fine apart the rewriting of the SDP description in Kamailio
subst_body('/(^s=.*)/s=Test of a Sip call.\r/')
Any ideas if this is supposed to be supported?
Hi All,
Is it possible for Kamailio to interface with a particular Asterisk Server based on the FQDN of a caller?
I would like to pass calls received by Kamailio through to different Asterisk Servers based on the FQDN of the caller. I have used Load Balancing before, but I want to select which Asterisk Server the call is directed to.
Thank you,
HI All,
I am not sure if I understand it correctly but I thought that I could use rtpengine to redirect media packets. My current SIP flow is =>
Softphone=>Kamailio=>Asterisk=>Kamailio=>Softphone, and Media flows from is Asterisk<=>softphone. But I don't want Media to flow this way.
That is, I do not want Asterisk and the Softphone to be aware of each other. I would like the Media to go through Kamailio just like SIP packets do.
I installed rtpengine and it starts and runs with no errors. I even see traffic with the call is made but media traffic still flows from softphone<=>asterisk.
Any ideas?
Thank you,
Hello,
I want to upgrade my both Kamailio from 4.4 to 5.1
I have to upgrade the SQL structure before running the 5.1 release.
But my SQL servers are synchronized - Kamailio 4.4 can works with the 5.1 SQL structure ?
Hi Henning,
thanks again. I found meanwhile the root cause. It caused as you said by
the old logic of the make file. I used instead the new Formula of the tm
module’s make file (as i remember). Consequently, it did not bring the
compilation through those unwanted libraries.
I will spot the details later when i am back in office next Monday.
BR
Abdulaziz
On Thu 9. Aug 2018 at 21:19 Henning Westerholt <hw(a)kamailio.org> wrote:
> Am Donnerstag, 9. August 2018, 14:27:44 CEST schrieb Abdulaziz Alghosh:
> > thanks a lot for your response and explanation. strutils.[c,h] and
> > strcommon.[c,h] are almost the same. So I modified my included header
> from
> > stcommon[] to strutils as you mentioned.
> > Unfortunately, I surfed sequentially Kamailio version upgrades. Even
> > though, i did not found such hints about this modification. So I have
> some
> > doubts the called headers and codes from our own module. Hence, I am
> asking
> > for yor advice.
>
> Hello Abdul,
>
> lets move this discussion to the sr-dev list, as its a development related
> topic.
>
> > What I am trying to do now is compiliing our module separately under it
> is
> > own directory so I gain the Shared Object file (.so). Somehow our Module
> is
> > requring cds, presence and xcap libraries. But the strange thing is that
> > headers from these libraries are #including other headers assuming these
> > included header files are under the same library's directory (but in fact
> > most of the header files are under ../src/core/). For example :
>
> Do you placed your own module in the src/modules directory as well? If
> not, I
> would suggest to place it there. Its hard to find the issue just with the
> logs, there are also many errors here.
>
> My suggestion would be to go from your own module and try to compile a
> single
> file with gcc (for the actual command you can call "make quiet=0" and copy-
> paste it). I would try to investigate one error a time, in the end they
> should
> be all mostly related.
>
> There were also some changes in the Makefile logic, maybe you should
> compare
> your Makefile to one of the official modules.
>
> > Making in cds
> > CC (gcc) [L libser_cds.so.0.1] cds.o
> > In file included from cds.c:2:
> >
> /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/memory.h:125:21:
> > warning: mem/mem.h: No such file or directory
> >
> /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/memory.h:126:25:
> > warning: mem/shm_mem.h: No such file or directory
> > In file included from cds.c:3:
> > /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/sync.h:30:22:
> > warning: locking.h: No such file or directory
> > In file included from cds.c:4:
> >
> /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/logger.h:42:20:
> > error: dprint.h: No such file or directory
> > make[2]: *** [cds.o] Error 1
> > make[1]: [cds] Error 2 (ignored)
> >
> >
> > Those libraries are delivered with version 5.1.4 itself so i do not think
> > it is a good idea to modify the paths of the included header files to
> > compile my module. because most probably these libraries are needed by
> > standard default modules of kamailio.
> >
> > I hope this is not too much for you to inspect.
> > Note: The attached has the log files ( resulting from make all and
> install
> > ) .
> >
> > Your kind response is highly appreciated
> > BR
> > Abdulaziz
> >
> > On Thu, Aug 9, 2018 at 11:31 AM, Abdulaziz Alghosh <aziz647(a)gmail.com>
> >
> > wrote:
> > > Hello Henning,
> > >
> > > thanks a lot for your response and explanation. strutils.[c,h] and
> > > strcommon.[c,h] are almost the same. So I modified my included header
> from
> > > stcommon[] to strutils as you mentioned.
> > > Unfortunately, I surfed sequentially Kamailio version upgrades. Even
> > > though, i did not found such hints about this modification. So I have
> some
> > > doubts the called headers and codes from our own module. Hence, I am
> > > asking
> > > for yor advice.
> > >
> > > What I am trying to do now is compiliing our module separately under
> it is
> > > own directory so I gain the Shared Object file (.so). Somehow our
> Module
> > > is
> > > requring cds, presence and xcap libraries. But the strange thing is
> that
> > > headers from these libraries are #including other headers assuming
> these
> > > included header files are under the same library's directory (but in
> fact
> > > most of the header files are under ../src/core/). For example :
> > >
> > > Making in cds
> > > CC (gcc) [L libser_cds.so.0.1] cds.o
> > > In file included from cds.c:2:
> > >
> /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/memory.h:125:2
> > > 1: warning: mem/mem.h: No such file or directory
> > >
> /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/memory.h:126:2
> > > 5: warning: mem/shm_mem.h: No such file or directory
> > > In file included from cds.c:3:
> > >
> /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/sync.h:30:22:
> > > warning: locking.h: No such file or directory
> > > In file included from cds.c:4:
> > >
> /Abdul/install/clean_test/kamailio-5.1.4/src/lib/cds/../cds/logger.h:42:20
> > > :
> > > error: dprint.h: No such file or directory
> > > make[2]: *** [cds.o] Error 1
> > > make[1]: [cds] Error 2 (ignored)
> > >
> > >
> > > Those libraries are delivered with version 5.1.4 itself so i do not
> think
> > > it is a good idea to modify the paths of the included header files to
> > > compile my module. because most probably these libraries are needed by
> > > standard default modules of kamailio.
> > >
> > > I hope this is not too much for you to inspect.
> > > Note: The attached has the log files ( resulting from make all and
> install
> > > ) .
> > >
> > > Your kind response is highly appreciated
> > > Abdulaziz
> > >
> > >
> > > On Thu, Aug 9, 2018 at 8:11 AM, Henning Westerholt <hw(a)kamailio.org>
> > >
> > > wrote:
> > >> Am Mittwoch, 8. August 2018, 17:47:07 CEST schrieb Abdulaziz Alghosh:
> > >> > i am somehow newbie with Kamailio and trying to migrate from
> kamailio
> > >> > version 3.0.3 to 5.1.4. Former fellows had developed own modules
> which
> > >> > needed "strcommon.h" and "strcommon.c".
> > >> >
> > >> > These last two files are not delievered with version 5.1.4. but I
> > >> > copied
> > >> > them under ../src/core/ thinking it would be beneficial.
> Unfortunately,
> > >> > after make prefix / (and including our own module) all, it seem that
> > >> > several dependencies exist. Especially from header files under
> > >> > ..src/lib/xcap/ and ../src/lib/presence
> > >> >
> > >> > Can somebody tell me how "strcommon.h" and "strcommon.c" where
> > >>
> > >> replaced in
> > >>
> > >> > version 5.1.4 ?
> > >>
> > >> Hello Abdul,
> > >>
> > >> the functions in strcommon.[c,h] were moved into
> src/core/strutils.[c,h]
> > >> in
> > >> releases starting from 5.0. I'd suggest to have a look to the file to
> > >> verify
> > >> if there are no other changes.
>
> Best regards,
>
> --
> Henning Westerholt
> https://skalatan.de/blog/
>