19 Jun
2024
19 Jun
'24
10:54 p.m.
I am extremely new at this, but trying to set up TLS with a carrier. TLS connection is
good, Invite goes out, we get the 100 and the 200, but subsequent messages (ACK and BYE)
are being sent with UDP and I cannot figure out how to get them to maintain the TLS
transport. Any suggestions? I think this is the section I'm looking for.
# Manage incoming replies in transaction context
onreply_route[MANAGE_REPLY] {
xdbg("incoming reply\n");
if(status=~"[12][0-9][0-9]") {
route(NATMANAGE);
}
if (has_body("application/sdp")) {
xdbg("rtpengine_manage loop-protect MANAGE_REPLY");
#rtpengine_manage("loop-protect");
}
}
20 Jun
20 Jun
12:52 a.m.
El Wed, 19 Jun 2024 19:54:26 -0000
"sarah.martin--- via sr-users" <sr-users(a)lists.kamailio.org> escribió:
I am extremely new at this, but trying to set up TLS
with a carrier. TLS
connection is good, Invite goes out, we get the 100 and the 200, but
subsequent messages (ACK and BYE) are being sent with UDP and I cannot figure
out how to get them to maintain the TLS transport. Any suggestions? I think
this is the section I'm looking for.
What's your contact look like?
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
1:03 a.m.
I replaced IPs, FYI
200 OK from carrier
SIP/2.0 200 OK
Via: SIP/2.0/TLS
KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2
Via: SIP/2.0/TLS
FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De
From: "+14388006102" <sip:+14388006102@KAM_PUB_IP>;tag=XjQ5g4Ze5UaZp
To: <sip:933@CARRIER_PUB_IP:5061;transport=tls>;tag=gK04d33797
Call-ID: b99c2b65-a827-123d-1984-4201c0a80193
CSeq: 84807919 INVITE
Record-Route:
<sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes>
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,
multipart/mixed
Contact: <sip:933@CARRIER_PUB_IP:5061>
Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: timer
Supported: timer
Session-Expires: 1800;refresher=uac
Content-Length: 324
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP
s=SIP Media Capabilities
c=IN IP4 206.146.100.22
t=0 0
m=audio 33168 RTP/SAVP 0 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
ACK Kam is sending
ACK sip:933@CARRIER_PUB_IP:5061 SIP/2.0
Via: SIP/2.0/UDP
KAM_PUB_IP:5060;branch=z9hG4bK18ff.f8c56ea9cad44dc10408188224b923cf.0;i=a2
Via: SIP/2.0/TLS
FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKmK767vF2vjZ0S
Max-Forwards: 69
From: "+14388006102" <sip:+14388006102@KAM_PUB_IP>;tag=XjQ5g4Ze5UaZp
To: <sip:933@CARRIER_PUB_IP:5061;transport=tls>;tag=gK04d33797
Call-ID: b99c2b65-a827-123d-1984-4201c0a80193
CSeq: 84807919 ACK
Contact: <sip:mod_sofia@FS_PUB_IP:5061;transport=tls;alias=FS_PUB_IP~56403~3>
Content-Length: 0
11:39 a.m.
Hi
The INVITE would also be interesting.
Does the Contact: Header in the invite contain the transport=tls
attribute?
Souldn't the 200 OK reply contain at least one Record-Route (the lowest
one) stating transport=tls?
PS: I was facing a similar issue with a commercial SBC which, when
TLS/TCP is not licensed, has the oddity to remove the transport
attribute from the contact header and send new transactions in the same
dialog without specifying transport (defaulting to UDP). So I had to
create a copy the value of the transport header to a custom t=
contact attribute, which I then use to restore the U-URI transport
attribute towards the registrar handling the CPE connection.
200 OK from carrier
SIP/2.0 200 OK
Via: SIP/2.0/TLS
KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2
Via: SIP/2.0/TLS
FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De
From: "+14388006102" <sip:+14388006102@KAM_PUB_IP>;tag=XjQ5g4Ze5UaZp
To: <sip:933@CARRIER_PUB_IP:5061;transport=tls>;tag=gK04d33797
Call-ID: b99c2b65-a827-123d-1984-4201c0a80193
CSeq: 84807919 INVITE
Record-Route:
<sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes>
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,
multipart/mixed
Contact: <sip:933@CARRIER_PUB_IP:5061>
Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: timer
Supported: timer
Session-Expires: 1800;refresher=uac
Content-Length: 324
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP
s=SIP Media Capabilities
c=IN IP4 206.146.100.22
t=0 0
m=audio 33168 RTP/SAVP 0 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
ACK Kam is sending
ACK sip:933@CARRIER_PUB_IP:5061 SIP/2.0
Via: SIP/2.0/UDP
KAM_PUB_IP:5060;branch=z9hG4bK18ff.f8c56ea9cad44dc10408188224b923cf.0;i=a2
Via: SIP/2.0/TLS
FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKmK767vF2vjZ0S
Max-Forwards: 69
From: "+14388006102" <sip:+14388006102@KAM_PUB_IP>;tag=XjQ5g4Ze5UaZp
To: <sip:933@CARRIER_PUB_IP:5061;transport=tls>;tag=gK04d33797
Call-ID: b99c2b65-a827-123d-1984-4201c0a80193
CSeq: 84807919 ACK
Contact: <sip:mod_sofia@FS_PUB_IP:5061;transport=tls;alias=FS_PUB_IP~56403~3>
Content-Length: 0
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
3:47 p.m.
Originating invite towards carrier. Yes, the contact includes the transport=tls.
INVITE sip:933@CARRIER_PUB_IP:5061;transport=tls SIP/2.0
Record-Route:
<sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=09c1cZr21c5HF;did=dbd.79d;nat=yes>
Via: SIP/2.0/TLS
KAM_PUB_IP:5061;branch=z9hG4bK317b.e2cd4e0e036cc3a13f6bb1a86e1db84e.0;i=f1
Via: SIP/2.0/TLS
FS_PUB_IP:5061;received=FS_PUB_IP;rport=39577;branch=z9hG4bKF0jKaBSBpQtXF
Max-Forwards: 69
From: "2029200292" <sip:2029200292@KAM_PUB_IP>;tag=09c1cZr21c5HF
To: <sip:933@CARRIER_PUB_IP:5061;transport=tls>
Call-ID: 8460387e-a536-123d-1984-4201c0a80193
CSeq: 84646169 INVITE
Contact: <sip:mod_sofia@FS_PUB_IP:5061;transport=tls;alias=FS_PUB_IP~39577~3>
User-Agent: FreeSWITCH-mod_sofia/1.10.7-release-19-883d2cb662~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 753
X-FS-Support: update_display,send_info
P-Asserted-Identity: "2029200292" <sip:2029200292@KAM_PUB_IP>
P-Hint: outbound
v=0
o=FreeSWITCH 1718380362 1718380363 IN IP4 KAM_PUB_IP
s=FreeSWITCH
c=IN IP4 KAM_PUB_IP
t=0 0
a=rtpengine:94805c0d8314
m=audio 11080 RTP/SAVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:11081
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9Qjov4TJ7gCTZ1QXBcvg5zwRmNE5d1A6OEfmY7Lz
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:ue9JN4KAuPD9xsJwC1HzQflx67IY8+dOpnYszoyJ
a=crypto:3 F8_128_HMAC_SHA1_80 inline:04FfXKIKe9NlS6JaQjiCqEGGs7pJs7yPINkwxU+p
a=crypto:4 F8_128_HMAC_SHA1_32 inline:RJJdhXJ7iP+l7ssqqbWxZmZN3kU09VDZe9Vp+0dt
a=setup:actpass
a=fingerprint:sha-256
E6:F5:49:C1:2A:33:E2:F5:22:7E:7D:E0:EA:3D:77:0C:45:50:B8:8F:20:4D:C4:BA:8F:5F:3D:57:F5:94:B4:8F
a=ptime:20
4:04 p.m.
Hi
Originating invite towards carrier. Yes, the contact
includes the transport=tls.
I think I'm missing something.
Which message is not correctly routed?
The 200 OK reply to an INVITE which was initiated via transport tls? Or
messages in a new transaction of that call, possibly from the B to A
side?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
5:14 p.m.
FS-->Kam-->Carrier
Invite to carrier is good, sent over tls and so the reply from the carrier, the 200 ok.
The ACK is sent via UDP and so is the Bye, which I didn't include.
5:34 p.m.
Am Thu, 20 Jun 2024 14:14:11 -0000
schrieb smartin114--- via sr-users <sr-users(a)lists.kamailio.org>rg>:
Invite to carrier is good, sent over tls and so the
reply from the carrier, the 200 ok. The ACK is sent via UDP and so is the Bye, which I
didn't include.
I fear I need more information and a complete example to see what might
be going wrong.
INVITE: FS => TLS => Kamailio => UDP => Carrier
some more messages
200 OK: Carrier => UDP => Kamailio => TLS => FS
and the ACK to the 200 OK, they are all fine?
So the Problem is the BYE when sent which direction? From the Carrier?
I assume this is the case.
Basically you need to look at the INVITE from the FS.
Does the Contact: header contain a transport=tls attribute? (According
to your example, it does)
So this information needs to be stored on the Carrier side (or whatever
B2BUA an the Carrier side handles the call) and when the carrier issues
a BYE the R-URI of that BYE needs to contain transport=tls as this is
the information, the last HOP towards the Fs side will be using when
all Route: Header have been consumed.
If this is NOT the case and transport=tls is missing in the BYE R-URI
the IMHO SIP implementation Carries side is 'broken', you face the same
issue I have had. :-)
If you are able to put other attributes in the invite Contact header,
and they are sent back the BYE from the Carrier, then you can copy the
transport value to a custom contact attribute (I use t=) and restore the
transport attribute on the R-URI from that.
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
5:48 p.m.
everything from FS to Kam shows TLS and good. It's just the leg between Kam and the
carrier. The invite goes from Kam to the carrier (the one I pasted above), the carrier
200ok's it, also good, then Kam sends the ACK over UDP, so the carrier never actually
sees it - because they aren't listening on 5060 for this connection and the carrier
retransmits the 200 until the call terminates. When Kam initiates the Bye, it is also
over UDP. When Kam responds to the carrier Bye that eventually comes, it sends that over
TLS.
7:43 p.m.
can you show the 200 OK?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
On Thu, Jun 20, 2024 at 5:43 PM smartin114--- via sr-users <
sr-users(a)lists.kamailio.org> wrote:
I was trying to add an attachment of the call flow,
but I don't see that I
can?
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
7:45 p.m.
it is already in the thread.
200 OK from carrier
SIP/2.0 200 OK
Via: SIP/2.0/TLS
KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2
Via: SIP/2.0/TLS
FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De
From: "+14388006102" <sip:+14388006102@KAM_PUB_IP>;tag=XjQ5g4Ze5UaZp
To: <sip:933@CARRIER_PUB_IP:5061;transport=tls>;tag=gK04d33797
Call-ID: b99c2b65-a827-123d-1984-4201c0a80193
CSeq: 84807919 INVITE
Record-Route:
<sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes>
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,
multipart/mixed
Contact: <sip:933@CARRIER_PUB_IP:5061>
Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: timer
Supported: timer
Session-Expires: 1800;refresher=uac
Content-Length: 324
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP
s=SIP Media Capabilities
c=IN IP4 CARRIER_PUB_IP
t=0 0
m=audio 33168 RTP/SAVP 0 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
8:13 p.m.
You trying to add the XML to the sdp?
Are you manipulating something somewhere? It is very strange indeed... have
you tried force_socket?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
On Thu, Jun 20, 2024 at 7:06 PM smartin114--- via sr-users <
sr-users(a)lists.kamailio.org> wrote:
it is already in the thread.
200 OK from carrier
SIP/2.0 200 OK
Via: SIP/2.0/TLS
KAM_PUB_IP:5061;branch=z9hG4bK18ff.3d856b8b0b007414ab2dec09cbabd574.0;i=a2
Via: SIP/2.0/TLS
FS_PUB_IP:5061;received=FS_PUB_IP;rport=56403;branch=z9hG4bKKaee61yyZ98De
From: "+14388006102" <sip:+14388006102@KAM_PUB_IP>;tag=XjQ5g4Ze5UaZp
To: <sip:933@CARRIER_PUB_IP:5061;transport=tls>;tag=gK04d33797
Call-ID: b99c2b65-a827-123d-1984-4201c0a80193
CSeq: 84807919 INVITE
Record-Route:
<sip:KAM_PUB_IP:5061;transport=tls;lr;ftag=XjQ5g4Ze5UaZp;did=aad.91c1;nat=yes>
Accept: application/sdp, application/isup, application/dtmf,
application/dtmf-relay,
multipart/mixed
Contact: <sip:933@CARRIER_PUB_IP:5061>
Allow:
INVITE,ACK,CANCEL,BYE,REGISTER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Require: timer
Supported: timer
Session-Expires: 1800;refresher=uac
Content-Length: 324
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 913845 351585 IN IP4 CARRIER_PUB_IP
s=SIP Media Capabilities
c=IN IP4 CARRIER_PUB_IP
t=0 0
m=audio 33168 RTP/SAVP 0 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:LfSgFSVqhXNWMSziOtwpEeYmNu0/kGiyuMVS8VXy
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
8:15 p.m.
I haven't tried force_socket. Where would that be added?
No manipulating. I was stripping off some of the crypto suites, but that is about it.
9:36 p.m.
you'd need to mark the reply and before forwarding it, force_socket it to
your tls socket
You do have a TLS socket, right?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
On Thu, Jun 20, 2024 at 7:31 PM smartin114--- via sr-users <
sr-users(a)lists.kamailio.org> wrote:
and no, not adding XML to the SDP.
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
11:12 p.m.
Yes, there is a tls socket defined. I assume since the invite goes out TLS and all the
cert stuff works, there is a tls socket as well.
21 Jun
21 Jun
12:23 a.m.
is there a UDP socket a well? are you translating TLS<->UDP?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
On Thu, Jun 20, 2024 at 10:48 PM smartin114--- via sr-users <
sr-users(a)lists.kamailio.org> wrote:
Yes, there is a tls socket defined. I assume since
the invite goes out
TLS and all the cert stuff works, there is a tls socket as well.
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
12:25 a.m.
check
https://github.com/davidcsi/kamailio-private-public/blob/master/kamailio-tl…
that might give you some ideas
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
On Thu, Jun 20, 2024 at 11:23 PM David Villasmil <
david.villasmil.work(a)gmail.com> wrote:
is there a UDP socket a well? are you translating
TLS<->UDP?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
On Thu, Jun 20, 2024 at 10:48 PM smartin114--- via sr-users <
sr-users(a)lists.kamailio.org> wrote:
Yes, there is a tls socket defined. I assume
since the invite goes out
TLS and all the cert stuff works, there is a tls socket as well.
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
25 Jun
25 Jun
10:33 p.m.
In the end it was a very straight forward change. If the call comes in on port 5061 set a
TLS flag, then in the relay, if the flag is set call t_relay_tls vs t_relay
27 Jun
27 Jun
3:03 p.m.
Thanks for reporting back.
Henning
-----Original Message-----
From: smartin114--- via sr-users <sr-users(a)lists.kamailio.org>
Sent: Tuesday, June 25, 2024 9:34 PM
To: sr-users(a)lists.kamailio.org
Cc: smartin114(a)me.com
Subject: [SR-Users] Re: replies using the wrong protocol
In the end it was a very straight forward change. If the call comes in on port 5061 set a
TLS flag, then in the relay, if the flag is set call t_relay_tls vs t_relay
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to
sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
3:33 p.m.
good that you resolved it.
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
On Thu, Jun 27, 2024 at 2:32 PM Henning Westerholt via sr-users <
sr-users(a)lists.kamailio.org> wrote:
Thanks for reporting back.
Henning
-----Original Message-----
From: smartin114--- via sr-users <sr-users(a)lists.kamailio.org>
Sent: Tuesday, June 25, 2024 9:34 PM
To: sr-users(a)lists.kamailio.org
Cc: smartin114(a)me.com
Subject: [SR-Users] Re: replies using the wrong protocol
In the end it was a very straight forward change. If the call comes in on
port 5061 set a TLS flag, then in the relay, if the flag is set call
t_relay_tls vs t_relay
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
148
days inactive
156
days old
21 comments
6 participants
participants (6)
-
Benoit Panizzon -
David Villasmil -
Henning Westerholt -
Jon Bonilla (Manwe) -
sarah.martin＠nextiva.com -
smartin114＠me.com