Hi guys,
on our enviromet we have 130+ gateway configured over the LCR_gw tables.
when we try to reload it.. we get error..
"Aug 28 09:40:36 vm-nextaitz-02 /usr/sbin/kamailio[3800]: ERROR: lcr
[lcr_mod.c:1511]: reload_tables(): too many gateways"
We reached some top values.. how can we modify it ?
Regards
Hi ppl,
The problem I'm facing is that function *ds_is_from_list* seems to return
false when a gateway's address is a FQDN that resolves into multiple IP
addresses (I'm talking about A records), consequently in-dialog requests
like BYE and re-Invites get blocked since they don't pass the
*ds_is_from_list* validation.
Am I missing some parameter or something?
Thanks,
--Sergiu
Hello,
just discovered what I consider to be an inconsistency in naming and
behaviour for event_route blocks for local-request and local-response
and starting a discussion here to see how to move on.
The event_route[tm:local-request] is executed before sending there local
generated request out (allowing also to change its content, drop,
etc...). This event route is quite popular event route used when the
local generated requests need to be checked or updates.
The event_route[tm:local-response] is executed after the response is
sent out, obviously no possibility to change anymore the content. I
haven't checked the code for event_route[sl:local-response], but based
on commit message should be the same.
I haven't used the local-response so far at all, today after a
discussion on sr-users I wanted to enable kemi callback for
tm:local-response and I noticed that behaviour in the code, even I
expected to be like local-request (before sending out).
I am not sure how much used are the event routes for tm:local-response
and sl:local-response, I haven't seen any questions about them so far on
mailing lists, that's why I am asking here if would make sense to rename
them like tm:local-response-sent and sl:local-response-sent to properly
reflect when they are executed. I am expecting that they are very few
used so far, so no big head ache with upgrades and bringing some
consistency around (this change to be part of next major release).
It can stay like now with proper documentation, however in the future if
one want and event route for local responses before being sent out,
there will be more confusion, imo ...
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hi,
I installed Kamailio SIP server:
Following article:
https://github.com/open5gs/nextepc/blob/master/docs/_docs/guide/04-setting-…
By following step # 12 (as per above article) when we initiate the call we
get - Too many hops 483
Created two user earlier:
$ kamctl add test testpasswd
$ kamctl add test2 testpasswd
syslog show:
Aug 27 09:36:50 localhost /usr/sbin/kamailio[56286]: ERROR: nathelper
[nathelper.c:780]: add_contact_alias_0(): failed to get contact uri
Aug 27 09:36:50 localhost /usr/sbin/kamailio[56286]: ERROR:
ims_registrar_pcscf [save.c:268]: save_pending(): No contact headers
Aug 27 09:36:50 localhost /usr/sbin/kamailio[56275]: ERROR: <script>:
REGISTER (sip:test1@139.54.102.135 (139.54.102.135:5060) to
sip:test1@139.54.102.135, ee24f837b04b07334e25befe81217f8f(a)45.45.0.16)
Aug 27 09:36:50 localhost /usr/sbin/kamailio[56275]: ERROR: nathelper
[nathelper.c:780]: add_contact_alias_0(): failed to get contact uri
Aug 27 09:36:50 localhost /usr/sbin/kamailio[56275]: ERROR:
ims_registrar_pcscf [save.c:268]: save_pending(): No contact headers
Aug 27 09:36:50 localhost /usr/sbin/kamailio[56276]: ERROR: <script>:
REGISTER (sip:test1@139.54.102.135 (139.54.102.135:5060) to
sip:test1@139.54.102.135, ee24f837b04b07334e25befe81217f8f(a)45.45.0.16)
Aug 27 09:37:05 localhost /usr/sbin/kamailio[56278]: ERROR: <script>:
REGISTER (sip:test1@139.54.102.135 (45.45.0.16:42965) to
sip:test1@139.54.102.135, 04e06b6352f7a2b8f97c1a3733b3334a(a)45.45.0.16)
Aug 27 09:37:05 localhost /usr/sbin/kamailio[56278]: ERROR:
ims_registrar_pcscf [save.c:339]: save_pending(): Will save pending contact
without security parameters
Aug 27 09:37:05 localhost /usr/sbin/kamailio[56374]: ERROR: <script>:
Diameter: AAR failed on subscription to signalling
Server IP 139.54.102.135 where Kamailio is installed, UE IP address
45.45.0.16, 45.45.0.1
Followed this
https://www.kamailio.org/wiki/tutorials/faq/main#why_the_sip_requests_are_r…
Thought to test using SIPp - installed and ran default command: ./sipp –sn
uac 127.0.0.1 and ./sipp –sn uac 139.54.102.135
Aug 27 08:51:32 localhost /usr/sbin/kamailio[56295]: ERROR: <script>:
INVITE (sip:sipp@139.54.102.135:5061 (139.54.102.135:5061) to
sip:service@139.54.102.135:5060, 2-60232(a)139.54.102.135)
Aug 27 08:51:32 localhost /usr/sbin/kamailio[56295]: ERROR: ims_ipsec_pcscf
[cmd.c:507]: ipsec_forward(): Contact doesn't exist
The user sipp and service does'nt exist
Added user:
kamctl add sipp testpasswd
kamctl add service testpasswd
Still same error:
Aug 27 10:52:17 localhost /usr/sbin/kamailio[56289]: ERROR: ims_ipsec_pcscf
[cmd.c:507]: ipsec_forward(): Contact doesn't exist
Aug 27 10:52:17 localhost /usr/sbin/kamailio[56284]: ERROR: <script>:
INVITE (sip:sipp@139.54.102.135:5061 (139.54.102.135:5061) to
sip:service@139.54.102.135:5060, 977-61357(a)139.54.102.135)
Please advise.
Thanks and Regards.
hi
i m using kamailio 5.1,,, on ubuntu 18.4
installed form source ....
after few days it stop registering client to kamailio.... it resolved after
restart service ... same after few day
loges ----
---------------------
kamailio.service - LSB: Start the Kamailio SIP proxy server
Loaded: loaded (/etc/init.d/kamailio; generated)
Active: active (exited) since Wed 2019-08-21 08:07:44 UTC; 5 days ago
Docs: man:systemd-sysv-generator(8)
Process: 1936 ExecStart=/etc/init.d/kamailio start (code=exited,
status=0/SUCCESS)
Aug 21 08:07:44 talk /usr/local/sbin/kamailio[1969]: INFO: <core>
[core/cfg/cfg_ctx.c:595]: cfg_set_now(): tls.low_mem_threshold2 has been
changed to
Aug 21 08:07:44 talk /usr/local/sbin/kamailio[1969]: INFO: <core>
[main.c:2636]: main(): processes (at least): 27 - shm size: 67108864 - pkg
size: 838
Aug 21 08:07:44 talk /usr/local/sbin/kamailio[1969]: ERROR: dispatcher
[dispatcher.c:813]: ds_warn_fixup(): failover functions used, but required
AVP
Aug 21 08:07:44 talk /usr/local/sbin/kamailio[1969]: INFO: <core>
[core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially
212992
Aug 21 08:07:44 talk /usr/local/sbin/kamailio[1969]: INFO: <core>
[core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally
425984
Aug 21 08:07:44 talk /usr/local/sbin/kamailio[1969]: ERROR: <core>
[core/tcp_main.c:2850]: tcp_init(): bind(c, 0x7fbabac2c1f4, 16) on
172.31.35.49:509
Aug 21 08:07:44 talk /usr/local/sbin/kamailio[1969]: INFO: <core>
[core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
Aug 21 08:07:44 talk kamailio[1936]: * already running
Aug 21 08:07:44 talk kamailio[1936]: ...done.
Aug 21 08:07:44 talk systemd[1]: Started LSB: Start the Kamailio SIP proxy
server.
plz help
thank you
--
*Regards:*
Gaurav Kumar
(moved the discussion to user list)
Hello Salah,
I see the this output in the log message:
6(26) INFO: <script>: on_reply_route [SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.32.0.6;rport=5060;received=172.32.0.6;branch=z9hG4bKe68a.99dc492fe74dcfe1017828521a5fa362.0
2(22) INFO: <script>: on_reply_route [SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.32.0.6;rport=5060;received=172.32.0.6;branch=z9hG4bK178a.79cddb135aabfc42736fd9e9fd826ba8.0
and so on.. So you are seeing the replies correctly, or I wrong?
Cheers,
Henning
Am 22.08.19 um 21:29 schrieb Salah Ahmed:
Hello Henning,
We already added xlog in the onreply_route and found all messages in between kamailio and UAS. The attached log files in first email has those logs. If any other specific log needed I am here to provide them.
Thanks,
Salah
On Thu, Aug 22, 2019 at 2:24 PM Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> wrote:
Hello Salah,
ok, see if you are able to output some easy log with "xlog" in this route, to make sure there is no cfg problem somewhere.
Cheers,
Henning
Am 22.08.19 um 21:15 schrieb Salah Ahmed:
Hello Henning,
Thanks for quick reply, We armed the t_on_reply just before t_relay() in the route block.
t_on_reply("LOGRPL");
if (!t_relay()) {
sl_reply_error();
}
Thanks,
Salah
On Thu, Aug 22, 2019 at 2:03 PM Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> wrote:
Hello Salah,
the replies are going from the UAS to the UAC over Kamailo as a proxy, with the exception of the hop-by-hop 100.
So you should see the 200 OK in the Kamailio in reply_route and onreply_route. Maybe you can check if you armed the onreply_route with t_on_reply for the INVITE routing.
Cheers,
Henning
Am 22.08.19 um 19:50 schrieb Salah Ahmed:
Hello,
We facing an issue on capturing sip message in Kamailio(Version: 5.2.3). The scenario is very simple.
UAC Kamailio UAS
|--------INVITE--------->| |
| |-------INVITE------->|
| |<------100 Trying----|
|<-------100 Trying------| |
| |<------200 Ok--------|
|<-------200 Ok----------| |
In this simple scenario, we can't catch any reply messages in between the Kamailio and UAC. We have tried reply_route, onreply_route, and onsend_route. But no one work to grep that reply on that side. onsend_route was bad try as its only for forwarded reply message. Is there any other magic to capture those replies. A debug=3 log message attached here.
Thanks,
Salah
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev(a)lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
in my kamailio-asterisk integration i have a exit after the authentication
logic, BUT; there's another conditional after the "exit" sentence,
so my ask, if there's a exit in that piece of code .. that next conditional
will not be executed?
Docs seems said "stop execution of script" so all the rest of the logic in
file will not be routed?
The documentation seems does not explain in good behavior what happened or
the kamailio-asterisk wiki page does not have good explanations for that!
it's that an error?
https://www.kamailio.org/wiki/cookbooks/4.3.x/core#exit
-
-
```
if (from_uri==myself)
{#!ifdef WITH_ASTERISK
if (!proxy_authorize("$fd", "sipusers")) {#!else
if (!proxy_authorize("$fd", "subscriber")) {#!endif
proxy_challenge("$fd", "0");
exit;
}
if (is_method("PUBLISH"))
{
if ($au!=$tU) {
sl_send_reply("403","Forbidden auth ID");
exit;
}
} else {
if ($au!=$fU) {
sl_send_reply("403","Forbidden auth ID");
exit;
}
}
consume_credentials();
# caller authenticated
} else {
# caller is not local subscriber, then check if it calls
# a local destination, otherwise deny, not an open relay here
if (!uri==myself)
{
sl_send_reply("403","Not relaying");
exit;
}
}
}
#!endif
return;
}
```
8:52 am
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
Hello,
I have been having an issue using kamailio to load balance to a SIP/MRCP server. I believe that the issue actually lies with the reply being sent from the final recipient, but I wanted to be sure that I understood the problem and to see if there were any possible solutions within Kamailio.
I am using the dispatcher module to dispatch SIP INVITES to media resources, in this case I am just using a single host in a single dispatcher group. The configuration that I have has worked just fine for other SIP/MRCP servers, which is why I think the issue is with this target in particular.
The INVITE is routed correctly and contains the headers that it should. The invite comes originally from a Freeswitch, arrives at Kamailio, who should then dispatch to a host in the group.
x.x.x.x:4901 is Kamailio
x.x.x.x:8090 is Freeswitch
y.y.y.y:8000 is the final target
This is the invite, as received by the final target after dispatched via Kamailio
INVITE sip: x.x.x.x:4901 SIP/2.0
Record-Route: <sip: x.x.x.x:4901;transport=tcp;lr>
Via: SIP/2.0/TCP x.x.x.x:4901;branch=z9hG4bK3a9a.7f9a4b588cd75108cfea9a2bd9ffa829.0;i=3
Via: SIP/2.0/TCP x.x.x.x:8090;branch=z9hG4bKStXp06Sv7jU7S
Max-Forwards: 69
From: <sip: x.x.x.x:8090>;tag=4gHgNcNUDjvFQ
To: <sip: x.x.x.x:4901>
Call-ID: 6f2a0e9c-3f9e-1238-2aa9-005056854777
CSeq: 8692231 INVITE
User-Agent: tts
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 281
v=0
o=IPSoft 3367790083977298880 2789991278648035021 IN IP4 x.x.x.x
s=-
c=IN IP4 x.x.x.x
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=audio 32038 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
a=mid:1
The reply that the server sends back appears to be missing a second Via header, which is preventing Kamailio for routing it correctly (based on the error message from core/forward.c)
This is the reply sent by the target destination
SIP/2.0 200 OK
Via: SIP/2.0/TCP x.x.x.x:8090;branch=z9hG4bKStXp06Sv7jU7S
To: <sip: x.x.x.x:4901>;tag=ndszib3k
From: <sip: x.x.x.x:8090>;tag=4gHgNcNUDjvFQ
Call-ID: 6f2a0e9c-3f9e-1238-2aa9-005056854777
CSeq: 8692231 INVITE
Contact: "Voiceware MRCP Server" <sip:vwmrcp@ y.y.y.y:8000;transport=tcp>
Content-Type: application/sdp
Content-Length: 324
v=0
o=- 1566492047 1566492047 IN IP4 y.y.y.y
s=Voiceware MRCP Server 2.15.0.7. Dec 28 2018
c=IN IP4 y.y.y.y
t=0 0
m=application 8002 TCP/MRCPv2 1
a=channel:12951125463@speechsynth
a=connection:new
a=setup:passive
a=cmid:1
m=audio 30158 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=sendonly
a=ptime:20
a=mid:1
It is correct that there should still be a 2nd Via header in the 200 OK reply from the target host, right?
If so, is there anything else that can be done in Kamailio to handle this, or is this mrcp server simply not complying properly with SIP?
There’s no funky natting between these hosts or anything like that.
Thanks in advance!
When set_rtpengine_set() is called with two parameters before
rtpengine_offer(), e.g.
set_rtpengine_set("1", "2");
rtpengine_offer();
it was not clear to me from rtpengine README, if the sets need to
reversed when set_rtpengine_set() is called before rtpengine_answer(),
i.e.,
set_rtpengine_set("2", "1");
rtpengine_answer();
or can the order of the sets be the same as it was in case of
rtpengine_offer()?
-- Juha