sr-users July 2018

sr-users@lists.kamailio.org

84 participants
98 discussions

Re-write From URI Domain ($fd) with source IP or relayed message

by Marrold

Hi All, For interoperability reasons I need to re-write the From URI Domain ($fd) in requests proxied by Kamailio to the source IP (socket) that Kamailio will send them via. I have experimented with onsend_route and can successfully discover the snd_ip, however it seems I am unable to rewrite the $fd, presumably because I am too late in the logic. Is this possible? I can hardcode IPs if required but would rather keep it dynamic if I can. Thanks in advance, Matthew

6 years

Unable to insert impu into table

by eyas barhouk

Hello community , on kamailio server i'm using the module "ims_usrloc_scsc" with the following configuration : ......................................................... modparam("ims_usrloc_scscf", "db_url", "mysql://eyas:eyas@localhost/scscf") modparam("ims_usrloc_scscf", "db_mode", 1) modparam("ims_usrloc_scscf", "enable_debug_file", 0) modparam("ims_usrloc_scscf", "matching_mode", 0) modparam("ims_registrar_scscf", "error_reply_code", 503) .......................................................... when i'm running kamailio and try to register i found the following : Jul 04 16:03:59 S-CSCF [S-CSCF][3796]: ERROR: ims_usrloc_scscf [usrloc_db.c:235]: db_insert_impurecord(): Unable to insert impu into table [sip:09876993998148@NET.SYRIATEL] Jul 04 16:03:59 S-CSCF [S-CSCF][3796]: ERROR: ims_usrloc_scscf [udomain.c:580]: insert_impurecord(): error inserting contact into db Jul 04 16:03:59 S-CSCF [S-CSCF][3796]: ERROR: ims_usrloc_scscf [impurecord.c:974]: update_impurecord(): Unable to insert new IMPU for <sip:09876993998148@NET.SYRIATEL> Jul 04 16:03:59 S-CSCF [S-CSCF][3796]: ERROR: ims_registrar_scscf [save.c:809]: update_contacts(): Unable to update impurecord for <sip:09876993998148@NET.SYRIATEL> Jul 04 16:03:59 S-CSCF [S-CSCF][3796]: ERROR: ims_registrar_scscf [cxdx_sar.c:253]: async_cdp_callback(): Error processing REGISTER Jul 04 16:03:59 S-CSCF [S-CSCF][3796]: INFO: ims_registrar_scscf [cxdx_sar.c:84]: create_return_code(): created AVP successfully : [saa_return_code] - [-1] Jul 04 16:03:59 S-CSCF [S-CSCF][3796]: ERROR: <script>: SAR failure - error response sent from module Jul 04 16:04:04 S-CSCF [S-CSCF][3697]: INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [-2] Jul 04 16:04:04 S-CSCF [S-CSCF][3814]: INFO: ims_auth [cxdx_avp.c:137]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp (avp_code = 297, vendor_id = 0) Jul 04 16:04:04 S-CSCF [S-CSCF][3814]: INFO: ims_auth [cxdx_mar.c:79]: create_return_code(): created AVP successfully : [maa_return_code] - [1] Jul 04 16:04:04 S-CSCF [S-CSCF][3694]: INFO: ims_auth [authorize.c:834]: authenticate(): uri=sip:NET.SYRIATEL;transport=TCP nonce=cae12e7c256b8a052ad9824ebb91fa07 response=ee82f8f8ad6bf4530d210144e Jul 04 16:04:04 S-CSCF [S-CSCF][3694]: INFO: ims_auth [authorize.c:886]: authenticate(): UE said: ee82f8f8ad6bf4530d210144eaf3c413 and we expect ee82f8f8ad6bf4530d210144eaf3c413 ha1 fd5e9c83ecc96ee Jul 04 16:04:04 S-CSCF [S-CSCF][3694]: INFO: ims_registrar_scscf [cxdx_sar.c:84]: create_return_code(): created AVP successfully : [saa_return_code] - [-2] Jul 04 16:04:04 S-CSCF [S-CSCF][3819]: INFO: ims_registrar_scscf [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp Jul 04 16:04:04 S-CSCF [S-CSCF][3819]: ERROR: ims_usrloc_scscf [usrloc_db.c:235]: db_insert_impurecord(): Unable to insert impu into table [sip:09876993998048@NET.SYRIATEL] Jul 04 16:04:04 S-CSCF [S-CSCF][3819]: ERROR: ims_usrloc_scscf [udomain.c:580]: insert_impurecord(): error inserting contact into db Jul 04 16:04:04 S-CSCF [S-CSCF][3819]: ERROR: ims_usrloc_scscf [impurecord.c:974]: update_impurecord(): Unable to insert new IMPU for <sip:09876993998048@NET.SYRIATEL> Jul 04 16:04:04 S-CSCF [S-CSCF][3819]: ERROR: ims_registrar_scscf [save.c:809]: update_contacts(): Unable to update impurecord for <sip:09876993998048@NET.SYRIATEL> Jul 04 16:04:04 S-CSCF [S-CSCF][3819]: ERROR: ims_registrar_scscf [cxdx_sar.c:253]: async_cdp_callback(): Error processing REGISTER could any one tell me where was my wrong and why it can't write on the DB & thanks in advance

6 years

Kamailio Anycast

by Mike Little

Hello, Sorry if this has already been answered but can Kamailio be configured to support clustering and use Anycast? We are looking to use Kamailio as a front end to Asterisk as the registar and presence server. If this is supported, are there any documents that explain how to configure this type of setup? Thanks!

6 years

IMS usage of Kamailio

by Akib Sayyed

Dear All I am willing to try Kamailio as IMS. before i try i would like to know following points - in Kamailio i see diameter support and authentication I-CSCF, P-CSCF, S-CSCF charging, QOS, ISC implemented but what about TAS do i need TAS seperately - I see that there is HOW-TO wiki , in how to wiki you are using FHoSS as HSS , can we use commercial/any other hss (afaik its using diameter so any HSS will do)? - Is there any configuration online available kamailio as IMS? - Are all IMS modules of Kamailio can be installed on one server or need each module on same machine (i am using IMS only for testing 1 or 2 calls at a time)

6 years

Having trouble getting presence working with Polycom VVX phones

by Justin Foley

Hey everyone. I've set up a kamailio server on a local dev box and running the phones on the same subnet as it to avoid any NAT issues. Seems to work fine, phones register & can call eachother and hear voice but the issue I'm running into is I can't seem to get presence to work. I've enabled it in the kamailio.cfg file with #!WITH_PRESENCE but if I go into "do not disturb" or try to call on phone1, it's not indicated on phone2. Also running ngrep on port 5060, I'm not seeing the anything regarding presence being sent over the SIP protocol.

6 years

$rs printed null

by Andrew Chen

Hi community, So I'm running 4.1.5 Kam version and I wanted to print out $rs variable. It printed out <null> right after the 183 session. Should it print something? What our server side sent is this: INVITE 100 183 488 or 487 And this is the output in kam logs: Jun 28 15:05:49 sjomainfnsg51 /usr/local/sbin/*kamailio*[15215]: INFO: <script>: [4975Fz-ses1-414b02f5R68422169(a)192.168.0.22][2][CSeq 1] fuze_for_mac/99.99.99999 Reply status <null> detected... any thoughts? Thanks -- Andy Chen -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

6 years

Multiple aliases in the Request Message

by Borislav Gergov

Hello, what is the proper way for kamailio nathelper module to handle multiple aliases in the request . For example We have ACK message that looped in the kamailio because is not forward to user phone: ACK sip:xxxxxx@10.10.10.32:38416;alias=192.168.129.135~5060~1;alias=192.168.205.32~38416~1 SIP/2.0 Via: SIP/2.0/UDP 192.168.146.174:46248 ;branch=z9hG4bK-524287-1---5b14eec905adf6ce Max-Forwards: 70 Route: <sip:mo@192.168.129.133;lr=on;ftag=c7d62d68;did=8a1.bcf2;rm=8> Route: <sip:mo@192.168.129.135;lr=on;ftag=c7d62d68;did=8a1.121> Route: <sip:mt@192.168.129.135;lr=on;ftag=c7d62d68;did=8a1.221> Route: <sip:mt@192.168.129.133;lr=on;ftag=c7d62d68;did=8a1.ccf2;rm=7> Contact: <sip:yyyyy@10.153.146.174:46248;transport=UDP> To: <sip:xxxxxx@domain.net;transport=UDP>;tag=dd9aaf1c From: <sip:yyyyy@domain.net;transport=UDP>;tag=c7d62d68 Call-ID: 5Zogf8chhpYlQRdpaZM4CA.. CSeq: 2 ACK User-Agent: Softphone Content-Length: 0

6 years

Auth and default kami config

by yu＠yu-boot.ru

Hello. Have a question on auth and default kamailio.cfg. Default behavior of kamailio on auth is: Auth initial requests, delete auth headers before forwarding to next hop. In-dialog requests are forwarded "as-is" so all auth related info is propagated to uplinks or just another Kami users. How should it be done correctly or "kamailio-way"? As for now, I just delete auth headers for all in-dialog requests, but I'm not sure it is correct. I looked how it works on softswitches like Yate. Registers and initial Invites are authenticated, ACK is not authenticated, but all other requests like reINVITE and BYE are. How is should be done? Thanks. -- sent from myMail for Android

6 years

[Kamailio]: Parse and Store nosip Message error.

by Zhong, Alec (NSB - CN/Qingdao)

Hi, We are developing a project for parser and store MEGACO message by kamailio. During the testing, we find that kamailio inserts one message only once, but there are duplicated messages in mysql datebase. Did you meet the similar issue before? Could you please share some information for us? Thank you in advance. [Environment/version] Environment: Debian-Jessie, docker image Version: kamialio 5.0.6 docker image. [Description] Kamailio stores one message by calling mysql function once, but there are two same message in DB randomly. Function flow: core->nosip parser-> nosip store. [Kamailio Log] Jun 26 07:17:49 dnt02-elk-control-worker-edge-01 journal: }]#033[0;39;49m#033[0;33;49m 5(22) CRITICAL: nosip [megaco_capture.c:49]: megaco_error_code(): No error in MEGCO! Jun 26 07:17:49 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: nosip [megaco_capture.c:406]: megaco_capture(): No error code.#033[0;39;49m#033[0;33;49m 5(22) CRITICAL: nosip [megaco_capture.c:269]: megaco_capture_store(): az_megaco_tmstamp(1529997468887999)//debug log for message, this is duplicated message in mysql. Jun 26 07:17:49 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: nosip [megaco_capture.c:305]: megaco_capture_store(): insert into homer table: [megaco_capture_all_20180626] Jun 26 07:17:49 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: nosip [megaco_capture.c:308]: megaco_capture_store(): storing info... Jun 26 07:17:50 dnt02-elk-control-worker-edge-01 journal: I0626 07:17:50.802482 1 event.go:218] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"homer-data-dashboard", UID:"136b3329-78f1-11e8-8d74-0050568fb61f", APIVersion:"v1", ResourceVersion:"2841229", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' storageclass.storage.k8s.io "glusterfs-storageclass" not found Jun 26 07:17:50 dnt02-elk-control-worker-edge-01 journal: I0626 07:17:50.802660 1 event.go:218] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"homer-data-semaphore", UID:"1369de0b-78f1-11e8-8d74-0050568fb61f", APIVersion:"v1", ResourceVersion:"2841228", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' storageclass.storage.k8s.io "glusterfs-storageclass" not found Jun 26 07:17:50 dnt02-elk-control-worker-edge-01 journal: I0626 07:17:50.802706 1 event.go:218] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"homer-data-mysql", UID:"136e804c-78f1-11e8-8d74-0050568fb61f", APIVersion:"v1", ResourceVersion:"2841231", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' storageclass.storage.k8s.io "glusterfs-storageclass" not found Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: I0626 07:17:51.223950 1 trace.go:76] Trace[1532720894]: "GuaranteedUpdate etcd3: *core.Endpoints" (started: 2018-06-26 07:17:48.964454076 +0000 UTC m=+1830051.184603352) (total time: 2.259414864s): Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Trace[1532720894]: [2.259374311s] [2.258991423s] Transaction committed Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: I0626 07:17:51.224190 1 trace.go:76] Trace[557711900]: "Update /api/v1/namespaces/kube-system/endpoints/kube-scheduler" (started: 2018-06-26 07:17:48.964209184 +0000 UTC m=+1830051.184358457) (total time: 2.259905913s): Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Trace[557711900]: [2.259791237s] [2.259619876s] Object stored in database Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: 2018-06-26 07:17:51.220413 W | wal: sync duration of 1.446041666s, expected less than 1s Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: I0626 07:17:51.225704 1 trace.go:76] Trace[656020708]: "GuaranteedUpdate etcd3: *core.Node" (started: 2018-06-26 07:17:50.573518495 +0000 UTC m=+1830052.793667844) (total time: 652.126103ms): Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Trace[656020708]: [651.833583ms] [647.806507ms] Transaction committed Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 5(22) CRITICAL: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/parser/parse_fline.c:244]: parse_first_line(): parse_first_line: bad request first line Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/parser/parse_fline.c:246]: parse_first_line(): at line 0 char 29: Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/parser/parse_fline.c:252]: parse_first_line(): parsed so far: MEGACO/2 [175.15.0.254]:32791 Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 29) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/parser/msg_parser.c:601]: parse_msg(): invalid message Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/parser/msg_parser.c:676]: parse_msg(): ERROR: parse_msg: message=<MEGACO/2 [175.15.0.254]:32791 Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Transaction = 359 { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Context = - { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Notify = ROOT { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: ObservedEvents = 1111 { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: 20180626T15175177: Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: it/ito Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: } Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: } Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: } Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: }> Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/pvapi.c:1377]: pv_printf(): no more space for spec value Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/pvapi.c:1386]: pv_printf(): buffer overflow -- increase the buffer size... Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: nosip [megaco_capture.c:344]: megaco_capture(): Dump msg:[MEGACO/2 [175.15.0.254]:32791 Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Transaction = 359 { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Context = - { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: Notify = ROOT { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: ObservedEvents = 1111 { Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: 20180626T15175177: Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: it/ito Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: } Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: } Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: } Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: }]#033[0;39;49m#033[0;33;49m 3(20) CRITICAL: nosip [megaco_capture.c:49]: megaco_error_code(): No error in MEGCO! Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: nosip [megaco_capture.c:406]: megaco_capture(): No error code.#033[0;39;49m#033[0;33;49m 3(20) CRITICAL: nosip [megaco_capture.c:269]: megaco_capture_store(): az_megaco_tmstamp(1529997471897950)//debug log, this is the non-dup message. Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: nosip [megaco_capture.c:305]: megaco_capture_store(): insert into homer table: [megaco_capture_all_20180626] Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: nosip [megaco_capture.c:308]: megaco_capture_store(): storing info... Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 26 07:17:51 dnt02-elk-control-worker-edge-01 journal: #033[0;39;49m#033[0;33;49m 3(20) CRITICAL: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Best Regards, Alec Zhong

6 years

Re: [SR-Users] Understanding 5XX stats in Kamailio

by Konstantin Polyakov

Hello Daniel, Is there information about stats - what is implemented, what is not implemented? I have the similar questions, it would be nice to be informed what stats can be use and what stats should be skipped. Thank you. > > >Message: 8 >Date: Fri, 29 Jun 2018 09:46:21 +0200 >From: Daniel-Constantin Mierla < miconda(a)gmail.com > >To: "Kamailio (SER) - Users Mailing List" >< sr-users(a)lists.kamailio.org >, Joel Serrano < joel(a)textplus.com > >Subject: Re: [SR-Users] Understanding 5XX stats in Kamailio >Message-ID: < cbd84f94-8bb1-ddc3-b901-5743360c1fb9(a)gmail.com > >Content-Type: text/plain; charset=utf-8 > >Hello, > >I haven't implemented those stats, but should be like: > > >On 28.06.18 23:54, Joel Serrano wrote: >> Does anyone know the difference between these metrics?? >> >> core:rcv_replies_5xx > >- the number of 5xx replies received by kamailio > >> sl:5xx_replies > >- the number of 5xx replies generated by kamailio via sl module functions > >> tmx:5xx_transactions > >- the number of transactions that completed with a 5xx response > >> >> Specially between core and tmx? > >Some of received 5xx responses may be due to stateless forwarding, a >matter of config file, thus some of them do not match transactions. > >Cheers, >Daniel > >-- >Daniel-Constantin Mierla -- www.asipto.com >www.twitter.com/miconda -- www.linkedin.com/in/miconda >Kamailio World Conference -- www.kamailioworld.com > > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >sr-users mailing list >sr-users(a)lists.kamailio.org >https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > >------------------------------ > >End of sr-users Digest, Vol 157, Issue 30 >***************************************** С уважением, Константин Поляков.

6 years

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users July 2018