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.
_______________________________________________ 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/
