Re: [SR-Users] too long mysql table key
Daniel-Constantin Mierla writes: > > Looks like default charset is something (e.g. utf8), where one char takes > > more than 1 byte and 767 limit is exceeded. > > > > Any suggestions on how to solve this? > > > I haven't trying for UNIQUE, but it may be the same as for usual INDEX > where one can provide the length for column (prefix size to be taken in > consideration). Weird, but when I dropped kamailio db and created it again, the error disappeared. I then checked and charset is latin1, not utf8: CREATE TABLE `domain_attrs` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `did` varchar(64) NOT NULL, `name` varchar(32) NOT NULL, `type` int(10) unsigned NOT NULL, `value` varchar(255) NOT NULL, `last_modified` datetime NOT NULL DEFAULT '2000-01-01 00:00:01', PRIMARY KEY (`id`), UNIQUE KEY `domain_attrs_idx` (`did`,`name`,`value`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1; I still don't understand why value (and name) need to be part of the index, since lookup_domain() loads attributes based on did only. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] too long mysql table key
Daniel-Constantin Mierla writes: > As I said, I haven't added this table, nor use it, my guess was that > this constraint is to avoid having same (did,name,value) more than > once. I have used domain_attrs to store properties that are common to all users of the domain, e.g., which lcr index (= set of pstn gws) they use, but I could imagine also something with multiple values, such as which geoip countries users of the domain can place calls. > It doesn't seem to be an index for the purpose of searching. If it loads > by did, then an index on did would be recommended, however, if it loads > all records at once and just groups by did in kamailio memory, then such > index will be useful. Eventually an index on did+name would be useful > when updating the records in database. reload_tables() loads all records in domain_attrs table to memory and then adds them to hash table. There is no option for db_only operation. So I don't see a point for such a unique index and suggest that it is changed to non-unique index on did and name only. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] too long mysql table key
Daniel-Constantin Mierla writes: > I haven't used this table myself, it's coming from SER branch, but I > guess the unique constraint is for being sure there are no duplicated > values for the same did/name tuple, but more records with same did and > name. lookup_domain() adds attributes associated with did to AVPs. Sure there can be more than one AVP with the same name. Therefore I suggest removing name and value from the index. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] too long mysql table key
Juha Heinanen writes: > domain-create.sql contains this: > > CREATE TABLE `domain_attrs` ( > `id` INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL, > `did` VARCHAR(64) NOT NULL, > `name` VARCHAR(32) NOT NULL, > `type` INT UNSIGNED NOT NULL, > `value` VARCHAR(255) NOT NULL, > `last_modified` DATETIME DEFAULT '2000-01-01 00:00:01' NOT NULL, > CONSTRAINT domain_attrs_idx UNIQUE (`did`, `name`, `value`) > ); Why value needs to be part of the index? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] too long mysql table key
I tried to install kamailio mysql db on Debian Stretch. Create of domain_attrs table failed with this kind of error message: ERROR 1071 (42000) at line 26: Specified key was too long; max key length is 767 bytes domain-create.sql contains this: CREATE TABLE `domain_attrs` ( `id` INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL, `did` VARCHAR(64) NOT NULL, `name` VARCHAR(32) NOT NULL, `type` INT UNSIGNED NOT NULL, `value` VARCHAR(255) NOT NULL, `last_modified` DATETIME DEFAULT '2000-01-01 00:00:01' NOT NULL, CONSTRAINT domain_attrs_idx UNIQUE (`did`, `name`, `value`) ); Looks like default charset is something (e.g. utf8), where one char takes more than 1 byte and 767 limit is exceeded. Any suggestions on how to solve this? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] about rtpengine-[offer-answer] via-branch flag
rtpengine-offer function documentation tells this about via-branch flag: via-branch=... - Include the “branch” value of one of the “Via” headers in the request to the RTP proxy. Possible values are: “1” - use the first “Via” header; “2” - use the second “Via” header; “auto” - use the first “Via” header if this is a request, or the second one if this is a reply; “extra” - don't take the value from a header, but instead use the value of the “extra_id_pv” variable. This can be used to create one media session per branch on the RTP proxy. When sending a subsequent “delete” command to the RTP proxy, you can then stop just the session for a specific branch when passing the flag '1' or '2' in the “rtpengine_delete”, or stop all sessions for a call when not passing one of those two flags there. This is especially useful if you have serially forked call scenarios where the RTP proxy gets an “offer” command for a new branch, and then a “delete” command for the previous branch, which would otherwise delete the full call, breaking the subsequent “answer” for the new branch. Is the note about "serial forking" correct or should it be about "parallel forking" instead? In case of serial forking, it would not matter if the whole call is deleted, because a new offer would be issued for the next branch. Or perhaps I just don't understand the meaning of the note? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] dns failover and branches
If Request-URI hostpart is a domain name with more than one SRV record, it appears that each SRV destination creates its own Kamailio branch. If branch route is set before t_relay(), it is executed only on the first SRV destination. If the first SRV destination fails, Kamailio tries automatically the second one, but any branch flags set in the branch route are lost. What is the simplest way to make Kamailio preserve the stuff set in the branch route for all SRV destinations? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] dns failover and branches
Juha Heinanen writes: > If Request-URI hostpart is a domain name with more than one SRV record, > it appears that each SRV destination creates its own Kamailio branch. > If branch route is set before t_relay(), it is executed only on the > first SRV destination. If the first SRV destination fails, Kamailio > tries automatically the second one, but any branch flags set in the > branch route are lost. Is the above the intended behavior in general? It seems a bit weird that K does automatic serial forking to SRV destinations without executing the branch route set before t_relay() for each of them. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dns failover and branches
Daniel-Constantin Mierla writes: > Is the branch parameter in the top Via of the second INVITE sent out > different than for the first INVITE (last digit incremented by 1 or > so)? Thanks for your reply. Yes it is: In the first INVITE: Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.0;i=1. In the second INVITE: Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.1;i=1. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dns failover and branches
Daniel-Constantin Mierla writes: > Sounded rather simple, so I did a quick search in the code and just > pushed a patch for it -- very small, but hopefully it fixes this. If all > tests are fine for you, then you can backport as needed to stable branches. Thanks, will test and backport. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] dns failover and branches
I did more some more tests. The branch route was properly executed before INVITE to the first SRV destination was sent. The branch route set some headers, branch flags, etc. After the first SRV destination failed, INVITE was sent to the second SRV destination and the branch route was not re-executed. In the second INVITE, headers that were added in branch route were correctly preserved. However, branch flags that were set in the branch route were not preserved. As result, processing of positive reply from the second srv destination failed. This looks like a bug to me. Also branch flags that were set in the branch route before the first INVITE was sent out should have been preserved for processing of the second INVITE. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dns failover and branches
Daniel-Constantin Mierla writes: > OK, so it is creating a new branch structure. That could explain why the > branch flags from previous INVITE are not there. If it is only the > branch flags missing (and the headers changes are already propagated), I > expect to be an easy patch. I will look into it very soon if nobody else > does it meanwhile. I did more checking and looks like only branch flags are gone. In addition to adding headers and setting branch flags, branch route adds record-route params using add_rr_param calls and also those params are preserved in the second INVITE. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] why is tcp_no_connect disabled by default
Vik Killa writes: > I'm trying to understand the scenario when `tcp_no_connect` should ever be > set to `no`. > Kamailio comes with `tcp_no_connect=no` by default which means it will try > (and seemingly always fail) to create an outbound tcp connection when a > UAC's tcp connection is lost. This in-turn could start building up the tcp > write queue and can be disastrous at scale. > So why would this setting (`tcp_no_connect=no`) ever be useful? For example, if K connects to another K over TCP and the connection does not exists, it makes sense to create one. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] placing LCR Parameters in kamailio.cfg
Logeshwaran G writes: > Getting Error while executing kamailio, > > 0(16640) ERROR: lcr [lcr_mod.c:479]: mod_init(): AVP gw_uri_avp has not > been defined Read lcr/README carefully before trying to use the module. -- Juha --- 3.28. gw_uri_avp (AVP string) Internal AVP that load_gws() function uses to store information of matching gateways. There is NO default value, thus this variable must be defined in sip-router.cfg. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dns failover and branches
Daniel, After your patch, branch flags are now preserved to the second SRV destination. Thanks, -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dns failover and branches
Joel Serrano writes: > Just curious, in what version of Kamailio would this patch be implemented? > is the backport to previous versions automatic or do we have to manually > apply and build? I think backports are usually done on per need basis. So if you need this patch in some version earlier that 5.0, you can backport it. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Conference Factory URI
Nguyen Tran Nhan writes: > Thanks for your reply. For example there are 10 number in SEMS. Now, number > 01 want to create conference by sending INVITE to URI. What URI value > should use? Any value as long as your SIP proxy routes the call to a SEMS conference application, for example, by adding P-App-Name header to the request or or ;appl= param to its Request-URI. But as I mentioned, SEMS distibution has several different example conference applications and you can write your own in less than 100 lines of DSM code. This is not SEMS mailing list so it not good idea to continue this discussion here. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Conference Factory URI
Nguyen Tran Nhan writes: > I want to create conference without interact with IVR, so, trying to use > Conference Factory URI. https://tools.ietf.org/html/rfc4579#section-3.2 > > I am looking for documentation but it seems very poor documentation. Could > you please help to give more document or opensource for Conference Factory > URI. SEMS does not support Conference Factory URI I guess? Anyone can add applications to SEMS either using C++ or writing them as DSM scripts. I don't know what Conference Factory URI is, but you can activate any number of SEMS based audio conferences using whatever URI you want. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] TLS to TCP
David Villasmil writes: > I have a kamailio 4.2.8 receiving on tls and i'm trying to forward on tcp, > but AFTER the call is established, kamailio hangs the call with "SIPS > required"... Are you sure that it is K that hangs the established call? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] relationship between debian kamailio.service and kamailio.init
Could someone who knows about systemd tell, what is the relationship between deb/stretch kamailio.service and kamailio.init files? kamailio.service contains kamailio binary argument values and command to start kamailio, but kamailio.init does much more. Why do both exist? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] best practice to re-install rtpengine after jessie to stretch upgrade?
I made a test upgrade from Debian Jessie to Stretch while rtpengine 5.1.1 was running on Jessie. What is the best practice to get xt_RTPENGINE module installed in the new Stretch linux kernel, since it does not happen automatically. Should I reinstall rtpengine* packages or is there some better way? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR - too few dots/colons
Annus Fictus writes:
> on ip_addr field the value is a normal IPv4 address like 1.2.3.4
>
> The gw_uri_avp befor call next_gws is:
>
> '1|sip:|0|||253719602||5060||;transport=udp|0'
That looks fine and these are just debug messages:
> DEBUG: lcr [../../core/resolve.h:258]: str2ip(): str2ip: ERROR: too few
> dots in [253719602]
> DEBUG: lcr [../../core/resolve.h:355]: str2ip6(): str2ip6: ERROR: too
> few colons in [253719602]
The code first tries if address field (in this case 253719602) contains
an ip 4 or 6 address string and, if not, takes int from the field and
places it into addr struct:
if (s.len > 0) {
if ((ip = str2ip()) != NULL)
*addr = *ip;
else if ((ip = str2ip6()) != NULL)
*addr = *ip;
else {
str2int(, );
addr->af = AF_INET;
addr->len = 4;
addr->u.addr32[0] = u;
}
} else {
addr->af = 0;
}
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Encryption of voice stream
Vasan VS writes: > Kindly let us know if we can have a mechanism to have the voice stream in > using the SIP server completely encrypted as well as prove that it is > encrypted using any speific mechanism. Better to use ZRTP for end-to-end encryption. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] SQL for ordered LCR rules
Patrick Wakano writes: > I am trying to ease the management of LCR routing rules, since once we > begin to have multiple prefixes, multiple GWs and so on, the visualization > and management of the rules priorities becomes exponentially hard to > do. I have written a simple web based interface for LCR configuration. I have a Routing page with these kind of rows: Callee Prefix Caller URI Regex Stop When I on that page click a Callee Prefix, I get to Gateways page of that prefix, where I have rows: Gateway Priority Weight And when I on that page click a Gateway, I get to a page where all kinds of inbound and outbound properties of that gw can be configured. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sql_do_query_async(): the db driver module doesn't support async query
Daniel Tryba writes: > Are you really using mysql directly? For example the cluster driver > doesn't support async, regardless of the backend driver support. I re-checked, and, yes, I was using cluster driver. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Simultaneous calls in kamailio
You can use, for example, sipp tool to generate simultaneous calls. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sql_do_query_async(): the db driver module doesn't support async query
Daniel Tryba writes: > Our solution was to switch to the mysql driver in kamailio and use the > galera loadbalancer > (http://galeracluster.com/documentation-webpages/glb.html) to implement > loadbalancing/failover to our mariadb galera master/master cluster. Thanks for the tip, -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Doubt in Lcr_table
Logeshwaran G writes: > May I know the Difference between the "prefix" column in Lcr_gw table and > lcr_rule table. From README: Name of the column holding prefix of Request-URI user part and prefix of gateway. I'll add names of tables to the above. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] lcr gws
Logeshwaran G writes:
> But the issue is not fixed for the below one:
>
> [root@zeodialer ~]# kamcmd lcr.dump_rules
> {
> lcr_id: 1
> rule_id: 1
> prefix: 91
> from_uri:
> request_uri:
> stopper: 1
> }
> {
> gw_index: 1
> priority: 1
> weight: 1
> }
> {
> lcr_id: 1
> rule_id: 4
> prefix: 00091
> from_uri:
> request_uri:
> stopper: 1
> }
> {
> gw_index: 1
> priority: 1
> weight: 1
> }
>
>
>
> *52**Why these two numbers are 5 and 2 are displaying in the output?
What do you mean by 5 and 2? I don't see those in the above.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] last pkg.stats entry
When I make pkg.stats query (latest master), I get a weird last entry.
What is it?
-- Juha
...
{
entry: 28
pid: 14675
rank: -4
used: 9450336
free: 2354944
real_used: 10227968
total_size: 12582912
total_frags: 310
}
{
entry: 29
pid: 0
rank: -128
used: 0
free: 0
real_used: 0
total_size: 12582912
total_frags: 0
}
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] last pkg.stats entry
Daniel-Constantin Mierla writes: > Should be fixed now in master -- secondary timer was counted twice, > resulting in an extra entry in process table that was not filled > (overall harmless, just empty content) -- I will backport in 5.0 as > well. Thanks for the fix. Tested and extra entry is gone. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sql_do_query_async(): the db driver module doesn't support async query
Daniel Tryba writes: > Our solution was to switch to the mysql driver in kamailio and use the > galera loadbalancer > (http://galeracluster.com/documentation-webpages/glb.html) to implement > loadbalancing/failover to our mariadb galera master/master cluster. In this solution, also loadbalancer must be made highly available, using, for example, corosync/pacemaker. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sql_do_query_async(): the db driver module doesn't support async query
Juha Heinanen writes: > > Our solution was to switch to the mysql driver in kamailio and use the > > galera loadbalancer > > (http://galeracluster.com/documentation-webpages/glb.html) to implement > > loadbalancing/failover to our mariadb galera master/master cluster. > > In this solution, also loadbalancer must be made highly available, > using, for example, corosync/pacemaker. Or run loadbalancer on each SIP proxy host. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] lcr_id vs lcr_count
Patrick Wakano writes: > I aggre with the lcr_count purpose and its usage for in-memory data. > However the problem I mentioned is that I cannot have an lcr_id of 1000 > eventough I have only one entry because my lcr_count is 50... > It is not about having a huge amount of lcr_ids but being able to have id > numbers greater than the lcr_count, which is not possible at the > moment... you need to do the mapping in your config, for example, using a htable. -- juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sanity passes invalid uri
Daniel-Constantin Mierla writes: > I don't remember any change recently to sanity, so probably it was > developed like this for long time. Yes, it is not a new bug. When I have extra time, I'll take a look at the code. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Transport question
Wilkins, Steve writes: > Yes, I do. It seems so strange that nothing I try will enable it to > go out over TCP. There is very little configuration to force it out > TCP. I have tried a few thing that Alex has suggested but nothing > sends it over TCP. Show what you get about Listening to syslog when you start K, for example: May 16 14:49:21 trout sip-proxy[22795]: Listening on May 16 14:49:21 trout sip-proxy[22795]: udp: 192.168.43.82 [192.168.43.82]:5060 May 16 14:49:21 trout sip-proxy[22795]: udp: 127.0.0.1 [127.0.0.1]:5070 May 16 14:49:21 trout sip-proxy[22795]: tcp: 192.168.43.82 [192.168.43.82]:5060 May 16 14:49:21 trout sip-proxy[22795]: tcp: 127.0.0.1 [127.0.0.1]:5070 May 16 14:49:21 trout sip-proxy[22795]: tcp: 127.0.0.1 [127.0.0.1]:6060 then $ru = $ru + ";transport=tcp"; force_send_socket(192.168.43.82:5060); # replace ip:port with yours t_relay(); -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Transport question
Wilkins, Steve writes: > I tried your suggestion and everything is still going over UDP. I > verified with tcpdump/wireshark and all SIP traffic is UDP. Check your send socket, i.e., that it listens on TCP. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_load_contacts() and t_next_contacts() guts
KamDev Essa writes: >- How do I mark the entries in the location table as permanent. you can use a flag for it or use long expires time. >- How do I group the entries in the location table as belonging to >- one hunt group ike the 4 extensions I mentioned uris of the extensions are permanent contacts of the called number. >- If I mark the entery as permanent how would I know if that >- extension is currently registered or not. permanent contact is always registered. -- juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_load_contacts() and t_next_contacts() guts
KamDev Essa writes: > But lookup looks at urloc (location) table but that is dynamic. How > do I say these extensions need to be in this hunt group. What > static table do I place that info in. Sorry, I don't understand. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Randomizing t_load_contacts() with same q value?
Daniel-Constantin Mierla writes: > > Without taking the q value into account I could do something with the > > defined contacts_avp before calling t_next_contacts(). But I have no > > idea how to randomize and serialize the branches with the same q value > > after calling t_next_contacts(). Any ideas? t_load_contacts() loads the contacts into an xavp. You can rearrange them according to your wishes before starting to call t_next_contacts(). -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] sanity passes invalid uri
I noticed that K 5.0 sanity() test passes uri that contains ` (back quote)
character.
Config:
modparam("sanity", "default_checks", 1024) /* URI checks */
modparam("sanity", "uri_checks", 3) /* RURI, From */
xlog("L_INFO", "Checking $ru\n");
if (!sanity_check())
xlog("L_INFO", "Check failed\n");
else
xlog("L_INFO", "Check passed\n");
Syslog:
Oct 27 17:17:38 lohi /usr/bin/sip-proxy[31946]: INFO: Checking sip:jh@te`st.fi
Oct 27 17:17:38 lohi /usr/bin/sip-proxy[31946]: INFO: Check passed
According to RFC3261:
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
Is this a bug or am I missing something?
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Distributed Presence between Multiple Kamailios
Charles Chance writes: > > Presence module has a new integration with DMQ in master branch which does > > exactly what you’re looking for. It’s enabled by setting modparam > > “enable_dmq” and the rest takes care of itself: > > > > https://github.com/kamailio/kamailio/commit/3fc1da644a6b375fc45ea17cbcf816 > > 43f70db545 Charles, What are the benefits of DMQ replication over use of shared database? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How are SIP messages divided amongst TCP workers?
This issue may be related to the question: https://github.com/kamailio/kamailio/issues/1107 -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] sipwise/sems for video
Amar Tinawi writes: > my question is does sems support Video ? or is there any tuning for sems to > allow Video media streams ? SEMS does not support video. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sipwise/sems for video
Amar Tinawi writes: > As signaling and media ? Media for sure. Haven't tried signaling only. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] how to enable tcp_write_buf?
I tried to issue mtree.list command using xmlrpc query that would result in large response, and got error Aug 15 18:12:07 char /usr/bin/sip-proxy[10348]: ERROR: [core/tcp_main.c:618]: _wbufq_add(): (221375 bytes): write queue full or timeout (0, total 0, last write 55534052 s ago) Aug 15 18:12:07 char /usr/bin/sip-proxy[10348]: ERROR: xmlrpc [xmlrpc.c:811]: send_reply(): Error while sending reply Aug 15 18:12:07 char /usr/bin/sip-proxy[10367]: ERROR: [core/tcp_main.c:3551]: handle_ser_child(): received CON_ERROR for 0x7f112ad22be0 (id 5), refcnt 3, flags 0x4018 I though that perhaps I could get rid of the error by increasing value of core var tcp_conn_wq_max. Description of the var tells: Maximum bytes queued for write allowed per connection. Attempting to queue more bytes would result in an error and in the connection being closed (too slow). If tcp_write_buf is not enabled, it has no effect. What is tcp_write_buf and how to enable it? I could not find anything about it in core cookbook. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to enable tcp_write_buf?
Dmitri Savolainen writes: > This issue is discussed here > https://github.com/kamailio/kamailio/pull/1376 There Daniel asks about increasing tcp_conn_wq_max and tcp_wq_max, which gets back to my original question: what is tcp_write_buf and how to enable it? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to enable tcp_write_buf?
Dmitri Savolainen writes: > This issue is discussed here > https://github.com/kamailio/kamailio/pull/1376 Thanks for the pointer. > As temporary solution i use jsonrpcs fifo for big results. I tried that too (over http) and it worked. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to enable tcp_write_buf?
Henning Westerholt writes: > The correct spelling should be tcp_buf_write (new name tcp_async). You can > find this in the core docs. Thanks. tcp_async is enabled by default. I then went and set tcp_conn_wq_max=256000 After that, I was able to fetch 1000 mtree records by issuing mtree.list command over xmlrpc. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to enable tcp_write_buf?
Dmitri Savolainen writes: > So i am afraid change default value (32k) so vast according to possible > side effects for SIP tcp connections I agree. That is why my plan is to switch from xlmrpc transport to http, which seems to work without any need to increase tcp_conn_wq_max. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] JSONRPC-S and async RPC commands
Daniel-Constantin Mierla writes: > the module has support for async commands sent over HTTP, but not over > other transport layers, iirc. Good, I'll give it a try. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] JSONRPC-S and async RPC commands
JSONRPC-S module README has: 2. Limitations This module does not implement asynchronous RPC commands. It is unlikely that asynchronous RPC commands will be executed from an JSON-RPC over HTTP client. Does this mean that, for example, tm.t_uac_wait command cannot be executed using JSON-RPC over HTTP? If so, why "it is unlikely that asynchronous RPC commands will be executed from an JSON-RPC over HTTP client", since those commands are currently commonly executed from XMLRPC client using xmlrpc module? It would be nice if JSONRPC-S module could be used as replacement of xmlrpc module. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] JSONRPC-S and async RPC commands
I cave tm.t_uac_wait over JSONRPC-S a try and got a crash: (gdb) where #0 0x7ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at jsonrpcs_mod.c:390 #1 0x7ff1ec5ee5ac in jsonrpc_delayed_ctx_close (dctx=0x7ff1e2706660) at jsonrpcs_mod.c:1037 #2 0x7ff1f1deb375 in rpc_uac_callback (t=0x7ff1e26d91e0, type=1024, ps=0x7ffceb219720) at rpc_uac.c:391 #3 0x7ff1f1e15d65 in run_trans_callbacks_internal (cb_lst=0x7ff1e26d9250, type=1024, trans=0x7ff1e26d91e0, params=0x7ffceb219720) at t_hooks.c:260 #4 0x7ff1f1e15e89 in run_trans_callbacks (type=1024, trans=0x7ff1e26d91e0, req=0x0, rpl=0x7ff1f4b06130, code=200) at t_hooks.c:287 #5 0x7ff1f1dca327 in local_reply (t=0x7ff1e26d91e0, p_msg=0x7ff1f4b06130, branch=0, msg_status=200, cancel_data=0x7ffceb2198f0) at t_reply.c:2136 #6 0x7ff1f1dccb40 in reply_received (p_msg=0x7ff1f4b06130) at t_reply.c:2538 #7 0x560eda5a8744 in do_forward_reply (msg=0x7ff1f4b06130, mode=0) at core/forward.c:744 #8 0x560eda5aa18e in forward_reply (msg=0x7ff1f4b06130) at core/forward.c:845 #9 0x560eda6232ab in receive_msg ( buf=0x560edbc749a0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' , ".0\r\nTo: ;tag=skjao\r\nFrom: ;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58) at core/receive.c:424 #10 0x560eda6c0ecd in receive_tcp_msg ( tcpbuf=0x7ff1e26d4038 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' , ".0\r\nTo: ;tag=skjao\r\nFrom: ;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58, con=0x7ff1e26d3d40) at core/tcp_read.c:1428 #11 0x560eda6c319f in tcp_read_req (con=0x7ff1e26d3d40, bytes_read=0x7ffceb21a004, read_flags=0x7ffceb21a00c) at core/tcp_read.c:1611 #12 0x560eda6c6dc6 in handle_io (fm=0x7ff1f40b8690, events=1, idx=-1) at core/tcp_read.c:1843 #13 0x560eda6b41b7 in io_wait_loop_epoll (h=0x560edab49f40 , t=2, repeat=0) at core/io_wait.h:1065 #14 0x560eda6c819c in tcp_receive_loop (unix_sock=45) at core/tcp_read.c:1955 #15 0x560eda56c056 in tcp_init_children () at core/tcp_main.c:4853 #16 0x560eda494912 in main_loop () at main.c:1711 #17 0x560eda49b92a in main (argc=17, argv=0x7ffceb21a688) at main.c:2645 -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] JSONRPC-S and async RPC commands
Daniel-Constantin Mierla writes:
> Get couple of more details from gdb:
Below, Juha
(gdb) frame 0
#0 0x7ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at
jsonrpcs_mod.c:390
390 in jsonrpcs_mod.c
(gdb) list
385 in jsonrpcs_mod.c
(gdb) info locals
nj = 0x0
i = -630111740
rbuf = {s = 0x3 , len = -187033216}
__func__ = "jsonrpc_send"
(gdb) p *ctx
$1 = {msg = 0x7ff1e270d170, msg_shm_block_size = 3024, method = 0x0, flags =
257, jreq = 0x0, req_node = 0x0, jrpl = 0x560edbc8ea20,
rpl_node = 0x0, reply_sent = 1, error_code = 0, error_text = {s = 0x0, len =
0}, http_code = 200, http_text = {s = 0x7ff1ec607b1d "OK",
len = 2}, transport = 1}
(gdb) p *ctx->jreq
Cannot access memory at address 0x0
(gdb) p *ctx->jrpl
$2 = {root = 0x560edbc8f380, flags = 0, buf = {s = 0x0, len = 0}, malloc_fn =
0x7ff1f4ceef10 <__GI___libc_malloc>,
free_fn = 0x7ff1f4cef510 <__GI___libc_free>}
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Enabling tcp_write_buf
Gholamreza Sabery writes: > In the documentation of "tcp_wq_max" option it is written that : > > > It has no effect if *tcp_write_buf *is not enabled. > > > > The interesting fact is that, there is not description of what it is and > > how one can enable it. There is even a question about it in the mailing > > lists: > > > https://lists.kamailio.org//pipermail/sr-dev/2011-June/011521.html > > > It seems that it is an inaccuracy in the documentation. If there is such an > option how to enable it? Can anyone tell? See https://lists.kamailio.org//pipermail/sr-users/2018-August/102568.html -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Parmas in lcr_gw
Ashutosh chaubey writes: > How to give username and password for the gateway in params column in > lcr_gw? It is up to you. params column value of a gw just specifies the params that are added to Request-URI when INVITE request is sent to the gw. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] JSONRPC-S and async RPC commands
Daniel-Constantin Mierla writes: > I just pushed a commit in master branch, hopefully is fixing the issue > -- let me know the results and if ok, it will be backported. Daniel, Thanks for the commit. My tm.t_uac_wait test (using master) now worked fine without issues. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route [tcp:closed] not executed
Daniel-Constantin Mierla writes: > The event_route was defined for the specific case where its name can be > anything and it is a matter of modules to execute some as they need. > > The interpreter which is defined in core has no clue about what names > can be there. The modules cannot complain if they do not find some > event_route blocks that they expect to execute, because if the event > route is not found, then there should be noting executed. Well, kamailio does not start if config includes call of a function defined in a module that is not loaded. Similarly, modules could register their event routes at load, which would allow the interpreter to detect unknown event routes. It may be too late to fix this, since too many modules already exists that define event routes. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route [tcp:closed] not executed
Daniel-Constantin Mierla writes: > Can you test with latest master and debug=3, then send all debug > messages from tcp connect to disconnect? Below is the debug. First REGISTER comes at 13:13:26 and un-REGISTER at 13:13:29 followed by tcp connection close. -- Juha Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 192.168.43.107 Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/tcp_main.c:999]: tcpconn_new(): on port 43822, type 2 Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/tcp_main.c:1305]: tcpconn_add(): hashes: 23:2680:2459, 4 Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0x55561b5d2d40, 69, 2, 0x7f64144e38b0), fd_no=57 Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x55561b5d2d40, 69, -1, 0x0) fd_no=58 called Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/tcp_main.c:4196]: handle_tcpconn_ev(): sending to child, events 1 Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/tcp_main.c:3847]: send2child(): checking per-socket generic workers (15845/27..15874/34) [tcp:192.168.43.107:5060] Sep 4 13:13:26 char /usr/bin/sip-proxy[15893]: DEBUG: [core/tcp_main.c:3875]: send2child(): selected tcp worker 0 27(15845) for activity on [tcp:192.168.43.107:5060], 0x7f64144e38b0 Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:1740]: handle_io(): received n=8 con=0x7f64144e38b0, fd=12 Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:1540]: tcp_read_req(): content-length=0 Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/receive.c:232]: receive_msg(): --- received sip message - request - call-id: [b89bf3310da039ee] - cseq: [59445 REGISTER] Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/receive.c:287]: receive_msg(): preparing to run routing scripts... Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2225]: tcpconn_send_put(): send from reader (15845 (27)), reusing fd Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2460]: tcpconn_do_send(): sending... Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2494]: tcpconn_do_send(): after real write: c= 0x7f64144e38b0 n=519 fd=12 Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2495]: tcpconn_do_send(): buf=#012SIP/2.0 401 Unauthorized ... Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/receive.c:449]: receive_msg(): cleaning up Sep 4 13:13:26 char /usr/bin/sip-proxy[15845]: DEBUG: [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0x55561b61bf40, 12, 2, 0x7f64144e38b0), fd_no=1 Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:1540]: tcp_read_req(): content-length=0 Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/receive.c:232]: receive_msg(): --- received sip message - request - call-id: [b89bf3310da039ee] - cseq: [59447 REGISTER] Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/socket_info.c:559]: grep_sock_info(): checking if host==us: 14==14 && [192.168.43.107] == [192.168.43.107] Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/socket_info.c:566]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2225]: tcpconn_send_put(): send from reader (15845 (27)), reusing fd Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2460]: tcpconn_do_send(): sending... Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2494]: tcpconn_do_send(): after real write: c= 0x7f64144e38b0 n=417 fd=12 Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_main.c:2495]: tcpconn_do_send(): buf=#012SIP/2.0 200 OK ... Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/receive.c:449]: receive_msg(): cleaning up Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:198]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:206]: tcp_emit_closed_event(): no callback registering for handling TCP closed event Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:315]: tcp_read_data(): EOF on 0x7f64144e38b0, FD 12 ([192.168.43.107]:43822 -> Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:316]: tcp_read_data(): -> [192.168.43.107]:5060) Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/tcp_read.c:1507]: tcp_read_req(): EOF Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]: DEBUG: [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x55561b61bf40, 12, -1, 0x10) fd_no=2 called Sep 4 13:13:29 char /usr/bin/sip-proxy[15845]:
Re: [SR-Users] event_route [tcp:closed] not executed
I had not loaded tcpops module. Should work after that. How about checking that all event routes in config have corresponding modules loaded? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route [tcp:closed] not executed
I loaded tcpops module but still nothing to syslog from: event_route [tcp:close] Debug (below) now shows this: Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: tcpops [tcpops.c:233]: tcpops_handle_tcp_closed(): received TCP closed event Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: tcpops [tcpops.c:207]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 10 -- Juha -- Sep 4 14:07:41 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_main.c:2225]: tcpconn_send_put(): send from reader (6487 (27)), reusing fd Sep 4 14:07:41 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_main.c:2460]: tcpconn_do_send(): sending... Sep 4 14:07:41 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_main.c:2494]: tcpconn_do_send(): after real write: c= 0x7f7fad11ed00 n=779 fd=12 Sep 4 14:07:41 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_main.c:2495]: tcpconn_do_send(): buf=#012SIP/2.0 200 OK ... Sep 4 14:07:41 char /usr/bin/sip-proxy[6487]: DEBUG: [core/receive.c:345]: receive_msg(): request-route executed in: 90073 usec Sep 4 14:07:41 char /usr/bin/sip-proxy[6487]: DEBUG: [core/receive.c:449]: receive_msg(): cleaning up Sep 4 14:07:47 char /usr/bin/sip-proxy[6487]: DEBUG: [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x558dca3d4f40, 12, -1, 0x10) fd_no=2 called Sep 4 14:07:47 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:1661]: release_tcpconn(): releasing con 0x7f7fad11ed00, state 1, fd=12, id=4 ([192.168.43.107]:44522 -> [192.168.43.107]:5060) Sep 4 14:07:47 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:1665]: release_tcpconn(): extra_data (nil) Sep 4 14:07:47 char /usr/bin/sip-proxy[6529]: DEBUG: [core/tcp_main.c:3307]: handle_tcp_child(): reader response= 7f7fad11ed00, 1 from 0 Sep 4 14:07:47 char /usr/bin/sip-proxy[6529]: DEBUG: [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0x558dca38bd40, 68, 2, 0x7f7fad11ed00), fd_no=56 Sep 4 14:07:47 char /usr/bin/sip-proxy[6529]: DEBUG: [core/tcp_main.c:3434]: handle_tcp_child(): CONN_RELEASE 0x7f7fad11ed00 refcnt= 1 Sep 4 14:07:52 char /usr/bin/sip-proxy[6529]: DEBUG: [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x558dca38bd40, 68, -1, 0x0) fd_no=57 called Sep 4 14:07:52 char /usr/bin/sip-proxy[6529]: DEBUG: [core/tcp_main.c:4196]: handle_tcpconn_ev(): sending to child, events 2001 Sep 4 14:07:52 char /usr/bin/sip-proxy[6529]: DEBUG: [core/tcp_main.c:3847]: send2child(): checking per-socket generic workers (6487/27..6507/34) [tcp:192.168.43.107:5060] Sep 4 14:07:52 char /usr/bin/sip-proxy[6529]: DEBUG: [core/tcp_main.c:3875]: send2child(): selected tcp worker 0 27(6487) for activity on [tcp:192.168.43.107:5060], 0x7f7fad11ed00 Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:1740]: handle_io(): received n=8 con=0x7f7fad11ed00, fd=12 Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:198]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: tcpops [tcpops.c:233]: tcpops_handle_tcp_closed(): received TCP closed event Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: tcpops [tcpops.c:207]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 10 Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/action.c:1554]: run_actions(): null action list (rec_level=1) Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:315]: tcp_read_data(): EOF on 0x7f7fad11ed00, FD 12 ([192.168.43.107]:44522 -> Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:316]: tcp_read_data(): -> [192.168.43.107]:5060) Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:1507]: tcp_read_req(): EOF Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:1661]: release_tcpconn(): releasing con 0x7f7fad11ed00, state -1, fd=12, id=4 ([192.168.43.107]:44522 -> [192.168.43.107]:5060) Sep 4 14:07:52 char /usr/bin/sip-proxy[6487]: DEBUG: [core/tcp_read.c:1665]: release_tcpconn(): extra_data (nil) Sep 4 14:07:52 char /usr/bin/sip-proxy[6529]: DEBUG: [core/tcp_main.c:3307]: handle_tcp_child(): reader response= 7f7fad11ed00, -1 from 0 ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route [tcp:closed] not executed
Juha Heinanen writes: > I loaded tcpops module but still nothing to syslog from: > > event_route [tcp:close] I had typo in above: should be closed instead of close. This again shows that it would be nice if it would be checked that each event_route has a home. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] please downgrade warning message
I noticed this when I start a correctly configured kamailio: Feb 27 21:55:45 rautu /usr/bin/sip-proxy[29529]: WARNING: registrar [registrar.c:369]: mod_init(): empty reg_xavp_cfg or sock_flag not set -> resetting Neither of those two are mandatory. I'm not using registered() function. Please downgrade the message to info or debug level. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] is t_flush_flags() really needed?
Juha Heinanen writes: > While testing xflags, i noticed that a regular flag that I set AFTER > calling t_newtrans() stays set in onreply_route even when I do not > call t_flush_flags(). I made the same test with xflags and they do require t_flush_xflags() call if an xflag is set after t_newtrans(); So the behavior is not the same with flags and xflags. This is confusing. The flags should behave the same way and I would prefer the flags way in order to avoid the flush call. I added sr-dev to this thread since it now deals also the new feature. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] is t_flush_flags() really needed?
Daniel-Constantin Mierla writes: > Afaik, flags after t_newtran() were supposed not to be moved to > transaction if t_flush_flags(), that being the purpose of the later > function. Are you doing any other tm operations between creating the new > transaction and relaying the request or end of script execution? After calling t_newtran() I arm failure and onreply routes and then call t_relay(). Flags set after t_newtran() are visible in both those routes without calling t_flush_flags(). Same should happen with xflags. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] is t_flush_flags() really needed?
While testing xflags, i noticed that a regular flag that I set AFTER
calling t_newtrans() stays set in onreply_route even when I do not
call t_flush_flags().
In a route block:
if (!t_newtran()) {
ERROR(Failed to create new transaction for $rm <$ru>);
exit;
};
if (!isflagset(19))
INFO( flag 19 is NOT set after t_newtran());
setflag(19);
and in onreply_route:
if (isflagset(19))
INFO(* flag 19 is set);
else
INFO(* flag 19 is NOT set);
Syslog gets:
Mar 25 11:24:41 trout /usr/bin/sip-proxy[21362]: INFO: flag 19 is NOT
set after t_newtran()
Mar 25 11:24:41 trout /usr/bin/sip-proxy[21433]: INFO: * flag 19 is set
So what is the point of t_flush_flags()?
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] force_send_socket
> Le 08/10/2018 à 02:27, Alex Balashov a écrit : > > Hi, > > > > 1. force_send_socket() is essentially deprecated in favour of mutating > > $fs: > > > > $fs = 'udp:67.215.186.219:5060'; According to wiki, $fs cannot deprecate force_send_socket. In force_send_socket, proto can be left out: force_send_socket Force to send the message from the specified socket (it _must_ be one of the sockets specified with the “listen” directive). If the protocol doesn't match (e.g. UDP message “forced” to a TCP socket) the closest socket of the same protocol is used. wheres: $fs - Forced socket $fs - reference to the forced socket for message sending (if any) in the form proto:ip:port -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] force_send_socket
Alex Balashov writes: > In the core, there are lots of functions such as strip(), prefix(), > rewritehostport(), and, in my view, force_send_socket(). These functions > don't take PV arguments, and are superceded by the more flexible direct > manipulation of the RURI, the destination set, and $fs, along with the > wealth of transformations available nowadays, which can be chained. It would be nice if $fs would supersede force_send_socket, i.e, allow proto to be missing. I haven't tried myself. If proto is mandatory in $fs then its use is more cumbersome than that of force_send_socket. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Single session start
Daniel Tryba writes: > On Mon, Nov 12, 2018 at 09:59:10AM +0100, Jos?? Antonio Guti??rrez Delgado > wrote: > > Hi, I would like to know if it is possible to make the last register of a > > user the active register and if possible the only one. > > I'm with an Android application and sometimes I can not deregister properly > > before the new registration, for example when the network changes, so there > > are times when the hanging signals do not work correctly when there is more > > than one register for a user. > > Is it possible to avoid that there is more than one register for a user? Is > > it possible to configure the last register to delete the previous ones or > > to be a single register? > > Thanks in advance and I await your answers. > > Take a look at the second argument for save() > > https://www.kamailio.org/docs/modules/5.1.x/modules/registrar.html#registrar.f.save > Set it to "0x04" to override any other location. Other options: 1) use tcp or tls and configure K to deregister when connection gets closed. 2) use a real SIP user agent (such as baresip) that supports GRUU and is thus able to tell that the next register request is from the same UA as the previous Both of these options allows also registering two different UAs using the same AoR. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] clang compiler warnings
I just made a test and, for sure, clang warns about unused variables: $ clang -Wunused-variable -I/usr/include/re -I/usr/include/baresip -lbaresip -lrem -lre baresip.c baresip.c:48:6: warning: unused variable 'unused' [-Wunused-variable] int unused; ^ 1 warning generated. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] clang compiler warnings
Floimair Florian writes: > I think your mail was intended for the baresip mailing list. > There is no baresip.c in Kamailio I just wanted to check if it is really so that clang doesn't generate unused compiler warnings. Any C source is OK for that test and I just happened to have baresip.c around. clang does not produce unused var warnings without -Wunused-variable, which means that that flag needs to be added to K Makefile. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route [tcp:closed] not executed
Daniel-Constantin Mierla writes: > Can you list the tcp connections via rpc and see if the one you expect > to be closed is still listed there? core.tcp_list after quiting baresip shows that the tcp connection has been removed, i.e., is not anymore in the list -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] event_route [tcp:closed] not executed
Based on comment:
https://github.com/kamailio/kamailio/issues/171#issuecomment-418175840
I gave event_route [tcp:closed] a try:
event_route [tcp:closed] { # Handle TCP connection close
xlog("L_INFO", "$proto connection closed ($conid)\n");
}
Nothing comes to syslog when I quit my baresip UA that according to
wireshark closes its TCP connection after un-registration (fin - fin -
ack).
I have not set closed_event param, because according to README, it
defaults to 1.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > what happens when you send a sip message and have debug=3? Do you see > any logs printed? Nothing comes to syslog when register request arrives. Also kamailio does not respond to ctl command. Below is sample on what comes to syslog after start. -- Juha root@char:/var/www/manager# Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: ERROR: rtpengine [rtpengine.c:2667]: send_rtpp_command(): timeout waiting reply for command "" from RTP proxy Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: ERROR: rtpengine [rtpengine.c:2541]: rtpp_test(): proxy did not respond to ping Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: rtpengine [rtpengine.c:668]: bind_force_send_ip(): force_send_ip_str not specified in .cfg file! Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: rtpengine [rtpengine.c:2518]: rtpp_test(): rtpp udp:192.26.134.10:6050 disabled for ever Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [core/sr_module.c:841]: init_mod_child(): idx 3 rank 3: mtree [udp receiver child=2 sock=192.168.43.107:5060] Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db.c:314]: db_do_init2(): connection 0x7f72f324a610 not found in pool Dec 24 12:29:41 char /usr/bin/sip-proxy[20315]: DEBUG: rtpengine [rtpengine.c:668]: bind_force_send_ip(): force_send_ip_str not specified in .cfg file! Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:107]: db_mysql_new_connection(): opening connection: mysql://:@127.0.0.1/sip_proxy Dec 24 12:29:41 char /usr/bin/sip-proxy[20315]: INFO: rtpengine [rtpengine.c:2551]: rtpp_test(): rtp proxy found, support for it enabled Dec 24 12:29:41 char /usr/bin/sip-proxy[20315]: DEBUG: rtpengine [rtpengine.c:668]: bind_force_send_ip(): force_send_ip_str not specified in .cfg file! Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:146]: db_mysql_new_connection(): connection type is 127.0.0.1 via TCP/IP Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:147]: db_mysql_new_connection(): protocol version is 10 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:148]: db_mysql_new_connection(): server version is 10.1.37-MariaDB-0+deb9u1 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: mtree [mtree_mod.c:344]: child_init(): #3: database connection opened successfully Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [core/sr_module.c:841]: init_mod_child(): idx 3 rank 3: sipdump [udp receiver child=2 sock=192.168.43.107:5060] Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [core/sr_module.c:841]: init_mod_child(): idx 3 rank 3: siptrace [udp receiver child=2 sock=192.168.43.107:5060] Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db.c:314]: db_do_init2(): connection 0x7f72f32b19b0 not found in pool Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:107]: db_mysql_new_connection(): opening connection: mysql://:@127.0.0.1/sip_proxy_usage Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:146]: db_mysql_new_connection(): connection type is 127.0.0.1 via TCP/IP Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:147]: db_mysql_new_connection(): protocol version is 10 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_my_con.c:148]: db_mysql_new_connection(): server version is 10.1.37-MariaDB-0+deb9u1 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db_res.c:119]: db_new_result(): allocate 56 bytes for result set at 0x7f72f32fd570 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_res.c:67]: db_mysql_get_columns(): 1 columns returned from the query Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db_res.c:156]: db_allocate_columns(): allocate 8 bytes for result names at 0x7f72f32ed3b0 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db_res.c:167]: db_allocate_columns(): allocate 4 bytes for result types at 0x7f72f3495140 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_res.c:84]: db_mysql_get_columns(): allocate 16 bytes for RES_NAMES[0] at 0x7f72f3495170 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_res.c:91]: db_mysql_get_columns(): RES_NAMES(0x7f72f3495170)[0]=[table_version] Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: db_mysql [km_res.c:105]: db_mysql_get_columns(): use DB1_INT result type Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db_res.c:188]: db_allocate_rows(): allocate 16 bytes for rows at 0x7f72f305b780 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db_row.c:117]: db_allocate_row(): allocate 32 bytes for row values at 0x7f72f305b4c0 Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db_val.c:74]: db_str2val(): converting INT [4] Dec 24 12:29:41 char /usr/bin/sip-proxy[20317]: DEBUG: [db_res.c:79]: db_free_columns(): freeing 1 columns
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > I pushed a quick fix for the case when db support is not enabled, > because these locks are useless in that case, so all children will do > the rtpengine init at the same time, without waiting for the others: Still took in rtpengine db mode about 2 minutes before kamailio became responsive after start. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes:
> Maybe you would also want to tune the timeout with the modparam:
>
> modparam("rtpengine", "rtpengine_disable_tout", 5)
>
> So detection of unavailable rtpproxy is fast, otherwise it is 60 sec by
> default, so you may still experience some slow start per child
> process.
I understand from the param description that it tells how to behave
AFTER rtp proxy has been marked disabled:
Once an RTP proxy was found unreachable and marked as disabled, the
rtpengine module will not attempt to establish communication to that
RTP proxy for rtpengine_disable_tout seconds.
The problem that I have experienced is that it takes long time (2
minutes or so) before rtpengine modules disables a non-responding
rtp proxy.
Also, no matter what the module does, it must not make the whole sip
proxy non-responsive for any number of seconds.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > You can make a fix yourself if you want and have the time. It is not a > module I coded, nor the one that added db support for it, so I am also > coding by learning what was done there. Understand. Perhaps the solution for now is to disable db mode in the code, since it is not a good idea to allow modules in K that freeze the whole sip proxy. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes:
> I was able to figure out what could be the cause with:
>
> modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223
> udp:192.168.64.4:2224")
In my test, I use rtpengine in db mode, i.e., db_url param is set.
Would your patch also fix the delay in that mode?
I'll give it a try anyway.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > I tried quickly with a rtpengine that was not running, and kamailio > started fine and then was responding fast for sip requests. > > To clarify: you actually have more rtpengine configured (at least two) > in a set and one is not available, right? Yes, I have two in one set: udp:127.0.0.1:6050 (running) udp:192.26.134.10:6050 (host 192.26.134.10 is down) > Is the CPU usage very high? Because it is strange that is responding, > but with long delay ... top does not show any kamailio processes in the top. In addition to not responding to sip requests, kamailio does not respond to kamcmd command either. It stars to respond when rtpengine module gives up on trying and declares udp:192.26.134.10:6050 disabled. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] kamailio does not responde if an rtpengine is unreachable
I noticed that if one rtpengine in a set is unreachable, kamailio 5.2 does start, but does not process any SIP requests. Is this intentional? -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > Can you see how many kamailio processes are running (w.g., with ps)? Are > there expected number of there? Same number of processes when I start K with proper rtpengine set and with one that has an rtpengine that does not respond. > If yes, take the PID of few of them and attach with gdb, then grab the > back trace in order to see what they do. There is 41 processes. Below is a few different ones. -- Juha --- #0 0x7f9958d04210 in __pause_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x55ce69f98509 in main_loop () at main.c:1755 #2 0x55ce69f9eb39 in main (argc=17, argv=0x7ffd8be61d18) at main.c:2645 #0 0x7f9958d359c3 in __recvfrom_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x55ce6a029443 in udp_rcv_loop () at core/udp_server.c:460 #2 0x55ce69f969cf in main_loop () at main.c:1621 #3 0x55ce69f9eb39 in main (argc=17, argv=0x7ffd8be61d18) at main.c:2645 #0 0x7f9958c7fe89 in __GI___sigwaitinfo (set=, info=0x0) at ../sysdeps/unix/sysv/linux/sigwaitinfo.c:56 #1 0x55ce6a04c36a in slow_timer_main () at core/timer.c:1093 #2 0x55ce69f971ab in main_loop () at main.c:1677 #3 0x55ce69f9eb39 in main (argc=17, argv=0x7ffd8be61d18) at main.c:2645 #0 0x7f9958d359c3 in __recvfrom_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x55ce6a153168 in async_task_run (idx=1) at core/async_task.c:269 #2 0x55ce6a151f9c in async_task_child_init (rank=0) at core/async_task.c:185 #3 0x55ce6a0d5e3a in init_child (rank=0) at core/sr_module.c:867 #4 0x55ce69f977cc in main_loop () at main.c:1703 #5 0x55ce69f9eb39 in main (argc=17, argv=0x7ffd8be61d18) at main.c:2645 #0 0x7f9958d350a3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f99554117e7 in io_wait_loop_epoll (h=0x7f9955643340 , t=10, repeat=0) at ../../core/io_wait.h:1034 #2 0x7f9955415d1a in io_listen_loop (fd_no=1, cs_lst=0x55ce6c6b6680) at io_listener.c:281 #3 0x7f9955431c4c in mod_child (rank=0) at ctl.c:338 #4 0x55ce6a0d5a84 in init_mod_child (m=0x7f99580b0ea0, rank=0) at core/sr_module.c:843 #5 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b12d0, rank=0) at core/sr_module.c:839 #6 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b1600, rank=0) at core/sr_module.c:839 #7 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b1ac0, rank=0) at core/sr_module.c:839 #8 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b1ee0, rank=0) at core/sr_module.c:839 #9 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b2720, rank=0) at core/sr_module.c:839 #10 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b2a30, rank=0) at core/sr_module.c:839 #11 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b3210, rank=0) at core/sr_module.c:839 #12 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b34a0, rank=0) at core/sr_module.c:839 #13 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b36f0, rank=0) at core/sr_module.c:839 #14 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b3a20, rank=0) at core/sr_module.c:839 #15 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b4270, rank=0) at core/sr_module.c:839 #16 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b44c0, rank=0) at core/sr_module.c:839 #17 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b47f0, rank=0) at core/sr_module.c:839 #18 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b4c80, rank=0) at core/sr_module.c:839 #19 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b5250, rank=0) at core/sr_module.c:839 #20 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b6e20, rank=0) at core/sr_module.c:839 #21 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b7490, rank=0) at core/sr_module.c:839 #22 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b77a0, rank=0) at core/sr_module.c:839 #23 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b7b20, rank=0) at core/sr_module.c:839 #24 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b7d70, rank=0) at core/sr_module.c:839 #25 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b87d0, rank=0) at core/sr_module.c:839 #26 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b8f50, rank=0) at core/sr_module.c:839 #27 0x55ce6a0d5707 in init_mod_child (m=0x7f99580b95d0, rank=0) at core/sr_module.c:839 #28 0x55ce6a0d5707 in init_mod_child (m=0x7f99580be830, rank=0) at core/sr_module.c:839 #29 0x55ce6a0d5707 in init_mod_child (m=0x7f99580beeb0, rank=0) at core/sr_module.c:839 #30 0x55ce6a0d5707 in init_mod_child (m=0x7f99580bf220, rank=0) at core/sr_module.c:839 #31 0x55ce6a0d5707 in init_mod_child (m=0x7f99580bf5c0, rank=0) at core/sr_module.c:839 #32 0x55ce6a0d5707 in init_mod_child (m=0x7f99580bf810, rank=0) at core/sr_module.c:839 #33 0x55ce6a0d5707 in init_mod_child (m=0x7f99580bfea0, rank=0) at core/sr_module.c:839 #34 0x55ce6a0d5707 in init_mod_child (m=0x7f99580c01a0, rank=0) at core/sr_module.c:839 #35
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > It waits for packets from the network. Did you send registration via > UDP? No, via tcp and there was also tcp listener processes. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
* Paolo Visintin - evosip.cloud writes: > we solved starting with no rtpengine this produces at startup: > WARNING: rtpengine [rtpengine_db.c:100]: rtpp_load_db(): No rtpproxy > instances in database > and then, after rtpengine instances are up and correctly running we send an > `rtpengine.reload` to kamailio That would work for me too. Also starting with all rtpproxies disabled and then enabling them after start. > Note that after the startup, if an rtpengine instance fails no hangs in > kamailio just put in disabled state and everything works! Exactly, but all these are hacks. This is a VERY serious issue and needs to be properly fixed. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes:
> Can you see the packet being sent over the network (with ngrep, tcpdump,
> ...)?
Yes, UDP register is sent, but kamailio does not respond to it.
Then I did this.
1) Started K where rtpengine udp:192.26.134.10:6050 is enabled but is
not running.
2) Gave kamcmd command. It two about two minutes before I got the
prompt.
3) Gave 'rtpengine.show all' command. It took perhaps 30 seconds to
produce:
{
url: udp:127.0.0.1:6050
set: 0
index: 0
weight: 10
disabled: 0
recheck_ticks: 0
}
{
url: udp:192.26.134.10:6050
set: 0
index: 2
weight: 1
disabled: 1
recheck_ticks: 60
}
{
url: udp:192.26.134.10:6050
set: 1
index: 1
weight: 1
disabled: 1(permanent)
recheck_ticks: N/A
}
Now udp:192.26.134.10:6050 shows as disabled and kamailio started to
accept sip requests.
How is it possible that one non-responding rtpengine can paralyze the
whole sip proxy?
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
David Villasmil writes: > You could also ask politely, as this IS open source, after all. I didn't notice any impoliteness in my message. I just mentioned that a proper fix is needed. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable
Daniel-Constantin Mierla writes: > I just pushed a series of commits trying to rework how loading (and > reloading) of rtpegines list is done, to avoid that sync'ed probing, > which can take long if any of the rtpengines is down. Daniel, Thanks for the commit. Now K starts responding immediately also in db mode even if some rtp proxies are not responding to ping. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to catch attacker using bad request line?
Juha Heinanen writes: > I'll backport to 5.1. cherry-pick didn't work: $ git cherry-pick -x f088d2afe4153b9e440a4293211c78f5a25af691 error: could not apply f088d2afe... core: if nosip msg hooks skip handling the packet, stop sip routing processing hint: after resolving the conflicts, mark the corrected paths hint: with 'git add ' or 'git rm ' hint: and commit the result with 'git commit' I'm not sure if I dare to do manual edit. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to catch attacker using bad request line?
Daniel-Constantin Mierla writes: > I guess you have some modules that registered to process non-sip > traffic, such as xhttp, xmlrpc, ... the parse_msg() throws error and in > such case the processing is delegated to non-sip message handling, if > all skipped, then ended up on trying going further as sip ... Yes, there is event_route [xhttp:request]. > > I just pushed a patch to deal with it properly. Can you test? if all ok, > feel free to backport. Now the event_route[core:receive-parse-error] was executed: Sep 17 17:52:14 char /usr/bin/sip-proxy[18269]: NOTICE: Request from <192.168.43.107> has invalid syntax and there was no ERROR/WARNING messages. I'll backport to 5.1. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to catch attacker using bad request line?
Daniel-Constantin Mierla writes: > I will check the cherry pick conflict and do the backport manually if > needed once. Going to be a bit later today. I did it. There was only one small conflict. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Record-Route Parameters
Duarte Rocha writes: > When Kamailio receives the INVITE, it relays it with two Record-Route like > this : > > Record-Route:sip:IP1;ftag=;vst=xxx;vsf=xxx > Record-Route:sip:IP2;ftag=;vst=xxx;vsf=xxx > What i want is : > > Record-Route:sip:IP1;ftag=;vst=xxx;vsf=xxx;NEW_PARAMETER=10 > Record-Route:sip:IP2;ftag=;vst=xxx;vsf=xxx;NEW_PARAMETER=20 If you now call record_route(), try calling record_route_preset(string [,string2]). -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] how to catch attacker using bad request line?
In order to be able to fail2ban an attacker that sends tons of SIP requests with malformed request lines, it would need to be possible to generate an appropriate syslog message from config file. I didn't find any sanity module param value that would turn on checking of request line syntax. Any other ideas? As an example, below is what comes to syslog when I send a request that has syntax error on request line. -- Juha Sep 17 14:46:39 char /usr/bin/sip-proxy[9458]: ERROR: [core/parser/msg_parser.c:337]: parse_headers(): bad header field [(null)] Sep 17 14:46:39 char /usr/bin/sip-proxy[9458]: WARNING: [core/receive.c:230]: receive_msg(): parsing relevant headers failed Sep 17 14:46:43 char /usr/bin/sip-proxy[9458]: ERROR: [core/parser/msg_parser.c:337]: parse_headers(): bad header field [(null)] Sep 17 14:46:43 char /usr/bin/sip-proxy[9458]: WARNING: [core/receive.c:230]: receive_msg(): parsing relevant headers failed ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] how to catch attacker using bad request line?
Juha Heinanen writes:
> I didn't find any sanity module param value that would turn on checking
> of request line syntax. Any other ideas?
I added log message at the beginning of main route block:
route { # main route block (initial tasks)
xinfo("Here\n");
It was not printed when malformed request came in, which means that the
main route block was not executed at all.
Kamailio cannot be wide open to DoS attacks. What is it that I'm
missing.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] MWI notification through pua.publish
willy writes: > Have anyone tried to use pua.publish to send MWI notification? Can it > work at all? > > I'm sending request through jsonrpc server, but it is not dispatched by > handle_publish. It works fine here. Last week I noticed an issue with pua.publish over jsonrpc and it was fixed. Even before the fix, pua.publish worked, but an error message was issued. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to catch attacker using bad request line?
Daniel-Constantin Mierla writes:
> try with event_route[core:receive-parse-error] { ... }
>
> The variables related to sip message content (headers, body, ...) likely
> not working there (should return null), but source IP/port should be good.
Thanks for the pointer. I defined:
event_route[core:receive-parse-error] { # Catch message parse errors
xnotice("Request from <$var(src_ip)> has invalid syntax\n");
}
but didn't get the notice to syslog. Only these:
Sep 17 16:37:52 char /usr/bin/sip-proxy[23020]: ERROR:
[core/parser/msg_parser.c:337]: parse_headers(): bad header field [(null)]
Sep 17 16:37:52 char /usr/bin/sip-proxy[23020]: WARNING:
[core/receive.c:230]: receive_msg(): parsing relevant headers failed
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Record-Route Parameters
Duarte Rocha writes: > Can you show me where? I've tried add_rr_param() but it still adds every > parameter to the two record-routes. I didn't quite understand your question. Perhaps you need to add the r-r headers using append_hf() function that allows you to customize them. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to catch attacker using bad request line?
Daniel-Constantin Mierla writes: > Can you send all log messages with debug=3? Below. > Btw, the source ip variable is $si. Oh yes, I had just copied the statement from other part of config, where $si has been assigned to $var(src_ip). -- Juha Sep 17 16:56:07 char /usr/bin/sip-proxy[24183]: INFO: [core/cfg/cfg_ctx.c:595]: cfg_set_now(): core.debug has been changed to 3 sip-proxy_ctl> Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 192.168.43.107 Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/tcp_main.c:999]: tcpconn_new(): on port 48636, type 2 Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/tcp_main.c:1305]: tcpconn_add(): hashes: 1768:3207:3940, 1 Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0x55839aa16da0, 67, 2, 0x7fb01cc67930), fd_no=55 Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x55839aa16da0, 67, -1, 0x0) fd_no=56 called Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/tcp_main.c:4196]: handle_tcpconn_ev(): sending to child, events 1 Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/tcp_main.c:3847]: send2child(): checking per-socket generic workers (24205/27..24230/34) [tcp:192.168.43.107:5060] Sep 17 16:56:16 char /usr/bin/sip-proxy[24255]: DEBUG: [core/tcp_main.c:3875]: send2child(): selected tcp worker 0 27(24205) for activity on [tcp:192.168.43.107:5060], 0x7fb01cc67930 Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/tcp_read.c:1759]: handle_io(): received n=8 con=0x7fb01cc67930, fd=12 Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:249]: parse_first_line(): parse_first_line: bad request first line Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:251]: parse_first_line(): at line 0 char 35: Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:257]: parse_first_line(): parsed so far: REGISTERsip:test.tutpro.com SIP/2.0 Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad message (offset: 35) Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/tcp_read.c:1560]: tcp_read_req(): content-length=0 Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:249]: parse_first_line(): parse_first_line: bad request first line Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:251]: parse_first_line(): at line 0 char 35: Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:257]: parse_first_line(): parsed so far: REGISTERsip:test.tutpro.com SIP/2.0 Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad message (offset: 35) Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/msg_parser.c:606]: parse_msg(): invalid message Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/msg_parser.c:681]: parse_msg(): ERROR: parse_msg: message=;expires=600;+sip.instance="";q=0.5;reg-id=1#015#012Max-Forwards: 70#015#012Route: #015#012To: #015#012From: ;tag=ab41d0eaaf619e81#015#012Call-ID: 08f94737eec75885#015#012CSeq: 26277 REGISTER#015#012User-Agent: baresip v0.5.11 (x86_64/linux)#015#012Supported: gruu, outbound, path#015#012Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE#015#012Content-Length: 0#015#012#015#012> Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/msg_parser.c:83]: get_hdr_field(): null buffer pointer Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/parser/msg_parser.c:279]: get_hdr_field(): error exit Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: ERROR: [core/parser/msg_parser.c:337]: parse_headers(): bad header field [(null)] Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: WARNING: [core/receive.c:230]: receive_msg(): parsing relevant headers failed Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/receive.c:232]: receive_msg(): --- received sip message - reply - call-id: [] - cseq: [] Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 17 16:56:16 char /usr/bin/sip-proxy[24205]: DEBUG:
Re: [SR-Users] how to catch attacker using bad request line?
Daniel-Constantin Mierla writes: > Can you send all log messages with debug=3? I also started k with debug=3 to check that the event route is ok: Sep 17 17:00:40 char sip-proxy: DEBUG: [core/events.c:53]: sr_core_ert_init(): event_route[core:receive-parse-error] is defined -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Record-Route Parameters
Duarte Rocha writes: > I need all of my kamailio's IPs in Record Routes and i can do that already. > What i want to do is add different parameters to each Record-Route. Is that > possible? Yes, read rr module README. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] crash at 480 reply to INVITE
Daniel-Constantin Mierla writes: > Can you tell what linux distro and version was running in your case? > Also, can you give the output for: It was Debian Stretch installed on (if I remember correctly) xen virtual machine. I'll check to be sure. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] crash at 480 reply to INVITE
Juha Heinanen writes: > It was Debian Stretch installed on (if I remember correctly) xen virtual > machine. I'll check to be sure. Yes, it was VM on XenServer. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
