Simon Hobson <[email protected]> wrote:
> It depends a lot on your setup. In many cases, loading SIP
> helper will completely screw up your connection, in others it's
> needed. A good example of where NAT == Broken.
> Personally I make a point of disabling any SIP helper and
> configuring the endpoints to deal with the NAT - I find it's
> more reliable. A lot depends on the capabilities of the devices
> on all ends of the connections. On "sensible" NAT gateways, a
> device can use STUN to work out it's public IP and type of NAT,
> and then work reliably - don't try this witha Zyxel router as
> they go out of their way to f**k stuff up. Most public VoIP
> providers have NAT gateways which essentially ignore the
> content of the ISP messages and look to see where the RTP
> stream actually arrives from - and then proxy that to the final
> destination.
I work from the router point of view. I have seen that there can
be a problem with certain phones when the nf_nat_sip (and/or)
nf_conntrack_sip modules are loaded. At least, that's what it
looks like at the moment - still under test. I'm looking at a
simple way to have SIP support for users. Having a GUI option to
unload a 'SIP helper' (if SIP does not seem to work) is not much
user friendly - a bit too arcane. Kernel is 3.0.0 for ppc arch.
Any suggestions ?
Thanks.
________________________________
De : Simon Hobson <[email protected]>
À : [email protected]
Envoyé le : mardi 8 janvier 2013 7h47
Objet : Re: [Shorewall-users] Shorewall and SIP phones
Benny Pedersen wrote:
>> Are there general guidelines around on how to configure Shorewall
>> for use with SIP phones ? Especially regarding (some?) Cisco SIP
>> phones which are expecting a reply at port 5060 while sending from an
>> arbitrary high port.
>
>for sip protocol to work there is just that shorewall must load sip
>conntrackers, so make sure there is sip conntracker in your kernel,
>thats all
>
>atleast it works with my linksys spa 2102
It depends a lot on your setup.
In many cases, loading SIP helper will completely screw up your connection, in
others it's needed. A good example of where NAT == Broken.
Personally I make a point of disabling any SIP helper and configuring the
endpoints to deal with the NAT - I find it's more reliable. A lot depends on
the capabilities of the devices on all ends of the connections. On "sensible"
NAT gateways, a device can use STUN to work out it's public IP and type of NAT,
and then work reliably - don't try this witha Zyxel router as they go out of
their way to f**k stuff up. Most public VoIP providers have NAT gateways which
essentially ignore the content of the ISP messages and look to see where the
RTP stream actually arrives from - and then proxy that to the final destination.
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
