+1 Agreed. I tried using a sip uri from an itsp to get around some of the port 5080 stuff just today. Regardless of the syntax I use:
ip:port 1.2.3.4:580 sipdomain:5080 dns srv (subdomain) with sip pointing to port 5080 hostname:5080 The result was the call came into port 5080, but the invite still said: 18:54:29.636192 00:22:2d:6c:c6:52 > 00:0c:29:31:ec:cc, ethertype IPv4 (0x0800), length 74: (tos 0x20, ttl 51, id 38450, offset 0, flags [DF], proto TCP (6), length 60) 34.69.33.146.38781 > 89.70.238.20.5080: S, cksum 0x8ee0 (correct), 1561857714:1561857714(0) win 5840 <mss 1460,sackOK,timestamp 90761893 0,nop,wscale 7> 18:54:40.469946 00:22:2d:6c:c6:52 > 00:0c:29:31:ec:cc, ethertype IPv4 (0x0800), length 1514: (tos 0x20, ttl 51, id 51654, offset 0, flags [+], proto UDP (17), length 1500) *34.69.33.146.5060 > 89.70.238.20.5080: SIP, length: 1472* * * So the remote end sent the call to port 5080, good. BUT the invite is still sent to the sip proxy. * * * **INVITE sip:[email protected] <sip%[email protected]>SIP/2.0 * * * So, some extra attention will have to be paid to how this is implemented, because even when it is sent as a sipuri, it doesn't behave as expected, the proxy seems to be in the way even though port 5080 was stated. It would be nice to be able to handle REFER at sipxbridge when a foreign system makes a sip call and let sipxbridge act as more of an SBC than a b2bua, so more flexible ITSP functions can be used by the system. Tony On Fri, Aug 20, 2010 at 7:38 PM, Joegen Baclor <[email protected]>wrote: > 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]<[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] > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
