I’m sure someone will correct me here if I am wrong but, it is my understanding that the scenario described with the ITSP below isn’t possible at this time. I believe that three issues are at work: NAT translation, authentication, and ITSP support for re-invite (this was discussed in the past, search the archives)
The second scenario you describe is certainly possible if all parties (both remote users and SipX) have public IPs. If you’re using NAT, your only options are the ones Tony described. From: Irena Dolovčak [mailto:irena.dolov...@gmail.com] Sent: Friday, May 28, 2010 6:57 AM To: Tony Graziano Cc: sipx-users@list.sipfoundry.org Subject: Re: [sipx-users] Remote office problem 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 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/
