This brings up very "old" discussions. I had proposed using "different" ip addresses in sipxbridge (internal ip's) to segregate internal users from the sbc function. I also thought it might be easier to implement trunking without dropping registrations and trunk calls and make it easier to implement a standalone sbc/sipxbridge functionality at some point. Of course this might mean multiple nic and address support in sipx.
============================ 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: [email protected] <[email protected]> To: Martin Steinmann <[email protected]> Cc: 'Michael Scheidell' <[email protected]>; [email protected] <[email protected]> Sent: Fri Aug 20 19:38:52 2010 Subject: Re: [sipx-users] SIMPLE SOLUTION FOR ITSP'S WHO SEND TO PORT 5060 Re: iptables experts: port forwarding. Martin, Thanks for the links. Scott nailed on the head with a one liner. Joegen On 8/21/10 7:24 AM, Martin Steinmann wrote: > > Joegen > > I think a possible solution close to what you are suggesting is > captured here. This would likely be the most elegant solution. > > http://track.sipfoundry.org/browse/XX-5010 > > Solving the problem described here might be easier and get us part of > the way. Eventually we will need to address both. > > http://track.sipfoundry.org/browse/XX-4818 > > http://track.sipfoundry.org/browse/XX-8692 > > --martin > > *From:* [email protected] > [mailto:[email protected]] *On Behalf Of *Joegen > Baclor > *Sent:* Friday, August 20, 2010 7:14 PM > *To:* Michael Scheidell > *Cc:* [email protected] > *Subject:* Re: [sipx-users] SIMPLE SOLUTION FOR ITSP'S WHO SEND TO > PORT 5060 Re: iptables experts: port forwarding. > > Just thinking out loud. I am wondering that if carefuly done, the > proxy maybe able to simply forward trunk calls made through 5060 > towards 5080. Proxy must not record-route so that mid-dialog requests > could be handed off straight to the bridge. Any idea why this wasn't > considered instead of kludging it via firewall port forwarding? > > > > > On 8/20/10 10:54 PM, Michael Scheidell wrote: > > > my testing now, with level3 (they currently are sending to port 5080, > sending EVERYTHING to port 5080, I think. maybe I am wrong?) > > you are right. > > I can't just take ANYTHING from the ITSP coming in on udp port 5060 > and fwd to port 5080. > > here was an outbound call (itsp is sending to my port 5080.. but calls > are still on udp 5060) > > tcpdump -n -p not host 10.70.3.3 and not arp and not host > 10.70.255.255 and not host 255.255.255.255 and host 4.55.34.48 and > port 5060 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes > > I ASSUME that with tcp we could have used packet stats to only port > forward new packets? > > does this packet trace suggest that this won't work? > I don't have any rules in place right now, except that I asked L3 to > FWD to my udp port 5080. > when I make an outbound call (udp 5060), they respond on udp 5060. > with the REDIRECT rules in place, this would break the call path, > wouldn't it? > > > 10:51:37.138591 IP 10.72.0.2.5080 > 4.55.34.48.sip: SIP, length: 1072 > 10:51:37.171915 IP 4.55.34.48.sip > 10.72.0.2.5080: SIP, length: 294 > 10:51:39.087239 IP 4.55.34.48.sip > 10.72.0.2.5080: SIP, length: 924 > 10:51:39.330646 IP 4.55.34.48.sip > 10.72.0.2.5080: SIP, length: 965 > 10:51:39.376380 IP 10.72.0.2.5080 > 4.55.34.48.sip: SIP, length: 459 > 10:51:43.651919 IP 10.72.0.2.5080 > 4.55.34.48.sip: SIP, length: 897 > 10:51:43.688742 IP 4.55.34.48.sip > 10.72.0.2.5080: SIP, length: 345 > > > On 8/20/10 10:46 AM, M. Ranganathan wrote: > > It is workable if you do not have remote workers configured. > > We tested (successfully) against AT&T but without remote workers > following that strategy. > > Ranga > > > -- > Michael Scheidell, CTO > o: 561-999-5000 > d: 561-948-2259 > ISN: 1259*1300 > > *| *SECNAP Network Security Corporation > > · Certified SNORT Integrator > > · 2008-9 Hot Company Award Winner, World Executive Alliance > > · Five-Star Partner Program 2009, VARBusiness > > · Best in Email Security,2010: Network Products Guide > > · King of Spam Filters, SC Magazine 2008 > > ------------------------------------------------------------------------ > > This email has been scanned and certified safe by SpammerTrap®. > For Information please see http://www.secnap.com/products/spammertrap/ > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > sipx-users mailing list > [email protected] <mailto:[email protected]> > List Archive:http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
