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

Andreas Granig wrote:

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.

Makes sense. I use mediaproxy for RTP proxy, but nathelper for fix_nated.....

regards klaus

...

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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

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.....

On Friday 15 December 2006 20:09, Andreas Granig wrote:

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.

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 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

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.

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.

Dan Pascu wrote:

On Tuesday 19 December 2006 15:15, Klaus Darilion wrote:

...

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.

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

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@pernau.at wrote:

Andreas Granig wrote:

...

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.

Makes sense. I use mediaproxy for RTP proxy, but nathelper for fix_nated.....

regards klaus

...

...

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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

-- Klaus Darilion nic.at

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users