> thanks, > I'll try it out an let you know. > > It matters if you have (theoretical speaking) the remote user > trying to call an outside number, then the media goes like this : > > remote user ---- internet ----- sipx ------ internet ------ > voip provider > > and i want the media to go directly to provider (because of > the call quality) > > and in case where are two remote users: > > remote user ------ internet ----- sipx ------- remote user
I understand your question and I agree that this would be ideal but unfortunately, it simply isn't possible in almost all cases. Re-using your remote-worker-to-remote-worker example, if sipXecs does not anchor the media then to which IP:Port will each remote worker send their RTP to? Because the remote workers are behind a NAT, their public-facing media IP:port is determined by the NAT when they start transmitting. If you do not have a middle man that is publicly reachable, there is no way that these two remote workers can talk to each other because their public-facing media IP:Port is not known at call setup time (unless they use ICE). Note: in some systems, media anchoring is avoided by relying on STUN but sipXecs didn't go in that direction because it simply isn't reliable enough. As an example, STUN fails when symmetric NATs are being used. > On Fri, May 28, 2010 at 12:44 PM, Tony Graziano > <tgrazi...@myitdepartment.net> wrote: > > > The only thing you can try is aggressive mode in sip to > try to see if the > media will establish as peer-to-peer. > > Remote user utilizes media relay, has 2 modes > (conservative & aggressive). > It requires nat be setup at your router properly for > either to work. > > I don't understand why it matters, if the phone on one > leg of the call is > beHind sipx, it is using the same bandwidth to the > remote user whether > anchored or not. > > > ============================ > 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> > > Cc: sipx-users@list.sipfoundry.org > <sipx-users@list.sipfoundry.org> > Sent: Fri May 28 06:35:31 2010 > Subject: Re: [sipx-users] Remote office problem > > > ok ok.. i think we don't understand each other completely.. > > I understand that 3cx and sipx are different. I have > put 3cx just as an > example to describe to you what I want to do.. I don't > even know if that can > be done with sipx. That's what I'm trying to find out. > And that's why I have > asked you all that stuff. > > I know how to configure remote user, and I tried the > aggressive mode.. but > that isn't just that what I want to accomplish.. > I don't want the sipx to act as a B2BUA.. > > how is it exactly done in sipx? can i get a step by > step report what is > happening in sipx and what sipx servers and services > are involved? I'm just > trying to understand what is happening and what can be > done and what can't.. > > > The only thing I am trying to accomplish is to get the > phones to make calls > peer-to-peer; the sip signaling should still be servers job.. > > > > On Thu, May 27, 2010 at 11:49 AM, Tony Graziano < > tgrazi...@myitdepartment.net> wrote: > > > 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:9000 and 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. > > > > > > > -- > Irena Dolovčak > > > > > > -- > Irena Dolovčak > > _______________________________________________ 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/
