Hi,
The network topology is :
SipSoftphone(caller)----->kamailio/rtpproxy---->Softswitch---->sipGateway-->mobile
phone(callee)
The rtpproxy is managed in kamailio script by :
if (is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
}
}
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return;
if (is_request()) {
rtpproxy_offer("co");
}
if (is_reply()) {
rtpproxy_answer("coz80");
}
if (is_request()) {
if (!has_totag()) {
if(t_is_branch_route()) {
add_rr_param(";nat=yes");
}
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
if(is_first_hop())
set_contact_alias();
}
}
Now if in rtpproxy_answer(), i don't resize rtp packets, then
everything works fine. If i put "z80" then only one way audio can be
heard. In SipSoftphone(caller) side, nothing can be heard.
I have sniffed the SIP packets and it looked fine to me. The rtp
packets from callee arrives fine in kamailio/rtpproxy box. But it does
not leave that box.
I've sniffed the rtp packets. Before the call is picked up by the
callee, there is an ivr played. The ivr arrives at the
caller(softphone) end fine. But after picking up the phone, rtppackets
are not delivered to the caller(softphone)'s side.
This is the rtpproxy's log:
May 11 23:54:29 65429 rtpproxy[24207]: INFO:rxmit_packets: callee's
address latched in: 85.13.205.178:13716 (RTP)
May 11 23:54:41 65429 rtpproxy[24207]: DBUG:get_command: received
command "27802_12 Uc18,96 2b15632de8c94ff488e9cdc1cdbcb85d
182.16.156.25 4000 74d009e3a57246138e2e0124cbe6ee89;1"
May 11 23:54:41 65429 rtpproxy[24207]: INFO:handle_command: adding
strong flag to existing session, new=1/0/0
May 11 23:54:41 65429 rtpproxy[24207]: INFO:handle_command: lookup on
ports 54920/64810, session timer restarted
May 11 23:54:41 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27802_12 54920 64.120.57.111#012"
May 11 23:55:42 65429 rtpproxy[24207]: INFO:process_rtp: session timeout
May 11 23:55:42 65429 rtpproxy[24207]: INFO:remove_session: RTP stats:
1523 in from callee, 300 in from caller, 396 relayed, 0 dropped
May 11 23:55:42 65429 rtpproxy[24207]: INFO:remove_session: RTCP
stats: 0 in from callee, 8 in from caller, 8 relayed, 0 dropped
May 11 23:55:42 65429 rtpproxy[24207]: INFO:remove_session: session on
ports 54920/64810 is cleaned up
May 11 23:58:58 65429 rtpproxy[24207]: DBUG:get_command: received
command "27802_13 Uc18,96 008e2697e52a4adda7be16358b318def
182.16.156.25 4002 907ba9691f6a47f3bfb0bb4143ef7dc7;1"
May 11 23:58:58 65429 rtpproxy[24207]: INFO:handle_command: new
session 008e2697e52a4adda7be16358b318def, tag
907ba9691f6a47f3bfb0bb4143ef7dc7;1 requested, type strong
May 11 23:58:58 65429 rtpproxy[24207]: INFO:handle_command: new
session on a port 53876 created, tag
907ba9691f6a47f3bfb0bb4143ef7dc7;1
May 11 23:58:58 65429 rtpproxy[24207]: INFO:handle_command:
pre-filling caller's address with 182.16.156.25:4002
May 11 23:58:58 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27802_13 53876 64.120.57.111#012"
May 11 23:58:59 65429 rtpproxy[24207]: DBUG:get_command: received
command "27803_10 LZ80c18 008e2697e52a4adda7be16358b318def
85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1
6611E63499885;1"
May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: lookup on
ports 53876/42866, session timer restarted
May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command:
pre-filling callee's address with 85.13.205.178:26728
May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: RTP
packets from callee will be resized to 80 milliseconds
May 11 23:58:59 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27803_10 42866 64.120.57.111#012"
May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: callee's
address filled in: 85.13.217.158:26728 (RTP)
May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: guessing
RTCP port for callee to be 26729
May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: caller's
address latched in: 182.16.156.25:4003 (RTCP)
May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: caller's
address filled in: 182.16.156.25:1036 (RTP)
May 11 23:58:59 65429 rtpproxy[24207]: DBUG:get_command: received
command "27801_10 LZ80c18 008e2697e52a4adda7be16358b318def
85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1
6611E63499885;1"
May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: lookup on
ports 53876/42866, session timer restarted
May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: RTP
packets from callee will be resized to 80 milliseconds
May 11 23:58:59 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27801_10 42866 64.120.57.111#012"
May 11 23:59:00 65429 rtpproxy[24207]: DBUG:get_command: received
command "27802_14 LZ80c18 008e2697e52a4adda7be16358b318def
85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1
6611E63499885;1"
May 11 23:59:00 65429 rtpproxy[24207]: INFO:handle_command: lookup on
ports 53876/42866, session timer restarted
May 11 23:59:00 65429 rtpproxy[24207]: INFO:handle_command: RTP
packets from callee will be resized to 80 milliseconds
May 11 23:59:00 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27802_14 42866 64.120.57.111#012"
May 11 23:59:02 65429 rtpproxy[24207]: DBUG:get_command: received
command "27800_13 LZ80c18 008e2697e52a4adda7be16358b318def
85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1
6611E63499885;1"
May 11 23:59:02 65429 rtpproxy[24207]: INFO:handle_command: lookup on
ports 53876/42866, session timer restarted
May 11 23:59:02 65429 rtpproxy[24207]: INFO:handle_command: RTP
packets from callee will be resized to 80 milliseconds
May 11 23:59:02 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27800_13 42866 64.120.57.111#012"
May 11 23:59:06 65429 rtpproxy[24207]: DBUG:get_command: received
command "27801_11 LZ80c18 008e2697e52a4adda7be16358b318def
85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1
6611E63499885;1"
May 11 23:59:06 65429 rtpproxy[24207]: INFO:handle_command: lookup on
ports 53876/42866, session timer restarted
May 11 23:59:06 65429 rtpproxy[24207]: INFO:handle_command: RTP
packets from callee will be resized to 80 milliseconds
May 11 23:59:06 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27801_11 42866 64.120.57.111#012"
May 11 23:59:10 65429 rtpproxy[24207]: DBUG:get_command: received
command "27802_15 LZ80c18 008e2697e52a4adda7be16358b318def
85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1
6611E63499885;1"
May 11 23:59:10 65429 rtpproxy[24207]: INFO:handle_command: lookup on
ports 53876/42866, session timer restarted
May 11 23:59:10 65429 rtpproxy[24207]: INFO:handle_command: RTP
packets from callee will be resized to 80 milliseconds
May 11 23:59:10 65429 rtpproxy[24207]: DBUG:doreply: sending reply
"27802_15 42866 64.120.57.111#012"
May 11 23:59:20 65429 rtpproxy[24207]: INFO:rxmit_packets: callee's
address latched in: 85.13.217.158:26728 (RTP)
I don't what is going wrong here, but somehow rtpproxy is not relaying
the packets from callee's end.
But the addresses seems fine and whenever i remove the "z80" inside
rtpproxy_answer(), It works fine.
At first i thought its just that the resizer is broken. But when the
ivr is played, the rtppackets of the ivr works just fine.
--
-Cheers
-Arif
I have this setup for kamailio + asterisk, in which kamailio is supposed to listen on all ethernet interfaces on UDP port 5060, and will forward traffic from/to asterisk running on the same machine, and listening on localhost, udp port 5080. The scenario
for the problematic call is somewhat like this:
SIP-PROVIDER<--->NAT<--192.168.0.0/16-->eth0:192.168.10.10<--KAMAILIO-->127.0.0.1<--ASTERISK
Our firewall/NAT has been configured to redirect SIP traffic from the SIP provider to the kamailio+asterisk machine at IP 192.168.10.10. The attached file sip-traffic-from-eth0.txt shows a tcpdump capture of an incoming call at eth0. Then, kamailio is
supposed to redirect this traffic to asterisk. The attached file sip-traffic-from-localhost.txt shows a tcpdump capture of the same call at 127.0.0.1. The issue is that the INVITE is received, then routed to asterisk, which sends back the 200 OK, but then
there is no ACK from the SIP provider. From the point of view of the caller of the SIP provider, the destination just keeps ringing until timeout.
Am I right in assuming that the two Record-Route headers should not appear on the traffic as seen from eth0, and that they are the source of the trouble? Can you see any additional issues I might have not seen in the traffic?
How do I configure kamailio to listen to multiple ports, on all known interfaces?
I have tried "listen=udp:*:5060", "listen=udp:*:5062" on separate lines, but I get the following errors:
Not starting : invalid configuration file!
0(7806) : <core> [cfg.y:3411]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 190, column 12: syntax error
0(7806) : <core> [cfg.y:3411]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 190, column 12: ip address, interface name or hostname expected
0(7806) : <core> [cfg.y:3411]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 190, column 13:
ERROR: bad config file (3 errors)
I have also tried "port=5060", then "port=5062" on separate lines, but kamailio only listens on the port indicated by the last line.
I do not want to have to enumerate every single interface on the configuration file.
Hello,
I would like to ask what exactly means route(RELAY)? I don't found some
declaration of it. I{ found it in many method before exit;
I think its probably last handle of SIP message, am I right?
Thank you
Patrik
Hello all,
I trying to debug Errorwith mi_fifo an d I found out that file
kamailio_fifo is missing from the directory /tmp, also I not found it in my
Debian by locate command. I have correctly following lines in my conf files:
in kamailio.cfg:
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")
in kamctlrc:
OSER_FIFO="/tmp/kamailio_fifo"
So, I dont know, it maybe my mysql crashed?
Thank you for you help!
Patrik
Hi,
I'm using kamailio as a load balancer to dispatch to 5 asterisk Media
gateways with pjsip Stack
The old asterisk sip Stack is turned off.
hier my asterisk pjsip.conf to trust kamailios IP Addr.
pjsip.conf
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
tos=cs3
cos=3
[kamailio]
type=endpoint
context=outgoing-kamailio
disallow=all
allow=g722,alaw,ulaw
transport=transport-udp
direct_media=no
disable_direct_media_on_nat=yes
aors=kamailio
[kamailio]
type=aor
qualify_frequency=60
[kamailio]
type=identify
endpoint=kamailio
match=[IP-Addr-of-your-kamailio]
extensions.conf
exten => _XXXX.,1,Dial(PJSIP/${EXTEN}@trunkprofil)
od
exten => _XXXX.,1,Dial(PJSIP/trunkprofil/${EXTEN})
works great and pjsip is very fast !!! love it !!!
Regards
Rainer
--
*Rainer Piper*
Integration engineer
Koeslinstr. 56
53123 BONN
GERMANY
Phone: +49 228 97167161 <callto:004922897167161>
Hello, can someone let me know how I can start Kamailio with the init
script? In the /etc/default/kamailio file I have commented
out RUN_KAMAILIO=yes, this starts Kamailio but my phones do not register.
If I stop the init script and start kamailio with kamctl then my phones
register, what am I doing wrong here?
Also, if my understanding is correct, if I start Kamailio with the init
script I should not start kamailio with kamctl, in that case how do I run
the kamctl commands, for eg like kamctl ul show ?
Thanks for the help.
Arun
Hello,
can you enable query log in mysql and verify if they happen in such
case? I checked and for db_mode=1, it should immediately do the query.
For db_mode=3, th queries are done on time.
Also, is there any other application that could potentially delete
records? Because after the first registration of a phone (which does an
INSERT), there will be UPDATE queries, and if the record is not there,
there is nothing to update.
Look at usrloc module parameters, there are some parameters to try to do
insert if the update doesn't affect records, you can try with this one
to see if there is a difference.
Cheers,
Daniel
On 08/05/14 18:20, Henry Fernandes wrote:
> There are no errors in the log about this.
>
> Yesterday, I tried db_mode=2 (with default 'timer_interval' of 60 seconds) and it's better now, although still not working properly. There are still some records that are not in the 'location' table in the database.
>
> For example, I have a phone that has a registration expirations are set to 1 hour (3600 seconds). Currently, this record is not in the database however "kamctl ul show" shows the following:
>
> AOR:: phoneUsername
> Contact:: sip:phoneUsername@a.b.c.d:62544 Q=
> Expires:: 3123
> Callid:: f1e0aa72-eb0d28e2-c3737132(a)10.1.0.14
> Cseq:: 52
> User-agent:: PolycomVVX-VVX_500-UA/4.1.6.4835
> State:: CS_SYNC
> Flags:: 0
> Cflag:: 0
> Socket:: udp:a.b.c.d:5060
> Methods:: 8159
> Ruid:: uloc-536a9e57-3137-2
> Reg-Id:: 0
>
> In other words, it's been more than 60 seconds but the database is not up to date. This is similar to what I see with db_mode=1. In that case, the database is often missing more than 50% of the registered phones.
>
> Here are the parameters I'm using for the USRLOC module.
>
> modparam("usrloc", "db_url", WRITE_DBURL)
> modparam("usrloc", "db_mode", 2)
> modparam("usrloc", "use_domain", 0)
>
> -H
>
>
> On 2014-05-08, at 1:00 AM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
>
>> Hello,
>>
>> any db_mode>0 in 3.3 is safe for not losing registrations upon kamailio restart (e.g., db_mode=2 writes to db on time and at shutdown, so nothing is lost as well). db_mode=1 should do that in realtime, indeed.
>>
>> I'm not aware of any issue with db_mode=1, being used in quite some deployments. Can you check the syslog to see if there is any error reported there?
>>
>> If you use mysql, then you can enable logging the queries and then check if for each registration there is a mysql query to insert/update/delete a record.
>>
>> Cheers,
>> Daniel
>>
>> On 08/05/14 00:08, Henry Fernandes wrote:
>>> I'm using Kamailio 3.3 and the USRLOC module to track registrations. I have set "db_mode" to 1 because I want to store all registration info to the database and I want the database to be up to date (in case I need to restart Kamailio).
>>>
>>> Unfortunately, this doesn't work as I expect. When I query the database, it has far fewer entries in the "location" table than are registered to Kamailio (which I find with a "kamctl ul show"). Also, when I restart Kamailio, I lose some of the registrations for my phones.
>>>
>>> Am I misunderstanding the behaviour for db_mode=1? Isn't it supposed to keep the database up to date?
>>> -H
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hi,
I am a student in Programming, I develop for project of the end of study
a sip phone(Swing application). I use Sip Jain api. I installed kamailio in
Ubuntu Server 14.04 using this command : apt-get install kamailio*. Now, I
don't know what to do to configure this server like a registrar and I would
like use the presence module. Please help me, I need it.
Thanks
Hamza Jaafar