I think ultimately you would want something along the lines of this picture:
http://blog.myitdepartment.net/wp-content/uploads/2009/11/Call-Setup-Example-sipXecs-through-ITSP1.pdf <http://blog.myitdepartment.net/wp-content/uploads/2009/11/Call-Setup-Example-sipXecs-through-ITSP1.pdf>If your ISP sends you a static IP address and you can bridge your modem so the public IP address is sent to a firewall, you can easily have this environment which works, and works VERY well. Should you get excessive dos sip invites, you can simply block them at the firewall with a filter... It is doubtful your modem will do the type of nat traversal needed for a successful rollout for trunking or remote users, so this would be the far simplest approach. On Sun, May 9, 2010 at 7:53 AM, Tony Graziano <[email protected]>wrote: > Didn't mean to answer that twice. Couldn't get BB to send, so went to pc. > > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: Tony Graziano <[email protected]> > To: [email protected] <[email protected]> > Cc: [email protected] <[email protected]> > Sent: Sun May 09 07:09:10 2010 > Subject: Re: [sipx-users] Basic deployment scenario - local DNS server > mandatory? > > Rtp is not established until after legitimacy has been determined. I can > send illegitimate invites forever to port 5060 as a dos attack. An alg > would > still pass this through to whatever proxy you use, so the alg is useless as > a means to protect against it. > > The sipx proxy has permissions that require credentials to process an > outbound call. Inbound calls should always be allowed, because that IS the > nature of SIP. > > Carriers may wish to deploy using a different sbc. SiPx was designed with > enterprises in mind, not carriers. > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: Robert Hoffmann <[email protected]> > To: Tony Graziano <[email protected]> > Cc: sipx-users <[email protected]> > Sent: Sun May 09 05:35:18 2010 > Subject: Re: [sipx-users] Basic deployment scenario - local DNS server > mandatory? > > > It (ALG) gets in the way of sipx in trying to negotiate the sip > > registration > > or media. > > > > > I am a little confused now - when I started gathering info on SIP PBX > deployment an ALG / B2B-UA made sense for me as a means of only opening as > few inbound / outbound ports as possible (which is a good thing, right?). > My > ALG would basically work as a SBC that acts like a virtual endpoint for > incoming calls, effectively protecting sipX from getting swamped with > illegitimate RTP streams (i.e. a DOS attack) because the ALG only opens the > ports negotiated in the SDP. If I got you right - please correct me here - > you suggest that the typical approach for deploying sipX is more or less > exposing it with 1001 port forwardings (SIP 5060 + RTP 30000 - 31000) and > no > outbound port firewall rules (as any destination port number may be needed > for SIP signaling or RTP streams). Would you really do that in a > professional environment? This may sound like criticism but the truth is > that I have absolutely no clue. :-) Please enlighten me! > > > > Leaving it on will result in broken media for remote users as well as any > > itsp calls. It is a big fat no-no. > > > > > How would a SIP carrier use sipX if it were incompatible to SBCs due to the > fact that you cannot "dumb it down" ? Maybe I did not understand the scope > / > goal of sipX? >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
