I will encourage you to look this over: http://blog.myitdepartment.net/wp-content/uploads/2009/11/Call-Setup-Example-sipXecs-through-ITSP1.pdf
It may help explain things a little to you. On Mon, Jul 5, 2010 at 9:53 AM, Tony Graziano <[email protected]>wrote: > I dont know why you have port 5070 and 5090 stated. I assume your ITSP > shows you registered via port 5080, and its likely they will send you calls > on 5080. When you send calls to them, it should be on 5060, but in frame 14 > you are sending "to them" on port 5080. > > Can you explain why you have changed the ports from defaults? I am sure the > ITSP does not like the call being send on port 5080, but they should be > sending you a better explanation/error message. Did you ask them if they > allow that? I also see the transaction last about 2 seconds, and the ITSP is > not responding probably because they probably don't like that and ignore the > transaction altogether. > > 1. When you register to the ITSP, you should try to register on port 5080. > THe ITSP "should" try to send you calls on the port you registered from. > 2. Do not try to create a siptrunk freehand, instead use one (like voip.ms) > and alter the information for your ITSP gateway/registrar. > 3. Do not alter the port you send the ITSP calls on. Instaed, just send > them the calls on port 5060. > 4. Please ensure you have ports 5060 (udp/tcp), 5080 (udp) and 30000-31000 > (udp) properly stated in your firewall. Right now, there is no way the audio > would work. > > > > On Mon, Jul 5, 2010 at 9:40 AM, [email protected] <[email protected]>wrote: > >> Thanks for your answers and fast reply, Tony. >> >> Sorry for the trace, yes i altered it to mask some sensitive information >> from trace. I will be more careful for the next time and will follow >> your advice for clarifying. Sorry again :) >> >> I was thinking that not sending the public ip address might be the >> reason for all these problems. >> >> How do i need to proceed, is this a sipxecs configuration problem or it >> is because incomplete firewall rules as you commented already in your >> previous post? >> >> On Mon, 2010-07-05 at 09:31 -0400, Tony Graziano wrote: >> > Wow. How in the world can that ever work? >> > >> > >> > Look at the trace. You are not sending the real IP address of sipx to >> > the ITSP I believe. It will of course timeout because it can't route >> > to you. Besides the domain name, did you alter the trace to make it >> > unintelligible? If so, you need to clarify that or noone will be able >> > to follow the trace. >> > >> > On Mon, Jul 5, 2010 at 9:25 AM, [email protected] >> > <[email protected]> wrote: >> > Sorry, i forgot to attach the trace. Here it is. >> > >> > >> > On Mon, 2010-07-05 at 16:17 +0300, [email protected] wrote: >> > > Hi, >> > > >> > > before asking my questions i would like to explain our >> > installation and >> > > network, so you can have a better idea what we have done and >> > we are >> > > trying to do. >> > > >> > > We have one machine with 1 public ip address. We have >> > installed on this >> > > machine openvpn server and also virtualbox. >> > > >> > > We created one virtual machine on vbox that have centos 5.5 >> > installed >> > > and on it sipxecs. >> > > >> > > On host machine we create a tap0 interface and then we add >> > tap0 to a >> > > bridge interface with ip 10.1.1.1. We create this bridge >> > interface in >> > > order to give internet access to guest machine and to make >> > visible guest >> > > from host machine. On guest machine we use one interface >> > with ip >> > > 10.1.1.2. In order to give internet access to guest machine, >> > we create >> > > nat on host machine. >> > > >> > > We follow this article for vbox networking: >> > > http://www.virtualbox.org/wiki/Advanced_Networking_Linux >> > > >> > > As you already know on host machine we have installed >> > openvpn and it >> > > acts as vpn server. We have set openvpn to use tap device >> > and to act as >> > > a bridge and openvpn has this configuration: >> > > >> > > port 1194 >> > > proto udp >> > > dev tap0 >> > > >> > > ca ca.crt >> > > cert server.crt >> > > key server.key >> > > dh dh1024.pem >> > > >> > > server-bridge 10.1.1.1 255.255.0.0 10.1.1.3 10.1.1.254 >> > > ifconfig-pool-persist ipp.txt >> > > client-to-client >> > > client-config-dir ccd >> > > >> > > keepalive 10 60 >> > > comp-lzo >> > > user nobody >> > > group nobody >> > > persist-key >> > > persist-tun >> > > status openvpn-status.log >> > > verb 3 >> > > >> > > When we try to register over vpn all is ok and our >> > registratin urls >> > > looks this way: >> > > >> > > <sip:[email protected]:40200;x-sipX-nonat> >> > > >> > > Outgoing and incomming calls between sipx users is ok and >> > internal >> > > communication is ok. At least it looks ok from our tests. >> > > >> > > Now we are trying to make sipxecs to be accessible also from >> > non vpn >> > > users (remote users) and to be able to call via ITSP and to >> > receive >> > > calls from ITSP. >> > > >> > > Registration from remote users also look ok. We are able to >> > register and >> > > the url looks ok. >> > > >> > > Until this moment all is ok. The problem comes when we try >> > to call out >> > > via ITSP. >> > > >> > > In logs i see that we register to ITSP without any problems, >> > in sipx web >> > > interface also shows AUHTENTICATED. >> > > >> > > The problem appear when i try to make outgoing call via >> > ITSP. Then on >> > > the phone i get "408 ITSP Time out". I checked the traces, >> > but cannot >> > > figure out what the problem is. >> > > >> > > I was thinking that the problem maybe the rules that i use >> > for >> > > forwarding the ports to sipx from public interface on host >> > machine. But >> > > i'm not sure if this is the problem. >> > > >> > > I use these rules: >> > > >> > > IPTABLES=/sbin/iptables >> > > export EXTIF=eth0 >> > > export BRIF=br0 >> > > >> > > # my sipXecs proxy server and sipxbridge run here. >> > > export SIPXADDR=10.1.1.2 >> > > export PORTRANGE=30000:31000 >> > > >> > > >> > > #set a default policy >> > > /sbin/iptables -P INPUT ACCEPT >> > > /sbin/iptables -F INPUT >> > > /sbin/iptables -P OUTPUT ACCEPT >> > > /sbin/iptables -F OUTPUT >> > > /sbin/iptables -P FORWARD DROP >> > > /sbin/iptables -F FORWARD >> > > /sbin/iptables -t nat -F >> > > >> > > # set forwarding and nat rules >> > > /sbin/iptables -A FORWARD -i $EXTIF -o $BRIF -j ACCEPT >> > > /sbin/iptables -A FORWARD -i $BRIF -o $EXTIF -j ACCEPT >> > > >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport >> > 5060 -j >> > > DNAT --to-destination $SIPXADDR:5060 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp >> > --dport 5060 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport >> > 5060 -j >> > > DNAT --to-destination $SIPXADDR:5060 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp >> > --dport 5060 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport >> > 5070 -j >> > > DNAT --to-destination $SIPXADDR:5070 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp >> > --dport 5070 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport >> > 5070 -j >> > > DNAT --to-destination $SIPXADDR:5070 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp >> > --dport 5070 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport >> > 5080 -j >> > > DNAT --to-destination $SIPXADDR:5080 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp >> > --dport 5080 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport >> > 5080 -j >> > > DNAT --to-destination $SIPXADDR:5080 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp >> > --dport 5080 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport >> > 5090 -j >> > > DNAT --to-destination $SIPXADDR:5090 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp >> > --dport 5090 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport >> > 5090 -j >> > > DNAT --to-destination $SIPXADDR:5090 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp >> > --dport 5090 -j >> > > ACCEPT >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport >> > 9090 -j >> > > DNAT --to-destination $SIPXADDR:9090 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp >> > --dport 9090 -j >> > > ACCEPT >> > > >> > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport >> > 81 -j DNAT >> > > --to-destination $SIPXADDR:8443 >> > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp >> > --dport 8443 -j >> > > ACCEPT >> > > >> > > /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE >> > > >> > > >> > > Are these rules above wrong? If yes, then what are the right >> > rules that >> > > i need to use when sipxecs is located in private network >> > behind NAT? >> > > >> > > I suppose there are a lot of people that have such/similar >> > installations >> > > and i will be very happy if you share your experience in >> > such >> > > installations. >> > > >> > > Is it possible something to be wrong in headers and this way >> > ITSP does >> > > not know where to send packages? >> > > >> > > I attach one of the traces for failed outgoing call where i >> > get ITSP >> > > Timeout error. >> > > >> > > Let me know if you need snapshot of sipx installation and i >> > will send it >> > > too. >> > > >> > > What we need know is to get working outgoing and incoming >> > calls via >> > > ITSP. >> > > >> > > P.S. we have installed sipxecs 4.2.0-018575. >> > > >> > > Thanks in advanced! >> > > >> > >> > >> > >> > _______________________________________________ >> > 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/ >> > >> > >> > >> > -- >> > ====================== >> > 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. >> > >> > >> >> >> > > > -- > ====================== > 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. > > -- ====================== 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 Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
