Consider setting up for remote users (assuming sip trunking is not needed).
System>Internet Calling>Nat Traversal. Server>(yours)>Media Relay>advanced)>aggressive. Server>(yours)>NAT>setting the static public IP On Thu, May 27, 2010 at 5:40 AM, Tony Graziano <tgrazi...@myitdepartment.net > wrote: > You miss the point in that the 3cx handles nat traversal in a very > different way than sipx. > > With sipx, that same procedure requires use the media relay, which you > might adjust to be in "aggressive" mode, but there is not guarantee it would > work in every instance, hence the default mode is "conservative". > > > On Thu, May 27, 2010 at 3:49 AM, Irena Dolovčak > <irena.dolov...@gmail.com>wrote: > >> Hi, >> >> I don't think anchoring is the only way.. >> >> and there are more ways to bypass NAT, not just the SBC that handles it. >> >> >> I have done this with 3CX PBX and mikrotik routers on both ends. >> >> I tried to reproduce the same thing in 3CX PBX, and here is the picture >> with steps. >> I'm not sure if all is 100% OK, I tried to attach the important things. >> >> I want to do the same thing in sipx to.. what are the differences between >> them? (the 3cx and sipx) in the structure of the pbx.. >> >> PhoneA – user >> PhoneB – user2 >> >> 1 –src. Address/port 192.168.0.245:5062 dst address/port >> 82.210.15.45:5060 >> phone A sends an INVITE message >> (sip:u...@82.210.15.45:5062 to us...@82.210.15.45) >> >> 2 – the NAT translates the src address to his public address >> 89.201.135.15, the src port stays the same >> -The router sends the packet to the internet >> The router gives his public ip address to eht phone. No STUN is involved. >> >> 3 – the packet comes to the second router; he sees the dst. Address >> 82.210.15.45 and the dst. port 5060 – he knows he must forward the packet >> with the dst port 5060 to the internal IP address 192.168.1.15 >> >> 4 – the 3cx PBX gets the packet on port 5060 from the ip address >> 89.201.135.15 >> It examines the packet and sees that user is trying to call user2 >> >> 5 – The PBX send the user an information packet telling him that it is >> trying to contact user2; >> The message goes back to dst address 89.201.135.15:5062 >> >> 6 – the PBX sends an INVITE message to user2 >> (sip:u...@82.210.15.45:5062 to us...@82.210.15.45) where the PBX tells >> user2 how to contact user in SDP message which is sends together with the >> SIP message >> In the SDP message, user has send information on which port should the >> media packages be send to. The PBX forwarded the message to user2 >> The message goes from src address 192.168.1.15 on port 5060 to dst >> address/port 192.168.1.20:5060 >> >> 7 – user2 starts to ring and sends a RINGING message back to the PBX so it >> knows that he is ringing; >> It also sends the SDP information where on which port to send the media >> packets >> Src address/port 192.168.1.20:5060 dst address/port 192.168.1.15:5060 >> >> 8 – the PBX gets the message from user2 and forwards it back to user so he >> allso knows where to send media packets; it also sends the ring alert to >> user so the user knows user2 is ringing >> The packet is send to the router with Src address/port 192.168.1.15:5060dst >> address/port >> 89.201.135.15:5062 >> >> 9 – the router gets the packet form the PBX and sees the dst address/port >> 89.201.135.15:5062; to be able to send the packet, he traverses the src >> address 192.168.1.15 to 82.210.15.45 and sends it to the internet >> >> 10 – the second router gets the message now with src address >> 82.210.15.45:5060 and dst address 89.201.135.15:5062; he knows he has to >> forward the message back to private ip address 192.168.0.245:5062 >> >> 11 – when the user2 answers the call, the phone sends an OK message that >> it has picked up the phone. (The process is the same as at step 10) >> >> 12 – the phoneB sends the RTP packet direckt to the phoneA as it has all >> necessary information as the Ip address and port to which he should send >> it. >> Src address: 192.168.1.20:9000 dst address 89.201.135.15:11000 >> the router gets the packet, translates the private IP to 82.210.15.45 and >> send it to 89.201.135.15:11000 >> The second router gets the packet with src address/port 82.210.15.45:9000and >> dst address/port >> 89.201.135.15:11000 and it knows that it must forward it to the private >> ip address 192.168.0.245:11000 >> >> 13 – when user hang up, the phone sends a BYE message to the PBX to alert >> user2 >> Src address/port 192.168.0.245:5062 dst address/port 82.210.15.45:5060 >> >> 14 – the router gets the message, it outs a new src address >> (89.201.135.15) and send it to the dst address 82.210.15.45 >> >> 15 – the router gets the packet with dst address 82.210.15.45:5060 and it >> forwards it to internal ip 192.168.1.15 becouse it is tols to send the >> message with dst port 5060 to that ip address >> >> 16 – the PBX gets the message, and sends the message to user2 on ip >> address 192.168.1.20 >> >> 17- user2 sends an ACK message to the PBX. The call ends >> >> >> >> >> On Fri, May 21, 2010 at 1:55 PM, Tony Graziano < >> tgrazi...@myitdepartment.net> wrote: >> >>> Yes, vpn the remote site and it will take the media peer-to-peer. >>> >>> You seem to be stuck on the fact the sipx must anchor the media and fpr >>> whatever reason don't want to do that. It ONLY ANCHORS the media for the >>> calls that go through NAT, it won't anchor the media for you lan-to-lan >>> calls. >>> >>> In SIP, anytime you cross NAT something needs to anchor the media. That >>> device is called a SBC. >>> >>> I think if you want it to work some other way using a SIP (not sipx) >>> based >>> system, you need to invent your own technology. >>> >>> Good luck. >>> ============================ >>> Tony Graziano, Manager >>> Telephone: 434.984.8430 >>> Fax: 434.984.8431 >>> >>> Email: tgrazi...@myitdepartment.net >>> >>> 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: Irena Dolovčak <irena.dolov...@gmail.com> >>> To: Tony Graziano <tgrazi...@myitdepartment.net> >>> Sent: Fri May 21 07:40:57 2010 >>> Subject: Re: [sipx-users] Remote office problem >>> >>> I'm not sure am I following you. >>> >>> Are you saying that the sipx can only be configured to anchor the media >>> (as >>> a B2BUA)? Is there no other solution? >>> I understand that the sipxbridge anchor the media, that's why I removed >>> it. >>> >>> Is there any solution that I could use to make the remote worker to >>> connect >>> in a by-pass mode and not trunked? >>> >>> >>> > >>> > I thbik it you have remote workers enabled and server behind nat >>> > configured >>> > "it should work". Right now sipx is being told to route to ports it is >>> not >>> > employing because the sipxbridge component is not being used not is the >>> > remote workers aspect. If you support either, you define an SBC, you >>> have >>> > none. That's what sipxbridge does. Ingate makes a nice one too. >>> > >>> > >>> What exactly do you mean by "it should work"? >>> >>> -- >>> Irena Dolovčak >>> >> >> >> >> -- >> Irena Dolovčak >> > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: tgrazi...@voice.myitdepartment.net > Fax: 434.984.8431 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: helpd...@voice.myitdepartment.net > 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: tgrazi...@voice.myitdepartment.net Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net 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 sipx-users@list.sipfoundry.org 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/
