[Users] client_nat_test

[Ovidiu Sas]

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 at 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 at openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
>
>
> --
> Klaus Darilion
> nic.at
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>