On Wed, Apr 29, 2009 at 7:39 AM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

Hello,

$du is set by usrloc only if there is a received value in the location record. Can you check if you have it in db?

Cheers,
Daniel

On 04/29/2009 11:45 AM, Brandon Armstead wrote:

Daniel,

Yes I'm doing an append_hf("X-Duri: $du\r\n"); inside of branch_route[] i.e.:

branch_route[2]
{
if(isbflagset(4)){
# thats me!
} else {
# at this point X-Duri is null, so we are not saving it from the lookup?
# we need to save this to pass onto Proxy B, however the value is NULL at this point, and at the point of Proxy B (when received).
append_hf("X-Duri: $avp(s:duri)\r\n");
if(isbflagset(6)){
$du = "sip:PROXY_B;transport=udp;";
}
}

xlog("L_INFO", "[$ci][branch_route][$T_branch_idx] ru=$ru fu=$fu tu=$tu si=$si flag=$bF du=$du");
}

Then when X-Duri reaches Proxy B, if I see the INVITE comes from Proxy A, I take X-Duri and restore "$du" with the correct value.

However this is causing issues now as the value is <null>, I've tried saving $du into avp after looking up usrloc, I've tried simply calling $du in branch_route[], and I've tried saving $du in loose_route() into an avp, all to no avail.

What am I missing here as far as passing the value of $du from branch route to header, to pass along to Proxy B.

Thanks again!

On Wed, Apr 29, 2009 at 2:42 AM, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote:

On 04/29/2009 11:32 AM, Brandon Armstead wrote:

Daniel,

It looks like you helped me find part of the problem,
apparently Proxy A was sharing same branch flag as the one I
used to distinguish which proxy it was. I corrected this and
now branch flag for branch 1 is 00000060, and branch 2 is
00000040, however now both branches are routed appropriately
to the correct server, however the X-Duri (to restore to in
the INVITE) is null.

I may not followed all discussion branch - the X-Duri is a header
you append to the message? If yes, it is not visible immediately
in the script, but you can see it when the messages is ent to the
network.

Do I need to save this value into an AVP after
lookup("location")?

What you need to do with it? Where is its values taken from?

Cheers,
Daniel

Or should it be readily available in branch_route[], and for
some reason my variable is null?

P.S. (recap)
Proxy A NAT Branch Flag: 5
Proxy B NAT Branch Flag: 5

(Problem existed as used Flag 5 to distinguish "itself" as
proxy) -- changed this to 4 so now:

Proxy A NAT Branch Flag: 4
Proxy B NAT Branch Flag: 6

Calls are routed to Proxy B

X-Duri: <null> (as it is null in Proxy A). I'm
append_hf(X-Duri: $du) inside of branch_route[].

Thanks!

On Wed, Apr 29, 2009 at 2:17 AM, Daniel-Constantin Mierla
<miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>> wrote:

On 04/29/2009 11:11 AM, Brandon Armstead wrote:

Daniel,

No that would be the UAC (I have two clients behind the
same NAT). The problem is it looks like the branch flag is
not being set for both for some reason (when comparing)
even
though in the database it is the same?

So you have the brach flag for nat and branch flags for next
proxy, right? What is the value of branch flag? The value are
different indeed, but some flags you are looking for might be
set. It is easier spot if you print the hexa format of the
flags
rather than decimal one.

Cheers,
Daniel

Take a look at the flag= value from each of those logs
(this
is one call) to a UAC with two registrations line1/line2.

On Wed, Apr 29, 2009 at 2:02 AM, Daniel-Constantin Mierla
<miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>
<mailto:miconda@gmail.com <mailto:miconda@gmail.com>>>> wrote:

Hello,

On 04/29/2009 10:53 AM, Brandon Armstead wrote:

Hey guys,

Still facing a few challenges and seeing if
any further
input, I'm specifically trying inaki's suggestions /
method,
but here are the current problems:

sip:/etc/kamailio/m4cfgs# tail -f
/var/log/openser.log
| grep
-v -E 'non-local|repeated' | grep branch_route
Apr 29 07:38:05 db06 /sbin/kamailio[21279]:
[77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>>>][branch_route][1]
ru=sip:CALLEE@99.XX.XX.XX:5079
fu=sip:CALLER@sip.example.com
<mailto:sip%3ACALLER@sip.example.com>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>>>

tu=sip:CALLEE@sip.example.com
<mailto:sip%3ACALLEE@sip.example.com>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>>> si=99.XX.XX.XX

flag=96 du=<null>

This call is not sent to Proxy B (this is a
result of bflag
not being set) ???

is the proxy B at 99.XX.XX.XX:5079? If not, then set
$du to the
address of that proxy. It is null in the log above.

Cheers,
Daniel

My question is "Why", I look at the AOR / usrloc and
they both
have the "same exact flags set", this call is
rather sent
directly to UAC endpoint.

---

Apr 29 07:38:05 db06 /sbin/kamailio[21279]:
[77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>
<mailto:77e4c600-147767fb@172.16.1.35
<mailto:77e4c600-147767fb@172.16.1.35>>>>][branch_route][2]
ru=sip:CALLEE@99.XX.XX.XX:5062
fu=sip:CALLER@sip.example.com
<mailto:sip%3ACALLER@sip.example.com>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>>
<mailto:sip%3ACALLER@sip.example.com
<mailto:sip%253ACALLER@sip.example.com>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>>
<mailto:sip%253ACALLER@sip.example.com
<mailto:sip%25253ACALLER@sip.example.com>
<mailto:sip%25253ACALLER@sip.example.com
<mailto:sip%2525253ACALLER@sip.example.com>>>>

tu=sip:CALLEE@sip.example.com
<mailto:sip%3ACALLEE@sip.example.com>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>>
<mailto:sip%3ACALLEE@sip.example.com
<mailto:sip%253ACALLEE@sip.example.com>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>>
<mailto:sip%253ACALLEE@sip.example.com
<mailto:sip%25253ACALLEE@sip.example.com>
<mailto:sip%25253ACALLEE@sip.example.com
<mailto:sip%2525253ACALLEE@sip.example.com>>>> si=99.XX.XX.XX

flag=64 du=sip:PROXY_B;transport=udp;

This call is sent to Proxy B (however Proxy B) -
however the
X-Duri (is null) as it is not existant in Proxy
A's branch
route? should I save this from right after the
lookup("location") result into an avp?

Again, thank you for all and any help, thanks!

On Mon, Apr 27, 2009 at 5:42 PM, Brandon Armstead
<brandon@cryy.com <mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>
<mailto:brandon@cryy.com
<mailto:brandon@cryy.com> <mailto:brandon@cryy.com
<mailto:brandon@cryy.com>>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>
<mailto:brandon@cryy.com <mailto:brandon@cryy.com>>>>> wrote:

Klaus, Inaki, Daniel,

Thanks! Sorry I did not see this email come
through, I'm
going to go ahead and give this method a go,
and I'll
update with
the results, I have optimistic views.

As for the reason I was rewriting $ru and
setting $du to
null, is
because originally when I just changed $du to the
'destination
proxy' it did not seem to work at all (I do
not even
recall
what
exactly what was happening) however I decided
to just
change $ru,
and have the other proxy just "lookup" the usrloc
information
again. Again, this method looks interesting and
I'll let
you guys
know how it goes, thanks for all the input
and help!

Sincerely,
Brandon.

On Fri, Apr 24, 2009 at 1:18 AM, Klaus Darilion
<klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>>>> wrote:

Brandon Armstead schrieb:

Klaus,

So I took you and Inaki's input and
essentially
constructed a setup like so after the
lookup("location") call:

if(isbflagset(1)){
$du = null;
$rd = "P1";
} else if(isbflagset(2)){
$du = null;
$rd = "P2";
} else if(isbflagset(3)){
$du = null;
$rd = "P3";
} else if(isbflagset(4)){
$du = null;
$rd = "P4";
}

1. The above code has to be in the
branch_route
block -
otherwise multiple registrations of a single
user are not
handled correctly.

2. you are rewriting the RURI. You should
not do
that
as some
clients wants to the in the RURI the Contact
provided
during
REGISTER.

3. probably you use fix_nated_register() to
store the
public
IP:port of the client too. After lookup, this
information is
written to DURI. Thus, by setting $du you
overwrite
this info.
You should put it into a special header
so that
you can
restore it in the other proxy.

Here a snippet how it should work
(untested, no
warranty): ( I
use the term "originating" proxy for the
proxy which
received
the INVITE and the term "serving" proxy
for the
proxy which
handles the connection/registration of a
certain SIP
client).

e.g:
Alice -----INVITE----->
P1------->P2----->Bob2
/ \
/ \
/ V
V P3---->Bob3
Bob1

Bob's client Bob1 is connected to P1.
Bob's client Bob2 is connected to P2.
Bob's client Bob3 is connected to P3.

So, P1 is the originating proxy. P2 is the
serving proxy of
Bob2. ....

We do NAT traversal (note: we must not call
fix_nated_contact() for messages sent
between the
proxies!):
the originating proxy for the call-leg to the
caller, the
serving proxy for the call-leg to the callee.
The RTP proxy will be managed by the
originating
proxy
only.

route{
if (loose_route()) {
... additional loose route processing...
if (check_route_param("rtpproxy=yes")) {
force_rtp_proxy();
setbflag(7);
}

# downstream: in-dialog request is in
the same
direction as the
# initial request
if ( (check_route_param("nat=caller") &&
is_direction("downstream"))
|| (check_route_param("nat=callee") &&
is_direction("upstream"))) {
fix_nated_contact();
} else if (check_route_param("nat=both") {
fix_nated_contact();
setbflag(8);
} else {
setbflag(8);
}

t_on_reply("1");
t_relay();
exit();
}
...

# I am proxy 1
if ((src_ip=ip.of.proxy.2) ||
(src_ip=ip.of.proxy.3)...) {
# request comes from other proxy, that
means I
am the
# serving proxy
# do not lookup(), RURI is already set and
# DURI is provided in our X-DURI header
$du = $header(X-DURI);
# we do not care about an RTP proxy because
that's the
task
of the
# proxy which performed the lookup() (the
originating
proxy)
# add some record-route cookie to mark
that we
should
perform
# SIP NAT traversal for the callee
add_rr_param(";nat=callee");
# activate reply_route to
fix_nated_contact of
callee
setbflag(8); # flag 8 = fix contact
t_on_reply("1");
record_route();
t_relay();
exit;
}

...
# a new request - thus I am the
originating proxy

if ($dU looks like phone number) {
... route to Gateway....
exit;
}

if (!lookup("location")) {
sl_send_reply("404","not found");
exit;
}
# activate branch route to have dedicated
routing per
branch
t_on_branch("1");

# activate reply route to activate RTP proxy
t_on_reply("1");

# NAT traversal
fix_nated_contact();

record_route();
t_relay();
exit;
}

branch_route[1]{
if(isbflagset(1)){
# oh, that's me

# add some record-route cookie to mark
that we
should
perform
# SIP NAT traversal for the callee and
caller
add_rr_param(";nat=both");

# add some record-route cookie to mark
that we are
# in charge for the RTP proxy
add_rr_param(";rtpproxy=yes");

force_rtp_proxy();
setbflag(7); # flag 7 = RTP proxy
} else {
# add some record-route cookie to mark
that we
should
perform
# SIP NAT traversal for the caller
add_rr_param(";nat=caller");

# we have to route the request to the
serving
proxy
# write DURI in the header
append_hf("X-DURI: $du");
if(isbflagset(2)){
$du = sip:ip.of.proxy.2;transport=udp;
} else if(isbflagset(3)){
$du = sip:ip.of.proxy.3;transport=udp;
} else if(isbflagset(4)){
$du = sip:ip.of.proxy.4;transport=udp;
}
}
}

reply_route[1]{
if (isbflagset(7) &&
has_body("application/sdp")) {
force_rtp_proxy()
}
if (isbflagset(8)) {
fix_nated_contact()
}
}

Note: this code does not care about the
received
socket
of the
proxy. Thus it works if the proxy listens
only
on one port.

regards
klaus

On each Proxy, I changed the code
appropriately
excluding
the Proxy from itself (so it does not
forward to
itself).
I'm noticing weird behavior however
as it
seems as if
what is happening is it created other
issues
such as:

[INCOMING SERVER] -> P1 -> P2 -> P1
-> (loop?)

Also I setup this test amongst two
development
servers (in
which case it worked without issues).
Once I
included in
more development instances into the
ring it
seemed
as if
the flags were being set when they should
not be?

I.e. I placed a call FROM UA1 (with
bflag 5 SET)
From the
above example configuration ^ code.
If you
notice
(flag
5) is missing. To UA2 (Flag 3),
again this
looked
to be
doing some strange things such as
acting as
if another
flag was set when it should not have
been, thus
forwarding
to the wrong proxy or the wrong proxy
order. Do
you guys
have any further thoughts or input on
this?
Thanks!

On Thu, Apr 23, 2009 at 12:31 AM,
Klaus Darilion
<klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@pernau.at>>>>>> wrote:

Hi Brandon!

Back to the original email ....

Brandon Armstead schrieb:

Hello guys,

Is there a method upon using
lookup("location")
to also pull
out the "socket" information
for the
original
location the UAC
registered to, for scenarios
of this
example:

P1 & P2 share same usrloc
database.

UA1 registers to P1
UA2 registers to P2

UA1 calls UA2

UA1 invites -> P1 -> INVITES
-> UA2
(bypassing P2
-- where the
actual nat binding is).

Now upon P1 looking up usrloc
for UA2, I
would like
to recognize
that P1 is not the Proxy to
deliver the
call, and
forward the
request to P2 to send to UA2.

So currently I have:

UA1 INVITE -> P1 INVITE -> UA2

I wish to have:

UA1 INVITE -> P1 INVITE -> P2
INVITE
-> UA2

Is there an easy method to do
this?
I have been
looking at the
new nat traversal module it looks
like it is
doable
with this
(any further input as far as
that?).
Also is it
possible with
the classic Nat Helper module?
Any
input is
appreciated, thanks!

I think the nat_traversal module
can not
help you in
this case, nor
nathelper.

One possibility would be to spoof
at P1
the IP
address
of P2 -
nevertheless this would cause the
reply
sent back to
P2, but the
transaction is created in P1. (and you
need to hack
Kamailio for IP
spoofing).

Another easy solution would be: In
P1 set
a certain
branch-flag when
the client registers, e.g. bflag
1. In P2
set a
certain
branch-flag
when the client registers, e.g.
bflag 2.

Now, if a user is called, just make a
lookup() and
t_relay. Further
in the branch_route check if:
in P1: isbflagset(2) --> forward
to P2
in P2: isbflagset(1) --> forward
to P1

klaus

------------------------------------------------------------------------

_______________________________________________
Kamailio (OpenSER) - Users
mailing list
Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>>>>

http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

------------------------------------------------------------------------

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>
<mailto:Users@lists.kamailio.org
<mailto:Users@lists.kamailio.org>>>

http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

-- Daniel-Constantin Mierla
http://www.asipto.com/

-- Daniel-Constantin Mierla
http://www.asipto.com/

-- Daniel-Constantin Mierla
http://www.asipto.com/

------------------------------------------------------------------------

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org

http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

--
Daniel-Constantin Mierla
http://www.asipto.com/