sr-dev July 2019

sr-dev@lists.kamailio.org

20 participants
232 discussions

[kamailio/kamailio] cfgt: doesn't support tm_suspend() tm_continue() (#684)
by Victor Seva 23 Jan '24

23 Jan '24

Actual implementation doesn't work with async. Need to investigate how to support it --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/684

3 8

[kamailio/kamailio] dmq_usrloc not replicating contact attributes (#1968)
by pwakano 16 Jan '24

16 Jan '24

### Description  The dmq_usrloc module is not replicating the extra attributes saved in the xavp for the contact. So remote nodes don't receive these values, being unable to access it properly. It is expected that the attributes are replicated as well. #### Reproduction  Setup two nodes using the dmq_usrloc and usrloc in db_mode=0. When receiving a REGISTER, before saving the contact add some attribute in the xavp_contact. In a subsequent message to this contact (e.g.: INVITE) use a lookup() or registered() and try to access the desired xavp_contact attribute. If the request is received in the local node (which received the original REGISTER), the attribute will be valid, but if the request is received in the remote node, the attribute is empty. #### Log Messages  ``` May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: registrar [save.c:410]: pack_ci(): generated ruid is: uloc-5cee2114-5abe-2 May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:73]: ucontact_xavp_store(): trying to clone per contact xavps May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:697]: xavp_clone_level_nodata(): cloned root xavp [ulattrs] May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:721]: xavp_clone_level_nodata(): cloned inner xavp [cluster_node] May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:1701]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7f51b624d418, callback type 2/15, id 1 entered May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:776]: dmq_ul_cb_contact(): Callback from usrloc with type=2 May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:427]: init_usrloc_dmq_recv(): Initializing usrloc_dmq_recv for pid (23230) May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:785]: dmq_ul_cb_contact(): Replicating local update to other nodes... May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:746]: usrloc_dmq_send_contact(): sending serialized data {"action":1,"aor":"345671002","ruid":"uloc-5cee20df-5953-1","c":"sip:345671002@172.28.128.200:5060;rinstance=38e53fed7e84e081;transport=UDP","received":"","path":"<sip:172.28.128.102:5060;received=sip:172.28.128.200:5060;lr>","callid":"NOeeFh1Bh5JR0eJG8DENkg..","user_agent":"Z 3.15.40006 rv2.8.20","instance":"","expires":1559110577,"cseq":12,"flags":0,"cflags":3072,"q":-1,"last_modified":1559109977,"methods":4294967295,"reg_id":0,"server_id":0} May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:315]: usrloc_dmq_send(): sending dmq broadcast... ``` ### Possible Solutions  Only workaround seems to use usrloc with db_mode=3 and then not use the dmq_usrloc, having the usrloc with attributes info shared via the DB.... ### Additional Information Kamailio 5.2.2 installed from the repo. ``` # kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 67f967 compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 ``` * **Operating System**:  ``` # cat /etc/centos-release CentOS Linux release 7.3.1611 (Core) # uname -a Linux kamailio-2 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1968

3 7

[kamailio/kamailio] Using PATH makes nathelper to send the SIP ping to itself (#2011)
by pwakano 13 Jan '24

13 Jan '24

### Description When using the PATH header option to keep track of original Kamailio node that received the REGISTER, if nathelper is also used with SIP ping enabled, the SIP OPTIONS is sent to itself following the PATH header and not sent directly to the destination. The nathelper/user location modules should have a flag similar to the "path_check_local" of the registrar module, which is meant to avoid looping the message to itself in case the next hop pointed by the PATH header is "myself".  ### Troubleshooting #### Reproduction Configure the registrar module to support PATH and before saving the contact info add the PATH header with the local Kamailio information. Also make sure to have the nathelper and usrloc modules configured to send the keepalive SIP OPTIONS to the registered extensions. By the time the SIP OPTIONS is sent, Kamailio sends to itself, then the message has to be loose_route'd to the final destination. This could be avoided by having the nathelper module to identify the next hop is Kamailio itself skipping this destination as a call to "lookup()" does for the registrar module when the flag path_check_local is true.  #### SIP Traffic  172.128.128.10 is the Kamailio IP and 172.128.128.20 is the extension IP ``` 11:51:07.224713 IP (tos 0x60, ttl 64, id 64497, offset 0, flags [none], proto UDP (17), length 518) 172.128.128.10.5060 > 172.128.128.10.5060: SIP, length: 490 OPTIONS sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 Route: <sip:172.128.128.10:5060;received=sip:172.128.128.20:5060;lr;cluster_node=192.168.156.10:5060> From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 To: sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10 CSeq: 1 OPTIONS Content-Length: 0 11:51:07.226132 IP (tos 0x60, ttl 64, id 44359, offset 0, flags [none], proto UDP (17), length 502) 172.128.128.10.5060 > 172.128.128.20.5060: SIP, length: 474 OPTIONS sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 172.128.128.10;branch=z9hG4bKb958.b807e80b742db62504a45220d8f0e974.0 Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 To: sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10 CSeq: 1 OPTIONS Content-Length: 0 11:51:07.303474 IP (tos 0x0, ttl 128, id 10816, offset 0, flags [none], proto UDP (17), length 786) 172.128.128.20.5060 > 172.128.128.10.5060: SIP, length: 758 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.128.128.10;branch=z9hG4bKb958.b807e80b742db62504a45220d8f0e974.0 Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 Contact: <sip:172.128.128.20:5060> To: <sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP>;tag=bb0c1f2d From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10 CSeq: 1 OPTIONS Accept: application/sdp, application/sdp Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri User-Agent: Z 3.15.40006 rv2.8.20 Allow-Events: presence, kpml, talk Content-Length: 0 11:51:07.306821 IP (tos 0x60, ttl 64, id 64570, offset 0, flags [none], proto UDP (17), length 727) 172.128.128.10.5060 > 172.128.128.10.5060: SIP, length: 699 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 Contact: <sip:172.128.128.20:5060;alias=172.128.128.20~5060~1> To: <sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP>;tag=bb0c1f2d From: sip:sbc@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 Call-ID: 40ee1573-7506bba3-5e30c05(a)172.128.128.10 CSeq: 1 OPTIONS Accept: application/sdp, application/sdp Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri User-Agent: Z 3.15.40006 rv2.8.20 Allow-Events: presence, kpml, talk Content-Length: 0 ``` ### Possible Solutions  Not found. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 67f967 compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 ``` * **Operating System**:  ``` # uname -a Linux kamailio-1 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2011

4 7

[kamailio/kamailio] unistr.h: No such file or directory (#2020)
by stefan.wen 12 Jan '24

12 Jan '24

4 4

[kamailio/kamailio] kamctl - shell interpreter selection (#2019)
by Daniel-Constantin Mierla 23 Nov '23

23 Nov '23

### Description The `kamctl` tool seems to require `bash`, while trying to use `/bin/sh`, which can point to `dash` or other shell interpreters. For example, the output of `kamdbctl create`: ``` MySQL password for root: -e \E[37;33mINFO: creating database kamailio_simple_db ... -e \E[37;33mINFO: granting privileges to database kamailio_simple_db ... -e \E[37;33mINFO: creating standard tables into kamailio_simple_db ... -e \E[37;33mINFO: Core Kamailio tables succesfully created. Install presence related tables? (y/n): n /usr/sbin/kamdbctl: 216: /usr/sbin/kamdbctl: Bad substitution ``` It seems that the issue is expanding the variable when getting the answer for y/n question: * https://github.com/kamailio/kamailio/blob/master/utils/kamctl/kamdbctl.base… Such expression seems to be specific for bash: * https://mywiki.wooledge.org/Bashism ### Troubleshooting #### Reproduction Run `kamctl` with `/bin/sh` pointing to `bash`. ### Possible Solutions Decide what to do to have an acceptable solution: enforce `bash`, remove bashisms`... Or maybe focus to make `kamcli` a (full) replacement for `kamctl/kamdbctl` and get rid of those old-style shell/bash scripts: * https://github.com/kamailio/kamcli -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2019

3 4

[kamailio/kamailio] EVAPI: Better ability to remove dead clients (#1880)
by weili-jiang 23 Nov '23

23 Nov '23

### Description If an EVAPI client drops dead and silently closes its TCP connection, EVAPI is not notified in an acceptable time frame. The default OS TCP keep-alive parameters are generally far too long to be effective, and there is no way to override these using module or runtime configuration. Moreover, any attempts to put in a workaround is thwarted by the inability to close an arbitrary EVAPI connection from say, a timer event (since there is no way to specify a connection to close outside the EVAPI context). ### Expected behavior When an EVAPI client goes dead, the connection should be closed in the order of seconds (ideally configurable). The EVAPI should allow connections to be closed via scripting from any context. #### Actual observed behavior When an EVAPI client goes dead, the connection stays open (counting towards the maximum number of allowed clients). When the evapi_close is invoked from other contexts, nothing happens. #### Debugging Data #### Log Messages #### SIP Traffic ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.2.1 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 6.3.0 ``` * **Operating System**: Debian GNU/Linux 9 (stretch) ``` Linux 3b83b180f7c9 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1880

2 2

[kamailio/kamailio] support for a kamailio-dev package for external modules (#1752)
by Victor Seva 23 Nov '23

23 Nov '23

>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902944 > Hi! > > We've got several local kamailio modules, and it would be nice to be > able to build them separately and not have to hook them into the > kamailio source and build systems. I suppose others might find this > useful too. > > I started pondering what adding support for this would imply, and I > think the first step is whether this is something you think upstream > and you'd be happy supporting? It could be that the internal interfaces > are completely unstable and providing this might be a support nightmare, > for example, or other similar concerns. > > I think what would be needed is: > > - Support installing the library .so symlinks into the -dev package. > (The module .so I think would need to stay in the main and module > packages, because some stuff loads them as module.so directly?) > - Support installing the kamailio core, library and module .h files > into the -dev package. AFAIUI modules can have inter-module > dependencies and they might use interfaces from both kamailio core > itself, the shared libraries or other modules. > - Provide a pkg-config file with the necessary compile and link runes > (-I, -L, -rpath and similar) to be able to build 3rd party modules > easily. > > While checking this, I noticed there's a src/lib/Makefile.defs, which > has a TYPE variable to install headers and similar, but it does not > appear to be currently used? > > Thanks, > Guillem -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1752

5 7

[kamailio/kamailio] TLS: Consider what's new and what's supported in OpenSSL (#1878)
by Olle E. Johansson 23 Nov '23

23 Nov '23

### Description  ### Expected behavior #### Actual observed behavior #### Debugging Data ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` (paste your output here) ``` * **Operating System**:  ``` (paste your output here) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1878

3 7

[kamailio/kamailio] OpenSUSE warning cleanup (#1714)
by sergey-safarov 23 Nov '23

23 Nov '23

### Description During kamailio packaging on OpenSUSE in log exist this warnings ``` [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/acc_diameter.so [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/auth_diameter.so [ 860s] kamailio-json.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/jsonrpcc.so [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/pdb.so [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/siputils.so [ 860s] kamailio-xmpp.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/xmpp.so [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/sbin/kamailio [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/sbin/kamcmd [ 860s] The binary calls gethostbyname(). Please port the code to use getaddrinfo(). ``` Could you `port the code to use getaddrinfo()`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1714

3 3

[kamailio/kamailio] tls connection terminated frequently when mongodb cluster member becomes unavailable (#1599)
by flo-eyeson-team 23 Nov '23

23 Nov '23

### Description Kamailio frequently terminates tls connections to sip clients, if db_mongodb database driver is used and one mongodb cluster member becomes unavailable. If one mongodb secondary is shutdown (or the primary and a promotion takes place) kamailio will terminate the tls connection to a sip-client (sends a FIN/ACK) after a short period of time (differs 20s to 180s). If a sip client reconnects, registration will succeed (so mongodb access is fine) but kamailio will terminate the tls connection shortly after. This situation happens as well if only the connection between kamailio and a secondary is blocked (the cluster members can still communicate with each other). I assume that the mongo-c's server discovery might be the culprit. Mongoc iteratively tries to connect to all servers in the mongoc-uri to update their status (`mongodb://mongodb-cluster2:27017,mongodb-cluster1:27017,mongodb-cluster0:27017/kamailio?authMechanism=MONGODB-X509&replicaSet=rs1&ssl=true&sslcertificateauthorityfile=mongo.ca&sslclientcertificatekeyfile=mongo.certkey`). Nonethless, mongoc's server discovery should be transparent to the kamailio client as long as a primary exists (and this is the case). No reason to terminate tls client connections.  ### Troubleshooting #### Reproduction  1. Setup a mongodb cluster with 3 members. 2. Setup kamailio with tls using db-mongodb via tls. Note: The mongodb-uri must contain all three members, e.g. `mongodb://mongodb-cluster2:27017,mongodb-cluster1:27017,mongodb-cluster0:27017/kamailio?ssl=true`) 3. Connect/register a sip client via tls. 4. Stop one member. 5. Clients will receive a ready error on its tls connection. #### Log Messages  The db_mongodb kamailio logs don't reveal any errors. Operations are normal. The only thing which is shown in the logs is TLS read:error. As seen below. ``` Jul 23 14:22:09 bda3e8fce481 /usr/local/sbin/kamailio[318]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS read:error:140E0197:SSL routines:SSL_shutdown:shutdown while in init Jul 23 14:22:09 bda3e8fce481 /usr/local/sbin/kamailio[318]: ERROR: <core> [core/tcp_read.c:1485]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fa9b6343210 r: 0x7fa9b6343290 ``` A wireshark trace reveals that kamailio closes the tcp connection (FIN/ACK). The client receives a "stream truncated". ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.1.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 13:39:15 Jul 23 2018 with gcc 6.3.0 ``` * **mongoc-version** ``` mongoc-1.11.0 (built with cmake ../ -DENABLE_AUTOMATIC_INIT_AND_CLEANUP=OFF) ``` * **Operating System**:  ``` Debian 9.5 docker image running on CentOS 7 (kernel 3.10.0-514.6.1.el7.x86_64) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1599

3 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2019