Hello Everyone,
I have successfully setup a VM in OpenStack with Kamailio IMS, rtpengine
and FoHSS using the instructions mentioned in the guide which i wrote
(attached to this mail), all running in the machine. I am using the
existing alice and bob IMPUs created in FoHSS. But, when I try to call each
other the call doesnt go through and I observe in the wireshark traces that
S-CSCF is replying to I-CSCF that "403, Forbidden - Domain not served".
Can somebody please tell me do I need any additional components to make a
call or am i missing some configuration? It would be great if someone can
help me troubleshooting this issue.
I have attached the pcap file for your reference.
Many thanks in advance.
Regards,
Supreeth
I'm returning to an old issue, where Kamailio stops processing incoming
requests.
Now it turned out that only requests over UDP are not processed.
Requests over TCP work fine. Debug log doesn't show anything about the
requests over UDP, but wireshark sees them coming. core.ps shows that
main process - attendant and all udp receiver processes are alive.
Any ideas what could cause Kamailio (5.2 version) to stop processing
requests over UDP? What additional info should I try to get?
-- Juha
I recently did the upgrade from v4.4 to 5.2 (via Yum).
When starting Kamailio, I get these three errors. Not sure if they are
related or not but I do not think so.
Have spent a lot of time searching on Google for the answer and have not
found the solution.
[root@ids kamailio]# kamctl restart
INFO: Stopping Kamailio :
INFO: stopped
INFO: Starting Kamailio :
INFO: started (pid: 44608)
[root@ids kamailio]# tail -f /var/log/sipserver.log
Sep 4 00:39:06 ids /usr/sbin/kamailio[44608]: ERROR: <core>
[core/pvapi.c:1119]: pv_parse_spec2(): wrong char [t/116] in [$mt] at [2
(0)]
Sep 4 00:39:06 ids /usr/sbin/kamailio[44608]: ERROR: <core>
[core/dprint.c:451]: log_prefix_init(): wrong format[{$mt $hdr(CSeq) $ci} ]
Sep 4 00:39:06 ids /usr/sbin/kamailio[44626]: ERROR: <core>
[core/receive.c:319]: receive_msg(): no request_route {...} and no other
config routing engine registered
The last error is repeated many times (each time a remote user tries to
connect I think).
I can send any additional files if needed.
Thanks. I am burning out on this upgrade.
Kevin
Hi,
I am running 4.3.5:1b0c0a, which I am aware is an EOL'd release train,
and have a problem with the dialog module I am baffled by.
On many calls - I can't find any correlation to particular kinds of
endpoints - I see spoofed BYEs come out of Kamailio after a minute and a
half, as if the call had hit a dialog timeout or the dialog module's
dead peer detection (OPTIONS pinging) kicked it out.
The thing is, neither of those explanations seem to be borne out by the
parameters of the calls under investigation. The dialog timeout on these
calls is set to 7200, and the dialog keepalives aren't enabled in either
direction. If they were, it'd be logged.
Calls that are terminated in this manner also see the following log
message:
WARNING: dialog [dlg_req_within.c:214]: bye_reply_cb(): inconsitent
dlg timer data on dlg 0x7f9997317e48 [3390:9644] with clid
'1996679936_133218050(a)x.x.x.x' and tags '2bb17663-co4006-INS001' 'as7925780d'
But I don't think this is unusual for a dialog-spoofed BYE; presumably
this is due to a 200 OK for the BYE from both ends.
So anyway, I am trying to track down anything else that could
inadvertently cause dialog to hang up calls relatively quickly in that
release, or inadvertently set the dialog timeout parameter to something
lower than is apparent from the logging and the config.
If anyone has any pointers, that would not go unappreciated!
Many 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/
Hi All
Installed Kam 5.2.4, but now getting version mismatch on evapi.
ERROR: <core> [core/sr_module.c:348]: version_control(): module version
mismatch for /usr/lib64/kamailio/modules/evapi.so; core: kamailio 5.2.4
(x86_64/linux); module: kamailio 5.1.6 (x86_64/linux)
Anybody know how to get the correct evapi version. I am running centos 7
Bill
Greetings,
I have a Kamailio proxy with uac_replace for To and From Headers. So far
everything has worked correctly.
However, I now have a client who encodes my Calling Number too and I'm
getting some issues in the restore mechanics. I have the restore setup as
"auto" and it's info is stored in "vsf" and "vst" parameters of
Record-Route.
On replies sent by my client I have the following Record-Route and From
Header (Note : My Kamailio has two IPs which makes it insert two RR headers
):
Record-Route:
<sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_
o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH
DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>
Record-Route:
<sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_
o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH
DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>
From: "+351411110097"
<sip:I2116446I_500@xxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4
In this case the restore is done correctly
When the client sends me a BYE request I have the following Route Header and
To Header
Route :
<sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_
o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH
DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>,<sip:xxx.xxx.xxx.
xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_o=128_11_Y;vsf=AA
AAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcH
wIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>
To : "+351411110097"
<sip:I2116446I_500@xxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4
In this scenario, the To after restore is : To :"+351411110097"
<sip:Q4525417L_<>Gxxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4, which
throws an internal error on Kamailio about bad URI and also makes our
MediaGateway reply with a "Bad Request".
Can this error be caused by the restore of the uac_replace mechanics? Both
Record Route URIs are on different headers while the both Route URIs are on
the same Route header. Can this be the reason?
If you need more information please let me know.
Best Regards
David Costa
