17 Jun
2007
17 Jun
'07
9:21 p.m.
hi guys!
can somebody explain me how SEMS works with SER/OpenSER.
As I conceive proxy sends requests to SEMS via unix socket. Then SEMS
needs constructs reply or new request and ask proxy to send it. But
where reply come to proxy? into onreply_route[0] block? is it possible
to use t_on_reply() function when initial request writing to SEMS to ask
proxy to use specific onreply_route[] block?
Thanks for advise!
--
CU,
Victor Gamov
18 Jun
18 Jun
12:57 a.m.
Hello,
SER directly sends out the reply message to next_hop without going
through the route script. If you need to process outgoing messages from
SEMS, either modify them directly in SEMS, or use one SER instance as
SIP stack for SEMS on e.g. port 5070, and have one SER proxy
record-route. This way you get replies and followup requests on your
record-routing proxy.
Stefan
Victor Gamov wrote:
hi guys!
can somebody explain me how SEMS works with SER/OpenSER.
As I conceive proxy sends requests to SEMS via unix socket. Then SEMS
needs constructs reply or new request and ask proxy to send it. But
where reply come to proxy? into onreply_route[0] block? is it possible
to use t_on_reply() function when initial request writing to SEMS to ask
proxy to use specific onreply_route[] block?
Thanks for advise!
--
Stefan Sayer
Media Services Development
stefan.sayer(a)iptego.de
www.iptego.de
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
9:29 a.m.
Stefan Sayer wrote:
Hello,
SER directly sends out the reply message to next_hop without going
through the route script. If you need to process outgoing messages from
SEMS, either modify them directly in SEMS, or use one SER instance as
SIP stack for SEMS on e.g. port 5070, and have one SER proxy
record-route. This way you get replies and followup requests on your
record-routing proxy.
ok, I see
thanks
--
CU,
Victor Gamov
10:19 a.m.
New subject: [Users] OpenSer loops
Hello,
my Openser is looping whenever an external call comes in. Internal calls
from the same domain (route 1) are ok. Also from internal to external
domains.
I have set aliases in openser.cfg, I have set the hosts file but it
still loops.
Below you'll find the config and at the end an ngrep output on lo which
shows that
t_relay() is trying to deliver the invite message from
192.168.178.10:5060 -> 192.168.178.10:5060
in an endless loop until the emssage becomes too big due to increasing #
of via headers (see last message at the end of the mail).
Just to mention: Openser runs in a virtual environment (VirtualBox Host
br0=>tap1=> Client eth0)
Can anybody help? What am I doing wrong?
Here is my conf:
/etc/hostname
=============
sip
/etc/hosts
=============
127.0.0.1 localhost
192.168.178.10 sip2.mydomain.de sip.mydomain.de sip
======================================================================
#
# $Id: openser.cfg
#
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
children=4
log_facility=LOG_LOCAL7
#Add the xlog module:
loadmodule "/usr/lib/openser/modules/xlog.so"
# Uncomment these lines to enter debugging mode
#fork=no
#log_stderror=yes
check_via=yes
port=5060
listen=192.168.178.10:5060
#listen=0.0.0.0:5060
alias=udp:192.168.178.10
alias=udp:sip2.mydomain.de:5060
alias=udp:0.0.0.0:5060
alias=udp:127.0.0.1:5060
alias=udp:localhost:5060
# ------------------ module loading ----------------------------------
#set module path
mpath="/usr/lib/openser/modules/"
# Uncomment this if you want to use SQL database
loadmodule "mysql.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
loadmodule "nathelper.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "auth.so"
loadmodule "auth_db.so"
#domains
loadmodule "domain.so"
#Accounting
loadmodule "acc.so"
#siptrace
loadmodule "siptrace.so"
#AVP
loadmodule "avpops.so"
#Mediaproxy
loadmodule "mediaproxy.so"
# ----------------- setting module-specific parameters ---------------
# -- mi_fifo params --
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
# -- usrloc params --
modparam("usrloc", "nat_bflag", 2) # Nat-Flag=2
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module
modparam("auth_db", "calculate_ha1", 1)
# If you set "calculate_ha1" parameter to yes (which true in this config),
# uncomment also the following parameter)
modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# -- Domain Params --
modparam("domain", "db_url",
"mysql://openserro:openserro@localhost/openser")
modparam("domain", "db_mode", 1) # Use caching
# --Accounting Params --
modparam("acc", "log_flag", 2) # Use Flag #2
modparam("acc", "log_level", 2) # Set log_level to 2
modparam("acc", "log_extra",
"ua=$hdr(User-Agent);uuid=$avp(i:123)")
modparam("acc", "early_media", 1)
modparam("acc", "failed_transaction_flag", 2)
modparam("acc", "report_ack", 1)
modparam("acc", "report_cancels", 1)
modparam("acc", "detect_direction", 1)
modparam("acc", "log_extra",
"ua=$hdr(User-Agent);uuid=$avp(i:123)")
modparam("acc", "db_flag", 2)
modparam("acc", "db_missed_flag", 2)
modparam("acc", "db_table_acc", "acc") # Default
value is "acc"
modparam("acc", "db_table_missed_calls", "missed_calls") #
Default
value is "missed_calls"
modparam("acc", "db_url",
"mysql://openser:openserrw@localhost/openser")
# -- siptrace Parameters --
modparam("siptrace", "db_url",
"mysql://openser:openserrw@localhost/openser")
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "traced_user_avp", "$avp(i:123)") #
bringt nichts
# -- Mediaproxy params --
modparam("mediaproxy", "mediaproxy_socket",
"/var/run/mediaproxy.sock")
modparam("mediaproxy", "natping_interval", 60)
##modparam("registrar", "nat_flag", 2) #Nat-Flag=2
# -- Nathelper module
modparam("nathelper", "natping_interval", 10)
modparam("nathelper", "rtpproxy_disable", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{
setflag(2); # set for accounting (the same value as in log_flag!)
acc_log_request("Some comment");
sip_trace();
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("1")) {
sl_send_reply("483","Too Many Hops!");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
# apply loose (normal) routing rules
if(!is_method("REGISTER")) {
if(loose_route()) {
route(2);
}
}
if (is_uri_host_local()){
xlog("L_INFO", "Step 5a: is_uri_host_local() => To: is
local");
}
# NAT test
if (client_nat_test("3") && !is_present_hf("Route")){
setflag(8); # flag for NAT
force_rport();
fix_contact(); # Replace IP:Port
append_hf("P-hint: NAT\r\n");
}
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!method=="REGISTER") {
record_route();
}
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (!is_from_local()) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
if (is_method("INVITE")){
# Is To: Local adresse
if (is_uri_host_local()){
setflag(8); # flag for NAT
force_rport();
fix_contact(); # Replace IP:Port
append_hf("P-hint: NAT\r\n");
route(1);
}else{ # to: is no local adress
route(2);
}
} else {
route(2);
}
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (is_from_local()) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
if (!www_authorize("192.168.178.10", "subscriber")) {
www_challenge("192.168.178.10", "0");
exit;
};
acc_log_request("Some comment");
save("location");
exit;
};
lookup("aliases");
if (!is_from_local()) {
append_hf("P-hint: outbound alias\r\n");
route(1);
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
#sl_send_reply("404", "Not Found");
route(2);
#exit;
};
append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
route[1] {
#local route without NAT
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
sip_trace();
if (!t_relay()) {
sl_reply_error();
};
exit;
}
route[2]{
#route external via proxy
if (isflagset(8)){
if (is_method("INVITE")){
t_on_reply("1");
t_on_failure("1");
use_media_proxy();
fix_nated_contact();
} else if (is_method("BYE|CANCEL")) {
end_media_session();
} #invite
} #flagset 8
if (is_uri_host_local()){
lookup("aliases");
}
sip_trace();
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Add for mediaproxy
onreply_route[1] {
if (status =~ "(183)|(2[0-9][0-9])") {
if (client_nat_test("1")) {
fix_contact();
}
use_media_proxy();
}
}
failure_route[1] {
end_media_session();
}
Output of ngrep for lo
======================================
U(17) 192.168.178.10:5060 -> 192.168.178.10:5060
INVITE sip:oliver@sip2.mydomain.de;method=INVITE
SIP/2.0..Record-Route:
<sip:192.168.178.10;lr=on;ftag=4147186348102458>..Record-Route:
<sip:217.74.179.2
9;ftag=4147186348102458;lr=on>..Via: SIP/2.0/UDP
192.168.178.10;branch=z9hG4bK0df2.6a254967.0..Via: SIP/2.0/UDP
217.74.179.29;rport=5060;branch=z9hG4bK0d
f2.53376a54.0..Via: SIP/2.0/UDP
217.24.11.186:5530;branch=z9hG4bK4430225740333751..From:
<sip:myname@sipprovider.net>;tag=4147186348102458..To: <sip:
oliver@sip2.mydomain.de>..Call-ID: 4
883202677351876@sipprovider.net..CSeq: 2 INVITE..Contact:
<sip:myname@217.74.179.29:5060>..Proxy-Authorization:
Digest username="sipprovider/myname", realm="sipprovider.net",
nonce="46762df8ff60c6dc11695a491c1538cd9bec5471",
uri="sip:oliver@sip2.mydomain.de;method=
INVITE", response="6481c0c01cc11eae67aca5dd3d72a87e",
algorithm=MD5..Max-Forwards: 68..Expires: 1800..Content-Type:
application/BRAVIS_BETA..Content-Leng
th: 384..P-hint: OUTBOUND ON INTERNET..P-hint: outbound..P-hint:
NAT....ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAABPEKIMAJKBFABAAAAAAADABAAAFFAMDHNAEAAAAAAGIGPH
DHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFABAAAAAAABABAAABFAMDHNAEAAAAAAGIGPHDHEIAGGANADAC
JDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAPPPPPPEKAFAAAAAAHDHCGGGMHIAAAAAAAAABPEKIMAJKBF
#
U(17) 192.168.178.10:5060 -> 192.168.178.10:5060
SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP
192.168.178.10;branch=z9hG4bK0df2.6a254967.0;rport=5060..Via:
SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG
4bK0df2.53376a54.0..Via: SIP/2.0/UDP
217.24.11.186:5530;branch=z9hG4bK4430225740333751..From:
<sip:myname@sipprovider.net>;tag=4147186348102458..To:
<sip:oliver@sip2.mydomain.de>..Call-ID: 4
883202677351876@sipprovider.net..CSeq: 2 INVITE..Server: OpenSER
(1.2.0-notls (i386/linux))..Content-Length: 0....
#
U(17) 192.168.178.10:5060 -> 192.168.178.10:5060
INVITE sip:oliver@sip2.mydomain.de;method=INVITE
SIP/2.0..Record-Route:
<sip:192.168.178.10;lr=on;ftag=4147186348102458>..Record-Route:
<sip:192.168.178.
10;lr=on;ftag=4147186348102458>..Record-Route:
<sip:217.74.179.29;ftag=4147186348102458;lr=on>..Via: SIP/2.0/UDP
192.168.178.10;branch=z9hG4bK0df2.7a2549
67.0..Via: SIP/2.0/UDP
192.168.178.10;rport=5060;branch=z9hG4bK0df2.6a254967.0..Via:
SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bK0df2.53376a54.0..
Via: SIP/2.0/UDP
217.24.11.186:5530;branch=z9hG4bK4430225740333751..From:
<sip:myname@sipprovider.net>;tag=4147186348102458..To: <sip:oliver@sip2.tel
efaks.de>..Call-ID: 4 883202677351876@sipprovider.net..CSeq: 2
INVITE..Contact: <sip:myname@192.168.178.10:5060>..Proxy-Authorization:
Digest usernam
e="sipprovider/myname", realm="sipprovider.net",
nonce="46762df8ff60c6dc11695a491c1538cd9bec5471",
uri="sip:oliver@sip2.mydomain.de;method=INVITE", respo
nse="6481c0c01cc11eae67aca5dd3d72a87e", algorithm=MD5..Max-Forwards:
67..Expires: 1800..Content-Type:
application/BRAVIS_BETA..Content-Length: 384..P-h
int: OUTBOUND ON INTERNET..P-hint: outbound..P-hint: NAT..P-hint:
outbound..P-hint:
NAT....ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAABPEKIMAJKBFABAAAAAAADABAAAFFA
MDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFABAAAAAAABABAAABFAMDHNAEAAAAAAG
IGPHDHEIAGGANADACJDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAPPPPPPEKAFAAAAAAHDHCGGGMHIAAAA
AAAAABPEKIMAJKBF
#
U(17) 192.168.178.10:5060 -> 192.168.178.10:5060
SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP
192.168.178.10;branch=z9hG4bK0df2.7a254967.0;rport=5060..Via:
SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9h
G4bK0df2.6a254967.0..Via: SIP/2.0/UDP
217.74.179.29;rport=5060;branch=z9hG4bK0df2.53376a54.0..Via: SIP/2.0/UDP
217.24.11.186:5530;branch=z9hG4bK443022574
0333751..From: <sip:myname@sipprovider.net>;tag=4147186348102458..To:
<sip:oliver@sip2.mydomain.de>..Call-ID: 4
883202677351876@sipprovider.net..CSeq: 2
INVITE..Server: OpenSER (1.2.0-notls (i386/linux))..Content-Length: 0....
#
U(17) 192.168.178.10:5060 -> 192.168.178.10:5060
INVITE sip:oliver@sip2.mydomain.de;method=INVITE
SIP/2.0..Record-Route:
<sip:192.168.178.10;lr=on;ftag=4147186348102458>..Record-Route:
<sip:192.168.178.
10;lr=on;ftag=4147186348102458>..Record-Route:
<sip:192.168.178.10;lr=on;ftag=4147186348102458>..Record-Route:
<sip:217.74.179.29;ftag=4147186348102458;l
r=on>..Via: SIP/2.0/UDP
192.168.178.10;branch=z9hG4bK0df2.8a254967.0..Via: SIP/2.0/UDP
192.168.178.10;rport=5060;branch=z9hG4bK0df2.7a254967.0..Via: SIP/
2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bK0df2.6a254967.0..Via:
SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bK0df2.53376a54.0..Via:
SIP/2.0/UD
P 217.24.11.186:5530;branch=z9hG4bK4430225740333751..From:
<sip:myname@sipprovider.net>;tag=4147186348102458..To:
<sip:oliver@sip2.mydomain.de>..Call
-ID: 4 883202677351876@sipprovider.net..CSeq: 2 INVITE..Contact:
<sip:myname@192.168.178.10:5060>..Proxy-Authorization: Digest
username="sipprovider/myname", realm="sipprovider.net",
nonce="46762df8ff60c6dc11695a491c1538cd9bec5471",
uri="sip:oliver@sip2.mydomain.de;method=INVITE", response="6481c0c01c
c11eae67aca5dd3d72a87e", algorithm=MD5..Max-Forwards: 66..Expires:
1800..Content-Type: application/BRAVIS_BETA..Content-Length:
384..P-hint: OUTBOUND O
N INTERNET..P-hint: outbound..P-hint: NAT..P-hint: outbound..P-hint:
NAT..P-hint: NAT..P-hint: outbound..P-hint:
NAT....ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAA
BPEKIMAJKBFABAAAAAAADABAAAFFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFAB
AAAAAAABABAAABFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAP
PPPPPEKAFAAAAAAHDHCGGGMHIAAAAAAAAABPEKIMAJKBF
#
=============================================================================
Here is the last message before it becomes too big:
INVITE sip:oliver@sip2.mydomain.de;method=INVITE SIP/2.0
Record-Route: <sip:192.168.178.10;lr=on;ftag=4330431582305345>
Record-Route: <sip:192.168.178.10;lr=on;ftag=4330431582305345>
Record-Route: <sip:192.168.178.10;lr=on;ftag=4330431582305345>
Record-Route: <sip:192.168.178.10;lr=on;ftag=4330431582305345>
Record-Route: <sip:192.168.178.10;lr=on;ftag=4330431582305345>
Record-Route: <sip:217.74.179.29;ftag=4330431582305345;lr=on>
Via: SIP/2.0/UDP 192.168.178.10;branch=z9hG4bKd018.3a76c8c6.0
Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.2a76c8c6.0
Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.1a76c8c6.0
Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.0a76c8c6.0
Via: SIP/2.0/UDP 192.168.178.10;rport=5060;branch=z9hG4bKd018.f976c8c6.0
Via: SIP/2.0/UDP 217.74.179.29;rport=5060;branch=z9hG4bKd018.e28f70f2.0
Via: SIP/2.0/UDP 217.24.11.186:5530;branch=z9hG4bK4500476364380471
From: <sip:myname@sipprovider.net>;tag=4330431582305345
To: <sip:oliver@sip2.mydomain.de>
Call-ID: 4 402347358184803(a)sipprovider.net
CSeq: 2 INVITE
Contact: <sip:myname@192.168.178.10:5060>
Proxy-Authorization: Digest username="sipprovider/myname",
realm="sipprovider.net",
nonce="46762f3a40204b26064717316a0639b27a0980e5",
uri="sip:oliver@sip2.mydomain.de;method=INVITE",
response="87d50432f5ca4b2cbe245863957c0fae", algorithm=MD5
Max-Forwards: 64
Expires: 1800
Content-Type: application/BRAVIS_BETA
Content-Length: 384
P-hint: OUTBOUND ON INTERNET
P-hint: outbound
P-hint: NAT
P-hint: outbound
P-hint: NAT
P-hint: NAT
P-hint: outbound
P-hint: NAT
P-hint: NAT
P-hint: outbound
P-hint: NAT
P-hint: NAT
P-hint: outbound
P-hint: NAT
ABAAAAAALMAAAAAABGNKMIEHAFAAAAAAABPEKIMAJKBFABAAAAAAADABAAAFFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDABFBKIMAJKBFABAAAAAAACABAAADFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDBILCKIMAJKBFABAAAAAAABABAAABFAMDHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLACIEHAFJKBFABAAAAAAAEABAAAHEAJMHNAEAAAAAAGIGPHDHEIAGGANADACJDAGIIAHBDLKALBINJJKBFABAAAAAADDABAAPPPPPPEKAFAAAAAAHDHCGGGMHIAAAAAAAAABPEKIMAJKBF
27 Aug
27 Aug
6:32 p.m.
New subject: [OpenSER-Users] Call Forking
Does anyone have an idea how OpenSER behaves in terms of call forking?
That means:
- A sip client A registers at OpenSER from IP adress A,
- then another SIP client B registers at OpenSER from IP adress B with
the same credentials while A ist still registered.
Question 1:
- does OpenSER allow both clients to register with the same credentials?
Question 2:
- can this be switched on/off somewhere?
Question 3:
- in case it works, can an incoming call being routed to A and B
simulaneously?
Thanks for your help
Peter
6:52 p.m.
New subject: [OpenSER-Users] Call Forking
Hi there Peter,
answers bellow:
Question 1:
- does OpenSER allow both clients to register with the same credentials?
Yes, this
is the default behavior of openser.
Question 2:
- can this be switched on/off somewhere?
You can limit it here:
http://www.openser.org/docs/modules/1.2.x/registrar.html#AEN199
or by using some sort of avp tricks.
Question 3:
- in case it works, can an incoming call being routed to A and B
simulaneously?
Yes, calls would be forked to both entries in location table.
Cheers,
DanB
On 8/27/07, Peter P GMX <Prometheus001(a)gmx.net> wrote:
> Does anyone have an idea how OpenSER behaves in terms of call forking?
>
> That means:
> - A sip client A registers at OpenSER from IP adress A,
> - then another SIP client B registers at OpenSER from IP adress B with
> the same credentials while A ist still registered.
>
Question 1:
- does OpenSER allow both clients to register with the same credentials?
>
Question 2:
- can this be switched on/off somewhere?
>
Question 3:
- in case it works, can an incoming call being routed to A and B
simulaneously?
>
> Thanks for your help
> Peter
>
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
6327
days inactive
6398
days old
5 comments
4 participants
participants (4)
-
Dan-Cristian Bogos -
Peter P GMX -
Stefan Sayer -
Victor Gamov