Hi everybody
I've configured a SIP server (OpenSER 1.3.2) to work with rtpproxy and so far everything is fine, but now I want to be able to record the audio from a conversation. I've read that this is possible by using the function start_recording from the module NATHelper but I'm not able to get it working
RTPproxy 1.2.1 is running with the following options:
root@openser:/opt/rtpproxy-1.2.1/bin# ps uax | grep rtpproxy
rtpproxy 30827 0.0 0.0 26968 964 ? Ssl 14:49 0:00 /opt/rtpproxy-1.2.1/bin/rtpproxy -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.34.1 -s udp:127.0.0.1 7890 -r /etc/openser/stored_conversations -S /tmp -a -d DBUG -P
root 31547 0.0 0.0 7524 892 pts/1 R+ 15:59 0:00 grep rtpproxy
Output from netstat
root@openser:/opt/rtpproxy-1.2.1/bin# netstat -tupna | grep rtpproxy
udp 0 0 127.0.0.1:7890 0.0.0.0:* 30827/rtpproxy
Relevant parts of the configuration file
...
# ------ nathelper params -----
modparam("nathelper", "natping_interval", 30)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_bflag", 7)
modparam("nathelper", "sipping_from", "sip:pinger@openser.org")
modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7890")
modparam("nathelper", "force_socket", "udp:localhost:7890")
...
route[6] {
xlog("L_INFO", "ROUTE 6");
# NAT handling
# Set reply routing block, to which control is passed after a transaction
# completed with a negative result but before sending a final reply
t_on_failure("1");
# Check if we're NATed
if (isflagset(5) || isbflagset(6)) {
# Use rtpproxy
force_rtp_proxy();
if ( start_recording() ) {
xlog("L_INFO", "RECORDING...");
};
}
# Set reply routing block, to which control is passed each time a reply
# (provisional or final) for the transaction is received
t_on_reply("1");
}
...
onreply_route[1] {
xlog("L_INFO", "ONREPLY_ROUTE");
if ((isflagset(5) || isbflagset(6)) && status=~"(180)|(183)|(2[0-9][0-9])") {
xlog("L_INFO", "NAT'd TRANSACTION");
fix_nated_contact();
force_rtp_proxy();
if ( start_recording() ) {
xlog("L_INFO", "RECORDING...");
};
}
else if (nat_uac_test("1")) {
fix_nated_contact();
}
exit;
}
When I start OpenSER I see the following in syslog
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: NOTICE:core:main: version: openser 1.3.2-notls (x86_64/linux)
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:core:main: using 256 Mb shared memory
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:core:main: using 1 Mb private memory per process
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:sl:mod_init: Initializing StateLess engine
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:tm:mod_init: TM - initializing...
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:maxfwd:mod_init: initializing...
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:usrloc:ul_init_locks: locks array size 512
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:registrar:mod_init: initializing...
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:textops:mod_init: initializing...
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:xlog:mod_init: initializing...
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:avpops:avpops_init: initializing...
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:acc:mod_init: initializing...
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:dialog:mod_init: Dialog module - initializing
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:core:probe_max_receive_buffer: using a UDP receive buffer of 255 kb
Mar 19 16:08:45 openser /usr/sbin/openser[31630]: INFO:core:probe_max_receive_buffer: using a UDP receive buffer of 255 kb
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31632_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31632_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31632_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31632_1 1 "
Mar 19 16:08:45 openser /usr/sbin/openser[31632]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31631_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31631_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31633_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31633_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31634_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31634_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31635_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31635_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31636_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31636_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31637_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31637_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31638_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31638_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31637_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31637_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31631_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31631_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31634_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31634_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31636_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31636_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31633_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31633_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31635_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31635_1 1 "
Mar 19 16:08:45 openser /usr/sbin/openser[31631]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31634]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31637]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31633]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31636]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31635]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31638]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31639_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31639_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31638_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31638_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31640_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31640_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31642_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31642_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31643_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31643_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31644_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31644_0 20040107 "
Mar 19 16:08:45 openser /usr/sbin/openser[31642]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31643]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31645_0 V"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31645_0 20040107 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31639_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31639_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31642_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31642_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31644_1 VF 20050322"
Mar 19 16:08:45 openser /usr/sbin/openser[31644]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31644_1 1 "
Mar 19 16:08:45 openser /usr/sbin/openser[31640]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser /usr/sbin/openser[31639]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31640_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31640_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31643_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31643_1 1 "
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:handle_command: received command "31645_1 VF 20050322"
Mar 19 16:08:45 openser rtpproxy[30827]: DBUG:doreply: sending reply "31645_1 1 "
Mar 19 16:08:45 openser /usr/sbin/openser[31645]: INFO:nathelper:rtpp_test: rtp proxy <udp:127.0.0.1:7890> found, support for it enabled
But when I place the call no debug info from rtpproxy is being generated nor the RTP session is being saved to file.
Any idea what the problem can be?
Thanks in advance
Héctor
Hi all! Kamailio newbie here.
Well my setup is like this
Kamailio as load balancer and proxy -> Multiple clustered asterisk as
registrars
What I wanted to do was have all clients registered to asterisk so that most
of the pbx stuff will be done thru it and I'm using Asterisk Realtime as
well and doing A2billing at the same time so I was thinking if my setup will
actually work.
I have already configured kamailio to do load balancing and send to my
asterisk servers and my xlite is able to register to my asterisk server, the
problem I have right now is when I try to call, the call gets dropped. I
believe it's something about asterisk not being able to send the correct
INVITE or not being able to receive the ACK or something to that effect.
Please help me, as I've said I'm just a newbie with kamailio.
TIA!
We are planning a new voip system. The trunk is provided to us on a
private 10.x.x.x/29 range, and therefore not available direct to our end
customers. We plan to have some kind of SIP/RTP proxy in front of the
trunk, and a PBX in front of this. The trunk doesn't have any
authentication, the end customers should connect and authenticate to the
PBX in front, and the RTP streams should terminate to the proxy.
Is this possible to achieve by using Kamailio and RTPProxy?
Trunk
|
| 10.x.x.x/29
|
SIP Proxy
|
PBX Asterisk etc.
|
Customer
I have tried many different configurations and browsed every bundled
example and web, but still I am not able to do what I want. This have
already given me some grey hears, so I guess it's time to check if this
is even possible. If not, is there any other approach that is more
recommendable? If someone has done this before I would appreciate some
example configuration that I could work with.
Regards
Espen, Norway
Hello all,
since now it is possible to use only web interface to manage mailing
lists hosted on lists.iptel.org server. We had to disable the email
commands interface as part of fight against spam (it was causing too
many messages being sent from us, recognized by some blacklists as spam).
This means that for all actions like subscribing, un-subscribing,
changing your preferences etc. you have to use the web interface. You
can find a link to it at end of every message sent to the mailing list.
Sorry if it causes any inconvenience to you.
Pavel Kasparek
Hi List,
I have Kamailio 3.0.1 running from GIT with my old 1.5.3 config file.
Everything seems fine except the RPID.
I'm not getting any RPID sent in the SIP message and if I put debug=3 I see:
DEBUG: auth [rpid.c:177]: no rpid AVP
My config:
# auth
modparam("auth", "rpid_avp", "$avp(s:rpid)")
modparam("auth", "rpid_prefix", "<sip:")
modparam("auth", "rpid_suffix","@asterisk.ie
;party=calling;id-type=subscriber;privacy=off;screen=yes>")
# auth_db
modparam("auth_db", "db_url", "mysql://openser:XSXXXX@localhost/openser")
modparam("auth_db", "calculate_ha1", 1)
modparam("auth_db", "password_column", "password")
modparam("auth_db", "load_credentials", "$avp(s:rpid)=rpid")
in my route:
append_rpid_hf();
Probably missing something very simple. Any help would be appreciated.
Thanks,
Stephen.
i just made a test and noticed that route() accepts a pv argument.
at least i didn't get anhy syntax error from
route("$var(test)");
this is good if it works. Core functions section of
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#route
does not list route() function call at all.
-- juha
Hi, I set fr_inv_timer=150 and use lcr module to balance (and failover)
between two gateways.
In the failure route I set (simplified):
failure_route[FAILURE_ROUTE_OUT] {
if (t_local_replied("last")) {
next_gw();
t_relay();
}
}
This means that if a INVITE routed to gateway-1 replies a provisional response
but no final response within 150 seconds, then Kamailio should generate a
local 408 and failure route would relaty to gateway-2.
But what I see is that such "timeout" time is 75 seconds (the half of 150 !).
I remember a similar "issue" when handling with SRV DNS domains returning more
than one destinations, but in my case I just use single IP's in lcr module.
But the fact is that I use exactly 2 gateways in lcr (150/2 = 75). But anyhow
it doesn't make sense.
Do I miss something?
Thanks.
PD: Important, could occur the same with fr_timer?
--
Iñaki Baz Castillo <ibc(a)aliax.net>
i tested if route() with pv arg would work. i created a route block:
route [test] {
xlog("here we are\n");
return;
}
and then as the very first thing in the main route block i have:
$var(test) = "test";
route("$var(test)");
then i send the proxy a sip request and don't get anything related to
this to syslog, i.e., no "here we are" line nor any error message.
this looks like i bug to me, since if route() accepts a pv, i should see
"here we are" syslog entry or if it doesn't, i should see some kind of
error message.
comments?
-- juha
Hello all,
I am using kamailio-1.5.0 + mediaproxy. it works properly when
connection is in between two clients between same lan.
But when I connecting between two client who are on differet proxy
and behind different NAT, call has been established but no audio get
transferred.
What are the changed i suppose to do, or any parameters should get
enabled while compilation,
Thanks in advance.
--
Best Regards,
Rajnikant Vanza
Hi,
I'm using Kamailio - posted this to the opensips list as I thought I may get
support from the ag guys but nothing..
Has anyone else experienced this or have an idea as to what it may be?
Having a very small but annoying issue with Radius Accounting.
Everything is getting written fine except for 'Source-Port'
This appears in radius.log everytime a record is written/updated. - Error:
rlm_radutmp: NAS OpenSER port 5060 unknown packet type 15
It's writing this into the text files and value to the radacct table:
Source-Port = "\304\023"
All other information is being written correctly.
CDRTool version: 7.0
Freeradius version: 1.1.7-4
mediaproxy version: 2.3.10
Kamailio Version: 1.5.3
Using the dictionary files that ship with CDRTool
>From accounting:
modparam("acc", "db_url", "mysql://openser:XXXXXXXXXXXX@localhost/openser")
modparam("acc", "db_flag", 2)
modparam("acc", "log_flag", 2)
modparam("acc", "db_missed_flag", 3)
modparam("acc", "radius_config", "/etc/radiusclient-ng/radiusclient.conf")
modparam("acc", "radius_flag", 2)
modparam("acc", "radius_missed_flag", 3)
modparam("acc", "radius_extra", "User-Name=$Au; \
Calling-Station-Id=$from; \
Called-Station-Id=$to; \
Sip-Translated-Request-URI=$avp(s:translated_uri); \
Sip-RPid=$avp(s:rpid); \
Source-IP=$si; \
Source-Port=$sp; \
Canonical-URI=$avp(s:can_uri); \
Billing-Party=$avp(s:billing_party); \
Divert-Reason=$avp(s:divert_reason); \
X-RTP-Stat=$hdr(X-RTP-Stat); \
Contact=$hdr(contact); \
Event=$hdr(event); \
SIP-Proxy-IP=$avp(s:sip_proxy_ip); \
ENUM-TLD=$avp(s:enum_tld)")
Obviously it's not a show stopper but it's just bugging the hell out of me
:)
If any more info is required please let me know and I will provide ASAP.
TIA,
Stephen