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: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Joegen Baclor Sent: Friday, August 20, 2010 7:14 PM To: Michael Scheidell Cc: sipx-users@list.sipfoundry.org 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 SpammerTrapR. For Information please see http://www.secnap.com/products/spammertrap/ _____ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
