Hi,
I have still the problem that my htables are not written into a sqlite
db when I shutdown kamailio.
Manual writing via:
kamcmd htable.store ...
is working.
As I can see in the logs with highest loglevel, the function destroy()
is never called.
ht_db_url.len is > 0
ht_db_init_con() should work, else nothing would work with the db.
But I can not see the debug messages from ht_db_open_con()
Any ideas?
Best regards,
Bernd
Hello!
I noticed that there are differences in the DMQ htable replication protocol
for the old version of Kamailio 5.2 and the new 5.7.
For example, the new version uses action 2 when updating values and action
4 to remove.
The old Kamailio version uses the values 1 and 3 respectively.
Well, as a result, the htable data is not shared between such nodes, plus
there are errors in the syslog of the old version:
ERROR: htable [ht_dmq.c:328]: ht_dmq_handle_msg(): failed to replay action
It would probably be worth introducing some kind of DMQ htable protocol
versioning to maintain compatibility?
And is there any option to make them work together (I wouldn’t really want
to change the action number in sip/sdp/json on the fly)?
Kamialio 5.2
{"action":1,"htname":"shared","cname":"user","type":2,"strval":"uri","mode":1}
{"action":3,"htname":"shared","cname":"user","mode":0}
Kamailio 5.7
{"action":2,"htname":"shared","cname":"user","type":2,"strval":"uri","mode":1}
{"action":4,"htname":"shared","cname":"user","mode":0}
--
BR,
Denys Pozniak
Hello!
My topology is like this:
PBX -> Kamailio Topos -> User
When calling the user, PBX does not add the user part in the Contact URI,
something like:
Contact: <sip:10.10.10.10:5080;transport=udp>
When the customer sends a reinvite, the topos turns off for this
transaction and the sip partially breaks down with error:
topos [tps_storage.c:319]: tps_storage_fill_contact(): no r-uri user
topos [tps_storage.c:615]: tps_storage_record(): failed to store
As far as I understand, the RFC allows the absence of the user part in the
URI and this occurs quite often.
I can provide the pcap file and debug log in a private message if this
helps identify the essence of the problem.
# kamailio -v
version: kamailio 5.7.1 (x86_64/linux) 1cf389-dirty
--
BR,
Denys Pozniak
Hi,
I am planning to upgrade Kamailio to version 5.7.3 to manage some memory
leaks issues.
I am installing from source and came across these warnings, just wanted to
be sure if they are safe to be ignored.
cr_func.c: In function ‘set_next_domain_on_rule’:
cr_func.c:160:2: warning: missing braces around initializer
[-Wmissing-braces]
pv_value_t val = {0};
^
cr_func.c:160:2: warning: (near initialization for ‘val.rs’)
[-Wmissing-braces]
cr_func.c: In function ‘actually_rewrite’:
cr_func.c:348:2: warning: missing braces around initializer
[-Wmissing-braces]
pv_value_t val = {0};
^
cr_func.c:348:2: warning: (near initialization for ‘val.rs’)
[-Wmissing-braces]
cr_func.c: In function ‘ki_cr_load_user_carrier_helper’:
cr_func.c:782:2: warning: missing braces around initializer
[-Wmissing-braces]
pv_value_t val = {0};
^
--
LD (gcc) [M p_usrloc.so] p_usrloc.so
CC (gcc) [M evrexec.so] evrexec_mod.o
evrexec_mod.c:64:1: warning: missing braces around initializer
[-Wmissing-braces]
static evrexec_info_t _evrexec_info = {0};
^
evrexec_mod.c:64:1: warning: (near initialization for ‘_evrexec_info.data’)
[-Wmissing-braces]
LD (gcc) [M evrexec.so] evrexec.so
CC (gcc) [M avp.so] avp.o
LD (gcc) [M avp.so] avp.so
CC (gcc) [M acc_diameter.so] diam_message.o
CC (gcc) [M acc_diameter.so] acc_diameter_mod.o
CC (gcc) [M acc_diameter.so] diam_avp.o
CC (gcc) [M acc_diameter.so] diam_tcp.o
LD (gcc) [M acc_diameter.so] acc_diameter.so
CC (gcc) [M dmq.so] bind_dmq.o
CC (gcc) [M dmq.so] message.o
CC (gcc) [M dmq.so] dmq_funcs.o
dmq_funcs.c: In function ‘ki_dmq_send_message’:
dmq_funcs.c:304:3: warning: missing braces around initializer
[-Wmissing-braces]
dmq_peer_t new_peer = {0};
^
dmq_funcs.c:304:3: warning: (near initialization for ‘new_peer.peer_id’)
[-Wmissing-braces]
dmq_funcs.c: In function ‘ki_dmq_bcast_message’:
dmq_funcs.c:374:3: warning: missing braces around initializer
[-Wmissing-braces]
dmq_peer_t new_peer = {0};
^
dmq_funcs.c:374:3: warning: (near initialization for ‘new_peer.peer_id’)
[-Wmissing-braces]
CC (gcc) [M dmq.so] notification_peer.o
CC (gcc) [M dmq.so] dmq.o
dmq.c:61:1: warning: missing braces around initializer [-Wmissing-braces]
sip_uri_t dmq_server_uri = {0};
^
dmq.c:61:1: warning: (near initialization for ‘dmq_server_uri.user’)
[-Wmissing-braces]
dmq.c:67:1: warning: missing braces around initializer [-Wmissing-braces]
static sip_uri_t dmq_notification_uri = {0};
^
dmq.c:67:1: warning: (near initialization for ‘dmq_notification_uri.user’)
[-Wmissing-braces]
Muhammad Danish Moosa
" The core of mans' spirit comes from new experiences. "___ Christopher
McCandless
Hello,
during the Kamailio Development Meeting that took place in Dusseldorf
earlier this month, one topic was related to administrative tasks
related to project development and management, how to
simplify/automatize such tasks.
To reduce the work load on volunteering contributors, GitHub Actions
were already used for various tasks related to project development and
management (e.g., automatic builds on commits and pull requests to
detect compile errors or code formatting mistakes).
In Dusseldorf another task was configured to be managed with GitHub
Actions, respectively the check of open issues and pull requests to
evaluate the interest of submitters, developers and community users to
pursue them. If there is no activity on an issue (potential bug or
feature request) or a pull request, after 6 weeks it is marked with the
label `stale`. After two more weeks of no activity, the issue or the
pull request is marked with the label `expired` and closed. Note that
any comment postpones the expire timeline, being considered that there
is interest in pursuing the issue or the pull request.
Requests for features were already treated in this way: if nobody
commits to implement it, it can be closed after one month, but it needed
manual work and many were still kept open. Potential bug reports that
become very old are hard to tackle if the source code changes or new
major releases are out, they might even not be valid anymore.
Anyhow, this automatic operations can be reverted if there is still
interest in pursuing the specific issues or pull requests. A registered
developer can remove labels and reopen a closed issue or pull request.
The non-registered-developer contributors have to make a comment that
includes the token `/notstale` to remove the label `stale` or includes
the token `/notexpired` to reopen a closed item.
This new kind of automatic task management might add a little
inconvenience because one has to restate the interest from time to time
for those items that could not be addressed. However, considering that
Kamailio is an open source collaborative project, in order to be fair
for those that volunteer to spend time and resources for development of
Kamailio, also the users/submitters have to stay engaged, not just
report and forget about.
The process to automatize tasks related to Kamailio development and
administration is work in progress. Everything can be adjusted based on
feedback (e.g., time lines), feel free to suggest improvements or new
solutions to make things easier for everyone within the project ecosystem.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com
Hi List
Two Kamailio Nodes situation.
Node A: Routing Instance.
Node B: Registrar Instance.
An invite is sent from Node A to B.
Customer registered on B is 'busy' as example.
B initiates Call Forwarding by adding a Diversion Header and sending
the Invite back to A with a new R-URI towards the CFB destination.
The Invite sent from B to A still has Node B in it's Record-Route. So
all subsequent SIP messages pass via B, which is not needed and cause
issue with rtpengine running on B.
I attempted to remove_record_route(); when sending the call back to A,
but this causes:
parse_headers(): bad header field [;lr;ftag=3910078620-883101371>
It looks like only the beginning of the RR header is removed leaving
back a competely broken line.
What is the propper was to remove a node from RR and Via routing?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hello All
Good Day
Here I am trying to achieve something like this
WSS to UDP Ext registartion which works well using
https://github.com/havfo/WEBRTC-to-SIP/tree/master/etc
Note here i am forwarding the registartion to asterisk pbx server and
define WSS of kamailio
Now for calls
- Webrtc - SIP calls works
- SIP - Webrtc calls not working
Here I am getting the request of the call on kamailio but kamailio send 404
not found to Asterisk PBX
Webrtc - Webrtc calls not working
Can anyone guide me on what I am doing wrong?
Thanks
Vishal P
Hello,
I'd like to know if there is a way, from Kamailio side, take the
refer-to header Kamailio receive in a REFER request and create a new
INVITE whit this data; then bridge the call between the originating user
and the new destination user.
Thank you
Regards
--
---
I'm SoCIaL, MayBe
Hello Daniel,
Thanks for the reply.
The extra dictionary is already included otherwise an error is thrown and Kamailio doesn't start.
However, i realized my mistake now and you were right. I was checking for the extra attributes in a tcpdump and on radius server and i didn't had the dictionary configured on both of them. The extra attributes are in the packet but weren't being listed.
One more question. Kamailio doesn't have a way to do a totally custom RADIUS access-request packet right?
(Sorry if this opens another thread. I usually just hit reply on the mailing list and let Outlook create the e-mail, but it usually creates another thread and i'm not sure why).
Thanks again.
Cheers,
Duarte
Hello Daniel,
Thanks for the reply.
The extra dictionary is already included otherwise an error is thrown and Kamailio doesn't start.
However, i realized my mistake now and you were right. I was checking for the extra attributes in a tcpdump and on radius server and i didn't had the dictionary configured on both of them. The extra attributes are in the packet but weren't being listed.
One more question. Kamailio doesn't have a way to do a totally custom RADIUS access-request packet right?
(Sorry if this opens another thread. I usually just hit reply on the mailing list and let Outlook create the e-mail, but it usually creates another thread and i'm not sure why).
Thanks again.
Cheers,
Duarte
