14 Dec
2006
14 Dec
'06
4:06 p.m.
Hi,
Provided that my clients are advised to not use STUN or any other NAT
traversal mechanism, is it enough to just use client_nat_test("2"),
which checks if source-ip is different from the one in the Via-Header?
Should be sufficient for detecting NAT, right?
Andy
14 Dec
14 Dec
7:20 p.m.
Hi Andreas,
I would say yes...maybe adding 16 for safety reasons ;). what about
"intelligent" ALGs on the path?
regards,
bogdan
Andreas Granig wrote:
Hi,
Provided that my clients are advised to not use STUN or any other NAT
traversal mechanism, is it enough to just use client_nat_test("2"),
which checks if source-ip is different from the one in the Via-Header?
Should be sufficient for detecting NAT, right?
Andy
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
7:54 p.m.
Bogdan-Andrei Iancu wrote:
I would say yes...maybe adding 16 for safety reasons
;).
Good idea, but I was just looking at client_nat_test of mediaproxy
module, not nat_uac_test of nathelper.
To avoid confusions like that, I'd generally propose to rip out the
nat-traversal stuff (client_nat_test, fix_contact) from mediaproxy,
because it does exactly the same as the corresponding nathelper
functions (nat_uac_test and fix_nated_contact). I don't see the point of
having redundant code here.
what about
"intelligent" ALGs on the path?
As noted before, customers are strongly advised not to use any. I guess,
you all know why ;o)
And there's no other point on the path where an ALG not under customer's
or our control could be placed in this specific deployment.
Regards,
Andy
8:35 p.m.
Andreas Granig wrote:
yes, that's right.
regards,
bogdan
Bogdan-Andrei Iancu wrote:
well.... :)
I would say yes...maybe adding 16 for safety
reasons ;).
Good idea, but I was just looking at client_nat_test of mediaproxy
module, not nat_uac_test of nathelper.
To avoid confusions like that, I'd generally propose to rip out the
nat-traversal stuff (client_nat_test, fix_contact) from mediaproxy,
because it does exactly the same as the corresponding nathelper
functions (nat_uac_test and fix_nated_contact). I don't see the point
of having redundant code here.
other opinions on the topic are welcomed!
what about "intelligent" ALGs on the
path?
As noted before, customers are strongly advised not to use any. I
guess, you all know why ;o)
And there's no other point on the path where an ALG not under
customer's or our control could be placed in this specific deployment. 
15 Dec
15 Dec
3:35 p.m.
Andreas Granig wrote:
--
Klaus Darilion
nic.at
Bogdan-Andrei Iancu wrote:
Makes sense. I use mediaproxy for RTP proxy, but nathelper for
fix_nated.....
regards
klaus
I would say yes...maybe adding 16 for safety
reasons ;).
Good idea, but I was just looking at client_nat_test of mediaproxy
module, not nat_uac_test of nathelper.
To avoid confusions like that, I'd generally propose to rip out the
nat-traversal stuff (client_nat_test, fix_contact) from mediaproxy,
because it does exactly the same as the corresponding nathelper
functions (nat_uac_test and fix_nated_contact). I don't see the point of
having redundant code here. what about "intelligent" ALGs on the
path?
As noted before, customers are strongly advised not to use any. I guess,
you all know why ;o)
And there's no other point on the path where an ALG not under customer's
or our control could be placed in this specific deployment.
Regards,
Andy
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
5:01 p.m.
Hi,
I would say, Dan's opinion is critical as he is the mediproxy maintainer.
regards,
bogdan
Klaus Darilion wrote:
To avoid
confusions like that, I'd generally propose to rip out the
nat-traversal stuff (client_nat_test, fix_contact) from mediaproxy,
because it does exactly the same as the corresponding nathelper
functions (nat_uac_test and fix_nated_contact). I don't see the point
of having redundant code here.
Makes sense. I use mediaproxy for RTP proxy, but nathelper for
fix_nated.....
5:41 p.m.
On Friday 15 December 2006 17:01, Bogdan-Andrei Iancu wrote:
Hi,
I would say, Dan's opinion is critical as he is the mediproxy
maintainer.
The point of that duplicated code there is to not have to load both
modules at the same time.
Besides that, they don't do _exactly_ the same thing at all.
The mediaproxy versions handle asymmetric clients and know when not to
alter the port of the contact and also when not to include the port in
the source address checks. Also the source address check verifies both
the IP and the port not only the IP as the nathelper version does. I have
cases of phones behind NAT that the nathelper checks fail to detect while
the mediaproxy checks do.
regards,
bogdan
Klaus Darilion wrote:
>> To avoid confusions like that, I'd generally propose to rip out the
>> nat-traversal stuff (client_nat_test, fix_contact) from mediaproxy,
>> because it does exactly the same as the corresponding nathelper
>> functions (nat_uac_test and fix_nated_contact). I don't see the
>> point of having redundant code here.
>
> Makes sense. I use mediaproxy for RTP proxy, but nathelper for
> fix_nated.....
--
Dan
8:09 p.m.
Dan Pascu wrote:
The point of that duplicated code there is to not have
to load both
modules at the same time.
Besides that, they don't do _exactly_ the same thing at all.
Ok, but why not merging the advantages of the two versions into one
module? That way, people don't have to wonder which of the functions to use.
And I'd also vote for splitting it up into three modules, like Ovidiu
Sas proposed in another mail, namely an rtpproxy and mediaproxy
controller module and a separate nathelper module.
Just my 2 cents,
Andy
9:27 p.m.
On Friday 15 December 2006 20:09, Andreas Granig wrote:
Dan Pascu wrote:
And how would you mediate the fact that mediaproxy recognizes and handles
asymmetric clients (for both SIP and RTP) while nathelper does not?
There are 2 configuration files to describe such clients and they are used
for both media relaying as well as contact fixing.
With your proposal there will be 2 modules that need to have the same
files specified as module parameters and there will be 2 modules
periodically checking if the asymmetric config files have changed and
need to be reloaded instead of keeping that into only 1 module.
I find this splitting to be unnatural since both operations belong to a
single logical entity and the issues it raises outweight the mere fact
that it cleans up the function list a bit.
If you are so keen to rip some things apart, why don't you rip off the
contact handling stuff from nathelper? The functions from mediaproxy
offer a superset of the nathelper functionality anyway, so I see no point
in removing the more advanced stuff.
--
Dan
The point of that duplicated code there is to not
have to load both
modules at the same time.
Besides that, they don't do _exactly_ the same thing at all.
Ok, but why not merging the advantages of the two versions into one
module? That way, people don't have to wonder which of the functions to
use.
And I'd also vote for splitting it up into three modules, like Ovidiu
Sas proposed in another mail, namely an rtpproxy and mediaproxy
controller module and a separate nathelper module. 
17 Dec
17 Dec
12:12 p.m.
i don't remember why, but i use functions from both meadiaproxy and
nathelper modules and i don't have any trouble with that.
-- juha
18 Dec
18 Dec
10:36 a.m.
Dan Pascu wrote:
And how would you mediate the fact that mediaproxy
recognizes and handles
asymmetric clients (for both SIP and RTP) while nathelper does not?
Then, as already said: why not merging the advantages of both versions?
Technically, it shouldn't be a problem to load the two config files into
shared memory in one module (and reread it by MI) and provide an api for
accessing it from others. This way, also rtpproxy could take advantage
of that. Beside that, I can't see any other functionality, which
mediaproxy has over the nathelper version.
I find this splitting to be unnatural since both
operations belong to a
single logical entity and the issues it raises outweight the mere fact
that it cleans up the function list a bit.
I don't see any real issues. It's some work which has to be done, and
it's not really the most important thing on the todo-list, but it would
remove unneeded redundancy.
Andy
19 Dec
19 Dec
2:52 p.m.
On Monday 18 December 2006 10:36, Andreas Granig wrote:
Then, as already said: why not merging the advantages
of both versions?
Technically, it shouldn't be a problem to load the two config files
into shared memory in one module (and reread it by MI) and provide an
api for accessing it from others.
It would be a problem for me because it will complicate things. I do not
need an MI interface for this. As it is now it automatically detects any
change in the config files and reloads them on the fly without any
intervention. Your proposal is a complication from my point of view.
This way, also rtpproxy could take advantage of that.
I doubt it. Specific changes are required to support asymmetric clients,
not only the fact that contact fixing is aware of that.
Beside that, I can't see any other functionality,
which mediaproxy has
over the nathelper version.
With this kind of statements (and the previous ones you made on the
subject) you only prove that you do not use mediaproxy, do not know what
it has to offer when compared to nathelper and do not care too much what
happens to it. This is why it has a README which details its capabilities
and how it compares with nathelper and what are its advantages.
I don't see any real issues. It's some work
which has to be done, and
it's not really the most important thing on the todo-list, but it would
remove unneeded redundancy.
It is interesting for me to notice that all these proposals to chop down
mediaproxy come from someone who is not using it. Not from someone who is
using it and wants to improve it, but from someone who doesn't use it and
doesn't know what it has to offer, but for some strange reason feels the
need to modify it to fit his vision of things.
As a conclusion, I'm open to any suggestion that will make mediaproxy
better and easier to use. I will not agree however to any change that
will complicate my life as a mediaproxy user so that someone else who is
not using it feels better over what it provides.
Currently the fact that the contact fixing/checking is present in 2
modules doesn't bother me at all, however all the proposals I've heard
here would make a mediaproxy user's life more complicated for no good
reason and they're not worth the price IMO.
--
Dan
3:15 p.m.
Dan Pascu wrote:
--
Klaus Darilion
nic.at
With this kind of statements (and the previous ones
you made on the
subject) you only prove that you do not use mediaproxy, do not know what
it has to offer when compared to nathelper and do not care too much what
happens to it. This is why it has a README which details its capabilities
and how it compares with nathelper and what are its advantages.
nathelper has 2 more NAT tests than mediaproxy
nathelper has fix_nated_register (which is essential for some clients)
nathelper can signal flags to rtpproxy (e.g. necessary for bridging mode)
nathelper allows "SIP ping"
mediaproxy has signaling AVP
mediaproxy can deal with asymmetric clients
IMO the nathelper benefits overrule the mediaproxy benefits. IMO
asymmetric clients should be blocked (poor implementation). Of course
Cisco gateways are asymmetric, but this is no big deal, as usually there
are no NATs between gateway and proxy. And asymmetric clients do not
work behind NAT.
Conclusion: If you use mediaproxy only for natted clients then you do
not have to care about asymmetric clients in the proxy.
I'm not sure about the fix_contact() function in mediaproxy module. Does
it really change the contact for REGISTERs or does it add a received
parameter like the fix_nated_register from nathelper? If it really
changes the contact then it wont work Nokia Phones.
regards
klaus
I don't see any real issues. It's some
work which has to be done, and
it's not really the most important thing on the todo-list, but it would
remove unneeded redundancy.
It is interesting for me to notice that all these proposals to chop down
mediaproxy come from someone who is not using it. Not from someone who is
using it and wants to improve it, but from someone who doesn't use it and
doesn't know what it has to offer, but for some strange reason feels the
need to modify it to fit his vision of things.
As a conclusion, I'm open to any suggestion that will make mediaproxy
better and easier to use. I will not agree however to any change that
will complicate my life as a mediaproxy user so that someone else who is
not using it feels better over what it provides.
Currently the fact that the contact fixing/checking is present in 2
modules doesn't bother me at all, however all the proposals I've heard
here would make a mediaproxy user's life more complicated for no good
reason and they're not worth the price IMO.
4:38 p.m.
Dan Pascu wrote:
On Tuesday 19 December 2006 15:15, Klaus Darilion
wrote:
Do you mean be manually writing the source IP:port into the received_avp
of registrar module? Yes, that should work. Do you know if this also
adds the ;received=..... parameter to the Contact header in the 200 Ok
response?
regards
klaus
--
Klaus Darilion
nic.at
nathelper has fix_nated_register (which is
essential for some clients)
this is redundant. It can be done with a simple avp_write() in the script.
3:29 p.m.
Dan Pascu wrote:
With this kind of statements (and the previous ones
you made on the
subject) you only prove that you do not use mediaproxy, do not know what
it has to offer when compared to nathelper and do not care too much what
happens to it. This is why it has a README which details its capabilities
and how it compares with nathelper and what are its advantages.
Well, actually I do use mediaproxy exclusively, and I have used the
nat-helping methods of it as well. So this is just a daring statement.
Letting the asymmetric-client feature aside, the functions
"client_nat_test" and "fix_contact" are fully interchangeable with the
correspondent nathelper functions without any side-effects (or at least,
none have been encountered here).
So, if there's another feature mediaproxy has over nathelper (I'm
talking about the modules, or more specifically, about the functions for
fixing Contact/SDP, not the RTP proxy implementation), please go ahead
and tell me, since you're insisting on how much better mediaproxy is.
There's nothing more the readme reveals on this.
On the other hand, this all is not about which version is better,
because it's really not worth the time. There already were lengthy
discussions back in 2004 which didn't come to an agreement, so...
It's just about a way for merging the SIP message altering stuff into
one module and encapsulating rtp proxy controllers into separate modules
for the sake of a cleaner configuration api.
Andy
15 Dec
15 Dec
5:06 p.m.
Maybe the right solution would be to have three modules (new names):
- mediaproxycontroller
- rtpproxycontroller
- natclienthelper
for a mediaproxy solution one would need two modules:
- mediaproxycontroller
- natclienthelper
for an rtpproxy solution one would need two modules:
- rtpproxycontroller
- natclienthelper
Like this, the nat detection would be in one single place
(natclienthelper module).
Memory utilization would benefit from this splitting: load only what you need.
Regards,
Ovidiu Sas
On 12/15/06, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andreas Granig wrote:
--
Klaus Darilion
nic.at
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Makes sense. I use mediaproxy for RTP proxy, but nathelper for
fix_nated.....
regards
klaus
I would say yes...maybe adding 16 for safety
reasons ;).
Good idea, but I was just looking at client_nat_test of mediaproxy
module, not nat_uac_test of nathelper.
To avoid confusions like that, I'd generally propose to rip out the
nat-traversal stuff (client_nat_test, fix_contact) from mediaproxy,
because it does exactly the same as the corresponding nathelper
functions (nat_uac_test and fix_nated_contact). I don't see the point of
having redundant code here. what about "intelligent" ALGs on the
path?
As noted before, customers are strongly advised not to use any. I guess,
you all know why ;o)
And there's no other point on the path where an ALG not under customer's
or our control could be placed in this specific deployment.
Regards,
Andy
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6548
days inactive
6553
days old
16 comments
6 participants
participants (6)
-
Andreas Granig -
Bogdan-Andrei Iancu -
Dan Pascu -
jh＠tutpro.com -
Klaus Darilion -
Ovidiu Sas