Hi, I must deal with a B2BUA which keeps the original SDP unchanged except the fact that it removes the "a=nortpproxy:yes" line added by RtpProxy. The B2BUA intercommunicates two Kamailio, both forcing its own RtpProxy server.
I've not tested it again but expect there will be no RTP as each RtpProxy will wait for RTP coming from the other. Am I right? Of course I could force RtpProxy just in NAT cases and so, but I prefer to force it always so the clients of each Kamailio can configure QoS for the media addresses (different in each server). Is there some workaround for it?
In the other hand: is it possible two different Kamailio's to share the same RtpProxy server? I've never tryied it. If it's valid, would it solve the B2BUA issue? (I don't think so as there are still different media sessions created by different kamailio instances).
Any thought? Thanks a lot.
Iñaki Baz Castillo writes:
I've not tested it again but expect there will be no RTP as each RtpProxy will wait for RTP coming from the other. Am I right?
hopefully you are not right. it must be possible to have a chain of rtproxys for the same session. mediaproxy works ok in this kind of situation. also, one mediaproxy relay can be controlled by several dispatchers.
-- juha
2010/4/23 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
I've not tested it again but expect there will be no RTP as each
> RtpProxy will wait for RTP coming from the other. Am I right?
hopefully you are not right. it must be possible to have a chain of rtproxys for the same session. mediaproxy works ok in this kind of situation. also, one mediaproxy relay can be controlled by several dispatchers.
Hi, I know that mediaproxy is supposed to work in such scenario, but I thought that RtpProxy was not. If both RtpProxy uses "force_rtpproxy()" without "-r" flag then both would be waiting until receiving packets from the other, like a dead lock, am I wrong? I'm fully sure I've read it somewhere.
Thanks.
Am 23.04.2010 13:32, schrieb Juha Heinanen:
Iñaki Baz Castillo writes:
I've not tested it again but expect there will be no RTP as each RtpProxy will wait for RTP coming from the other. Am I right?
hopefully you are not right. it must be possible to have a chain of rtproxys for the same session. mediaproxy works ok in this kind of situation. also, one mediaproxy relay can be controlled by several dispatchers.
It works as long either: - rtpproxy uses the same IP address as the SIP proxy (rtpproxy per default allows incoming RTP packets (latching) only from the IP from which the SIP message was received), or
- call rtpproxy with 'r' flag for the messages received from the trusted proxies
regards klaus
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/4/23 Klaus Darilion klaus.mailinglists@pernau.at:
It works as long either:
- rtpproxy uses the same IP address as the SIP proxy (rtpproxy per default
allows incoming RTP packets (latching) only from the IP from which the SIP message was received), or
- call rtpproxy with 'r' flag for the messages received from the trusted
proxies
Ok Ok! this makes a lot of sense. Thanks a lot, it's clear now.
2010/4/23 Klaus Darilion klaus.mailinglists@pernau.at:
Am 23.04.2010 13:32, schrieb Juha Heinanen:
Iñaki Baz Castillo writes:
I've not tested it again but expect there will be no RTP as each
> RtpProxy will wait for RTP coming from the other. Am I right?
hopefully you are not right. it must be possible to have a chain of rtproxys for the same session. mediaproxy works ok in this kind of situation. also, one mediaproxy relay can be controlled by several dispatchers.
It works as long either:
- rtpproxy uses the same IP address as the SIP proxy (rtpproxy per default
allows incoming RTP packets (latching) only from the IP from which the SIP message was received), or
- call rtpproxy with 'r' flag for the messages received from the trusted
proxies
Hi again, I have a doubt now. According to nathelper doc:
-------------------------------------------------------------------- 1.6.4. force_rtp_proxy([flags [, ip_address]])
-r flags that IP address in SDP should be trusted. Without this flag, nathelper ignores address in the SDP and uses source address of the SIP message as media address which is passed to the RTP proxy. --------------------------------------------------------------------
Ok, let's assume that Kamailio receives an INVITE from a gateway from IP 1.1.1.1, and the media address in the SDP is 1.1.1.2 (this is because the gateways uses a different interface(s) for the RTP).
Then if I invoke "force_rtp_proxy()" with no arguments, then nathelper will instruct RtpProxy proxy about media source address 1.1.1.1 (same as SIP signalling), am I right? And then, as the RTP will come from 1.1.1.2 it should be ignored/rejected by RtpProxy server, right? Theorically "-r" flag should be required for this case (so nathelper would instruct RtpProxy to be ready to receive the RTP from 1.1.1.2).
But for sure this is not true as using "force_rtp_proxy()" with no flags works in this scenario. This is because using "force_rtp_proxy()" without flags would allow RTP from the both the real address in the incoming SDP and the signalling IP, as the logs show:
rtpproxy log:
# INVITE arrives from gw: pre-filling caller's address with 1.1.1.1:SDP_ORIGINAL_PORT # 200 replied: caller's address filled in: 1.1.1.2:SDP_ORIGINAL_PORT (RTP)
So let's suppose Kamailio-1 (1.1.1.1) using RtpProxy-1 (9.9.9.1) and Kamailio-2 (2.2.2.2) using RtpProxy-2 (9.9.9.2), and also a transparent SIP proxy between them (Proxy-X with IP 5.5.5.5).
- Kamailio-1 receives an INVITE from a client and forces RtpProxy-1, so the SDP address becomes 9.9.9.1:PORT. - Kamailio-1 routes the INVITE to Proxy-X (5.5.5.5). - Proxy-X routes the INVITE to Kamailio-2. - Kamailio-2 invokes "force_rtp_proxy()" with no flags.
Then RtpProxy-2 would wait for incoming RTP from 5.5.5.5 (signalling source address) or from 9.9.9.1:PORT (the address in the INVITE's SDP). Similar would occur with the 200 OK so RtpProxy-1 would wait for RTP comming from 5.5.5.5 or 9.9.9.2:PORT (the address in 200's SDP).
Finally (correct me if I'm wrong) RtpProxy-1 would forward the RTP from its client to 9.9.9.2:PORT after some timeout as no RTP was received from 5.5.5.5 or 9.9.9.2:PORT. Then RtpProxy-2 already knows where to send its RTP (or the same timeout could occur with same result as well).
So RtpProxy-1 could send RTP to RtpProxy-2 and vice versa.
Do I miss something? Thanks a lot.
2010/4/24 Iñaki Baz Castillo ibc@aliax.net:
So let's suppose Kamailio-1 (1.1.1.1) using RtpProxy-1 (9.9.9.1) and Kamailio-2 (2.2.2.2) using RtpProxy-2 (9.9.9.2), and also a transparent SIP proxy between them (Proxy-X with IP 5.5.5.5).
- Kamailio-1 receives an INVITE from a client and forces RtpProxy-1,
so the SDP address becomes 9.9.9.1:PORT.
- Kamailio-1 routes the INVITE to Proxy-X (5.5.5.5).
- Proxy-X routes the INVITE to Kamailio-2.
- Kamailio-2 invokes "force_rtp_proxy()" with no flags.
Then RtpProxy-2 would wait for incoming RTP from 5.5.5.5 (signalling source address) or from 9.9.9.1:PORT (the address in the INVITE's SDP). Similar would occur with the 200 OK so RtpProxy-1 would wait for RTP comming from 5.5.5.5 or 9.9.9.2:PORT (the address in 200's SDP).
Finally (correct me if I'm wrong) RtpProxy-1 would forward the RTP from its client to 9.9.9.2:PORT after some timeout as no RTP was received from 5.5.5.5 or 9.9.9.2:PORT. Then RtpProxy-2 already knows where to send its RTP (or the same timeout could occur with same result as well).
I could do a test with the same scenario and unfortunatelly I miss something as it doesn't work:
RtpProxy-2 doesn't receive RTP, neither from 5.5.5.5 or 9.9.9.1:PORT, so after some time it decides to send the RTP to 5.5.5.5:PORT !! (the pre-filled caller's address in rtpproxy log). So in this case I need "-r" flag. Then after the timeout RtpProxy-2 would send the RTP to 9.9.9.1:PORT. Right?
Regards.
2010/4/24 Iñaki Baz Castillo ibc@aliax.net:
I could do a test with the same scenario and unfortunatelly I miss something as it doesn't work:
RtpProxy-2 doesn't receive RTP, neither from 5.5.5.5 or 9.9.9.1:PORT, so after some time it decides to send the RTP to 5.5.5.5:PORT !! (the pre-filled caller's address in rtpproxy log). So in this case I need "-r" flag. Then after the timeout RtpProxy-2 would send the RTP to 9.9.9.1:PORT. Right?
So yes, repeated the experiment with "-r" (if the request comes from a trusted node as 5.5.5.5) and I get bidirectional audio with the RTP passing throught both RtpProxy instances :)
Iñaki Baz Castillo writes:
1.6.4. force_rtp_proxy([flags [, ip_address]])
-r flags that IP address in SDP should be trusted. Without thisflag, nathelper ignores address in the SDP and uses source address of the SIP message as media address which is passed to the RTP proxy.
i don't understand what chaining of rtpproxies has to do with trusting of ip addresses. my proxy can receive a request from anyone from the internet and if that someone is behind nat and his proxy happens to use rtpproxy, then chaining with my rtpproxy does not work if some kind of trust relationship between these two proxies is needed.
-- juha
2010/4/24 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
1.6.4. force_rtp_proxy([flags [, ip_address]])
> > -r flags that IP address in SDP should be trusted. Without this > flag, nathelper > ignores address in the SDP and uses source address of the > SIP message > as media address which is passed to the RTP proxy.
i don't understand what chaining of rtpproxies has to do with trusting of ip addresses. my proxy can receive a request from anyone from the internet and if that someone is behind nat and his proxy happens to use rtpproxy, then chaining with my rtpproxy does not work if some kind of trust relationship between these two proxies is needed.
If these rtpproxy use the same IP as the Kamailio's SIP signalling IP, then there is no problem and no need to use "-r" flag. But my case is more exotic as there is a transparent proxy between Kamailio-1 and Kamailio-2, each one with its own RtpProxy not listening in same IP as its Kamailio, and thre is also a transaparent SIP proxy between them which, for some reason, removes the line "a=nortpproxy". In this case both RtpProxy would handle the media and a deadlock would occur if flag "-r" is not used because after some timeout both RtpProxy would start relaying RTP to the IP of the transparent proxy (the prefilled address when not using "-r" flag).
I've checked it.
Iñaki Baz Castillo writes:
If these rtpproxy use the same IP as the Kamailio's SIP signalling IP, then there is no problem and no need to use "-r" flag.
inaki,
does it work in the common case where there is two sip proxys and two rtpproxies belonging to two organizations that don't have any trust relationship between them and ip addresses of the rtpproxies are not the same as sip proxy ip addresses?
-- juha
2010/4/24 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
> If these rtpproxy use the same IP as the Kamailio's SIP signalling IP, > then there is no problem and no need to use "-r" flag.
inaki,
does it work in the common case where there is two sip proxys and two rtpproxies belonging to two organizations that don't have any trust relationship between them and ip addresses of the rtpproxies are not the same as sip proxy ip addresses?
In such case, the first Kamailio's nathelper module would add a line "a=nortpproxy" and force RTP throught its RtpProxy-1. The INVITE arrives to Kamailio-2 with the SDP *untouched* (same as nathelper-1 set).
Kamailio-2's nathelper would detect "a=nortpproxy" (hopefully) so it wouldn't force its RtpProxy-2. Ok, no problem.
But in my case, there is a buggy transparent SIP proxy between Kamailio-1 and Kamailio-2, and it removes the "a=nortpproxy" (by leaving untouched the rest of the SDP). Then, since RtpProxies listen in a IP different than Kamailio, and since both use "force_rtp_proxy()" with no "-r" flag, a deadlock occurs: Both RtpProxies prefill the caller and callee media address as remote "KAMAILIO_IP:SDP_PORT" (since "-r" flag is not used) so after sometomeout without receiving RTP both will send RTP to the prefilled media address (error, of course).
By using "-r" (in both or just one of the RtpProxies) it will work as such RtpProxy will prefill the remote media address with the SDP received media address (the IP from with the remote RtpProxy will sent RTP).
My conclussion is that using "-r" flag is MUCH better than not using it. Why?
Without "-r" flag: - RtpProxy prefills the remote address with SIP_RECEIVED_IP:SDP_PORT (which just makes sense in some corner cases). - If RtpProxy doesn't receive RTP in the port it publishes, it will forward its RTP to SIP_RECEIVED_IP:SDP_PORT.
With "-r" flag: - RtpProxy prefills the remote address with SDP_IP:SDP_PORT. - If RtpProxy doesn't receive RTP in the port it publishes, it will forward its RTP to SDP_IP:SDP_PORT.
In the case of two RtpProxy speaking between them, the second option (-r) is desired. If not, it will not work as described above.
Am 24.04.2010 11:25, schrieb Juha Heinanen:
Iñaki Baz Castillo writes:
If these rtpproxy use the same IP as the Kamailio's SIP signalling IP, then there is no problem and no need to use "-r" flag.
inaki,
does it work in the common case where there is two sip proxys and two rtpproxies belonging to two organizations that don't have any trust relationship between them and ip addresses of the rtpproxies are not the same as sip proxy ip addresses?
It depends on the configuration.
IMO a "correct" kamailio/rtpproxy setup uses (note: 'a' implies 'r'):
Alice Atlanta Biloxy Bob rtpproxy rtpproxy flags flags <---''---|--'a'--> <--'a'--|------->
This is because Atlante can not know about the setup of Biloxy (if the clients are behind, if there are multiple proxies in between). Thus, a proxy should perform NAT traversal (rewrite contact untrusted SDP) only for the local users. For external users (other domains) the Atlanta proxy should not rewrite the contact header and should use received SDP. Every domain's proxy is responsible to fix its client's signaling.
regards klaus
Iñaki,
I would be curious to know what practical circumstances demand such a convoluted topology.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892
On Apr 24, 2010, at 5:48 AM, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/4/24 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
1.6.4. force_rtp_proxy([flags [, ip_address]])
-r flags that IP address in SDP should be trusted. Withoutthis
flag, nathelper ignores address in the SDP and uses source address of the SIP message as media address which is passed to the RTP proxy.
i don't understand what chaining of rtpproxies has to do with trusting of ip addresses. my proxy can receive a request from anyone from the internet and if that someone is behind nat and his proxy happens to use rtpproxy, then chaining with my rtpproxy does not work if some kind of trust relationship between these two proxies is needed.
If these rtpproxy use the same IP as the Kamailio's SIP signalling IP, then there is no problem and no need to use "-r" flag. But my case is more exotic as there is a transparent proxy between Kamailio-1 and Kamailio-2, each one with its own RtpProxy not listening in same IP as its Kamailio, and thre is also a transaparent SIP proxy between them which, for some reason, removes the line "a=nortpproxy". In this case both RtpProxy would handle the media and a deadlock would occur if flag "-r" is not used because after some timeout both RtpProxy would start relaying RTP to the IP of the transparent proxy (the prefilled address when not using "-r" flag).
I've checked it.
-- Iñaki Baz Castillo ibc@aliax.net
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2010/4/24 Alex Balashov abalashov@evaristesys.com:
Iñaki,
I would be curious to know what practical circumstances demand such a convoluted topology.
Hi, please read the mail I've sent right now in this thread, it explains the exact case I suffer. All occurs due to a buggy transparent SIP proxy (a B2BUA in fact) which removes the "a=nortpproxy" line in the SDP.
On 04/24/2010 09:01 AM, Iñaki Baz Castillo wrote:
2010/4/24 Alex Balashovabalashov@evaristesys.com:
Iñaki,
I would be curious to know what practical circumstances demand such a convoluted topology.
Hi, please read the mail I've sent right now in this thread, it explains the exact case I suffer. All occurs due to a buggy transparent SIP proxy (a B2BUA in fact) which removes the "a=nortpproxy" line in the SDP.
I read that, but was curious about the larger picture; why do you need the transparent proxy/B2BUA?
2010/4/24 Alex Balashov abalashov@evaristesys.com:
I read that, but was curious about the larger picture; why do you need the transparent proxy/B2BUA?
It's the accounting softswitch in my company. All the SIP calls to the PSTN must go through it, even if the destination number is also a local SIP client. So, it could occur that a local SIP client (using Kamailio-1 + RtpProxy-1) calls another local SIP client (in Kamailio-2 + RtpProxy-2). It must work :)
As I said, using "-r" is the solution. In fact, I thing that "-r" should be the default value, as it makes more sense RtpProxy to prefill the media address with the address in the SDP rather than the SIP_RECEIVED_IP:SDP_PORT (which is mostly useless).
Am 24.04.2010 15:47, schrieb Iñaki Baz Castillo:
2010/4/24 Alex Balashovabalashov@evaristesys.com:
I read that, but was curious about the larger picture; why do you need the transparent proxy/B2BUA?
It's the accounting softswitch in my company. All the SIP calls to the PSTN must go through it, even if the destination number is also a local SIP client. So, it could occur that a local SIP client (using Kamailio-1 + RtpProxy-1) calls another local SIP client (in Kamailio-2 + RtpProxy-2). It must work :)
As I said, using "-r" is the solution. In fact, I thing that "-r" should be the default value, as it makes more sense RtpProxy to prefill the media address with the address in the SDP rather than the SIP_RECEIVED_IP:SDP_PORT (which is mostly useless).
It depends. Most time rtpproxy is used you care about NAT traversal, not a broken B2BUA. Thus IMO the current default setting makes more sense.
regards klaus
2010/4/26 Klaus Darilion klaus.mailinglists@pernau.at:
As I said, using "-r" is the solution. In fact, I thing that "-r" should be the default value, as it makes more sense RtpProxy to prefill the media address with the address in the SDP rather than the SIP_RECEIVED_IP:SDP_PORT (which is mostly useless).
It depends. Most time rtpproxy is used you care about NAT traversal, not a broken B2BUA. Thus IMO the current default setting makes more sense.
"-r" also works in case of NAT. The only difference is the initially prefilled media address (that is just use in case of not receiving media in the published port).
Am 26.04.2010 12:19, schrieb Iñaki Baz Castillo:
2010/4/26 Klaus Darilionklaus.mailinglists@pernau.at:
As I said, using "-r" is the solution. In fact, I thing that "-r" should be the default value, as it makes more sense RtpProxy to prefill the media address with the address in the SDP rather than the SIP_RECEIVED_IP:SDP_PORT (which is mostly useless).
It depends. Most time rtpproxy is used you care about NAT traversal, not a broken B2BUA. Thus IMO the current default setting makes more sense.
"-r" also works in case of NAT. The only difference is the initially prefilled media address (that is just use in case of not receiving media in the published port).
But doesn't give you the default more security? I thought that "latching in" is only allowed from the prefilled IP address.
regards klaus
2010/4/26 Klaus Darilion klaus.mailinglists@pernau.at:
"-r" also works in case of NAT. The only difference is the initially prefilled media address (that is just use in case of not receiving media in the published port).
But doesn't give you the default more security? I thought that "latching in" is only allowed from the prefilled IP address.
Are you sure? In my case when I receive an INVITE from my PSTN gateways such INVITE comes from SIGNALING_IP while the SDP contains a different SDP_MEDIA_IP. I call "force_rtpproxy()" with no flags so RtpProxy prefills the media address with "SIGNALING_IP:SDP_MEDIA_PORT". Anyhow the media comes from SDP_MEDIA_IP:SDP_MEDIA_PORT and RtpProxy allows such incoming RTP, so I don't know how such "latching in" security mechanism works (it should reject such audio if "-r" is not used, right? but it doesn't reject it so...).
Hola Iñaki,
Hi, I must deal with a B2BUA which keeps the original SDP unchanged except the fact that it removes the "a=nortpproxy:yes" line added by RtpProxy. The B2BUA intercommunicates two Kamailio, both forcing its own RtpProxy server.
I've not tested it again but expect there will be no RTP as each RtpProxy will wait for RTP coming from the other. Am I right? Of course I could force RtpProxy just in NAT cases and so, but I prefer to force it always so the clients of each Kamailio can configure QoS for the media addresses (different in each server). Is there some workaround for it?
You can use "-f" with force_rtp_proxy() :
f - instructs nathelper to ignore marks inserted by another nathelper in transit to indicate that the session is already goes through another proxy. Allows creating chain of proxies.
In the other hand: is it possible two different Kamailio's to share the same RtpProxy server? I've never tryied it. If it's valid, would it solve the B2BUA issue? (I don't think so as there are still different media sessions created by different kamailio instances).
Yes, you can share the same rtpproxy with different Kamailios.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
2010/4/23 Jesus Rodriguez jesusr@voztele.com:
Hola Iñaki,
Hi, I must deal with a B2BUA which keeps the original SDP unchanged except the fact that it removes the "a=nortpproxy:yes" line added by RtpProxy. The B2BUA intercommunicates two Kamailio, both forcing its own RtpProxy server.
I've not tested it again but expect there will be no RTP as each RtpProxy will wait for RTP coming from the other. Am I right? Of course I could force RtpProxy just in NAT cases and so, but I prefer to force it always so the clients of each Kamailio can configure QoS for the media addresses (different in each server). Is there some workaround for it?
You can use "-f" with force_rtp_proxy() :
f - instructs nathelper to ignore marks inserted by another nathelper in transit to indicate that the session is already goes through another proxy. Allows creating chain of proxies.
But the "problem" is that the SDP doesn't contain a=nortpproxy:yes" as the B2BUA removed it. Then I don't need "-f" :) But my question is, will be there media between both RtpProxies then? Well, after reading "Allows creating chain of proxies" it seems that it should be :)
In the other hand: is it possible two different Kamailio's to share the same RtpProxy server? I've never tryied it. If it's valid, would it solve the B2BUA issue? (I don't think so as there are still different media sessions created by different kamailio instances).
Yes, you can share the same rtpproxy with different Kamailios.
Great.
Thanks a lot.
You can try use the flags r and f for this case.
These flags can force rtpproxy "to send" a RTP.
You can see: http://www.kamailio.org/docs/modules/1.5.x/nathelper.html#id2468157
--- Em sex, 23/4/10, Iñaki Baz Castillo ibc@aliax.net escreveu:
De: Iñaki Baz Castillo ibc@aliax.net Assunto: [SR-Users] B2BUA removing a=nortpproxy:yes (rtpproxy-1 <---RTP---> rtpproxy-2) Para: "Kamailio" users@lists.kamailio.org Data: Sexta-feira, 23 de Abril de 2010, 8:50
Hi, I must deal with a B2BUA which keeps the original SDP unchanged except the fact that it removes the "a=nortpproxy:yes" line added by RtpProxy. The B2BUA intercommunicates two Kamailio, both forcing its own RtpProxy server.
I've not tested it again but expect there will be no RTP as each RtpProxy will wait for RTP coming from the other. Am I right? Of course I could force RtpProxy just in NAT cases and so, but I prefer to force it always so the clients of each Kamailio can configure QoS for the media addresses (different in each server). Is there some workaround for it?
In the other hand: is it possible two different Kamailio's to share the same RtpProxy server? I've never tryied it. If it's valid, would it solve the B2BUA issue? (I don't think so as there are still different media sessions created by different kamailio instances).
Any thought? Thanks a lot.
2010/4/23 Daniel Cardoso Alves dcardosoa@yahoo.com.br
You can try use the flags r and f for this case.
These flags can force rtpproxy "to send" a RTP.
Hi, "-f" is not useful for me as the "boggus" B2BUA already does the job of removing the line "a=nortpproxy:yes".
"-r" flag could be interesting. If I'm not wrong it means that RtpProxy will expect (and send) audio from/to the original address in the SDP. This could be nice when the request comes from a ggateway with public address, right? However in my case this is not always true as the B2BUA could carry an INVITE from a natted client so the SDP contains a private address.
Thanks a lot.
-- Iñaki Baz Castillo ibc@aliax.net
-
Alex Balashov -
Daniel Cardoso Alves -
Iñaki Baz Castillo -
Jesus Rodriguez -
Juha Heinanen -
Klaus Darilion