OK. I'll try to reply in a way that hopefully clarifies a few things, if I miss a response someone was looking for, please feel free to contact me directly.
Our SBC servers (which are running sipXecs, and ONLY running the SIP
TRUNKING Role) are only doing call build up. Actual voice traffic (voice
data/payload/whatever) is handled by the SIP Router Role (of which SIP Proxy
is part of).
Tony - you keep saying SIP Proxy needs to be enabled on any system in an HA
cluster. I get that, since SIP Proxy is a service carried on the SIP Router
role (which is the only 'HA enabled' roles in sipXecs at this time). It is
of course enabled on the 'core' (SIP ROUTER ROLE) servers (Primary and
Secondary, or Primary and Redundant to use terms directly from the software
itself). There is no SIP Proxy ROLE, SIP Proxy is a service that runs as
part of the SIP Router Role. So by telling me over and over that the SIP
Proxy must be running on all servers, you are seriously confusing me, and I
bet, a lot of the community that is not as familiar with the product as you
are.
So. The way our system is set up (currently, right now, today) is like this
(and works mostly - RE: my strange SRV happenings with inbound calls hitting
SIPX2 I mentioned some time back - I now realize that it's not an
Active/Passive HA, but rather an Active/Active one):
. On our DMZ are two sipXecs servers, each of which is ONLY running
the SIP Trunking Role (which is what I refer to as our SBCs (sorry for any
confusion!)). All these two servers do, is handle singalling with our ITSPs.
Only ONE of these actually has a Gateway and Dialing plan attached to it -
the other is doing nothing (we hope to get it hooked up to sipstation.com
soon)
. Inside our network are two more servers, a Primary and Redundant
sipXecs server, each of which has a variety of roles. Specifically though:
server 1 has SIP Router Role enabled, and server 2 has Redundant SIP Router
Role. Server 1 carries the rest of the Roles. Our SRV records (which are set
up correctly) are all prioritized AND weighted to use server 1 (though I'm
still oddly seeing calls try to go to server 2, but that's off topic).
In the proposition I made in my original email of this thread, all I break
out the VM and Conference Roles onto stand alone physical servers, and
virtualized the remaining roles (IM and ACD).
This has been proven to work by me, with an ITSP, at LEAST with minimal call
volume. If someone can tell me why it won't work, please do so - but explain
it as well, rather than simply telling me it'll get jitter.
I say again: since the SBCs don't actually have any voice traffic on them,
it should be perfectly safe to virtualize those.
In this setup, sipXbridge is NOT anchoring the media, in fact, the SIPX
Router servers are. And always will. sipXbridge only anchors the call if
they are also running the SIP Router Role. Am I mistaken there?
I can send along a SIPViewer breakdown of what an ITSP call looks like in
our environment if you want, to help clarify more if necessary.
Also - I didn't see any responses yet - does anybody know anything about
load-testing tools - actually used them - as this would be a great, and very
quick way, to prove if my setup works or not.
I own the book, I'm familiar with the wiki, and even so I still have
problems finding answers to questions in those places - which is why I am
turning to you, the experts, more and more often. Apologies if this comes
off as ranting or rude, but like Matt mentioned in one of his replies, a lot
of responses I get back from the list are not informative enough to be
helpful.
Peter Talbot
[v1.0.07.109]
From: [email protected]
[mailto:[email protected]] On Behalf Of Tony Graziano
Sent: Thursday, September 23, 2010 11:33 AM
To: Discussion list for users of sipXecs software
Cc: [email protected]
Subject: Re: [sipx-users] SIP Server Questions (Virtual vs Physical)
(but I don't think it is a "vmware" specific thing, in general, it a virtual
server "thing")
Media suffers from latency, and if the media is being played from a virtual
server with a latency issue (perhaps due to timing) "yucky stuff happens".
What he is saying is the media is anchored but being "bounced" so it is not
being encoded in any way.
I believe what he is saying, though I am not sure anyone has tested it under
a real load to verify this does not have a detrimental effect. I would still
have a concern over "resources" in general in a virtual environment, but
thats me.
On Thu, Sep 23, 2010 at 11:17 AM, Paul Scheepens <[email protected]> wrote:
Hi Joegen,
Just so that I (and the rest) understand it correctly:
Do you mean that VMWare only gives problems if audio needs to be encoded
(generated)/recoded(processed)?
And as the SBC is only relaying the RTP stream it does not matter that the
timers are not OK.
Paul
Joegen Baclor <[email protected]> wrote:
>
> sipXBridge will not be an issue with VM. The only issue with VM and
> Media Servers like Freeswitch in your case is the accuracy of the
> timers used in a VM which will be directly have an affect on audio
> sampling. The media anchor is sipXrelay. It does not process nor
> generate any media and, thus, will not require multi-media timer
> accuracy to perform its function. Hope that clears things up a bit.
>
> Joegen
>
>
> On Thursday, 23 September, 2010 04:12 PM, Mark Theis wrote:
> This is my point. I am looking for the answer. For some reason it
> feels like people make comments that do not actually inform me of
> anything. SipXbridge is not helping me. But... What would be the
> best alternative?
>
> Can someone please give the rest of us some pointers? I know that I
> have read all the wiki and I am still lost. Failover and redundancy
> is driving me crazy. Does redundant gateways (sip trunks) work?
>
> The wiki has just enough info to nake ne hungry. Any alternative links?
>
> Sorry to rant. Getting very fryustrated.
>
> -Mark
> Mark D. Theis
>
> Southern California Telephone & Energy
> 27515 Enterprise Circle West, Temecula Ca. 92590
>
> From: [email protected] <sipx-users-
> [email protected]>
> To: Discussion list for users of sipXecs software <sipx-
> [email protected]>
> Cc: [email protected] <sipx-users-
> [email protected]>
> Sent: Thu Sep 23 00:48:16 2010
> Subject: Re: [sipx-users] SIP Server Questions (Virtual vs Physical)
> R-r-r-r-right, sipxbridge is a-a-a-a-nchoring the m-m-m--media...
> On Thu, Sep 23, 2010 at 3:06 AM, Paul Scheepens <[email protected]>
wrote:
> Just a question on the SBC's, as they are handling voice as well,
> wouldn't there be a (possible) issue with VM.
> TeTeTeTalking with the outside world should be PePePePerfect IMHoHO.
>
> Paul
>
>
> From:
>
> Mark Theis <[email protected]>
>
> To:
>
> Discussion list for users of sipXecs software
<[email protected]>
>
> Date:
>
> 23-09-2010 06:40
>
> Subject:
>
> Re: [sipx-users] SIP Server Questions (Virtual vs Physical)
>
> Sent by:
>
> [email protected]
>
>
>
>
>
> Peter,
>
> I like your plan. I am not an expert (maybe because I have only
> been working with this for a month or so) yet, but.. What were you
> thinking to use as your SBC1 and SBC2? Each of your other devices'
> names hinted at (or explicitly said) sipXecs. but the SBC has me
> wondering. Are you thinking to have 2 separate ITSP Gateway (SBC)
> sipXecs VM's?
>
> As you might have noticed from my last post a couple minutes ago, I
> want to do something very similar to yours. but. all of my users
> will be external. And. I have my servers geo-diverse. This may be a
> problem for me, but I could not find another solution aside from
> sipXecs that claimed the ability to solve my problems.
>
> Thanks!
>
> Mark Theis
>
> Southern California Telephone and Energy
>
> Office (951) 693-1880 Ext. 212
> Fax (951) 693-1550
> Cell (951) 545-1013 or (949) 682-VOIP
>
> 27515 Enterprise Circle West
> Temecula, CA. 92590
> [email protected]
>
> From: [email protected] [ <mailto:sipx-users->
mailto:sipx-users-
> [email protected]] On Behalf Of Talbot, Peter
> Sent: Wednesday, September 22, 2010 1:43 PM
> To: Discussion list for users of sipXecs software
> Subject: [sipx-users] SIP Server Questions (Virtual vs Physical)
>
> Hi all.
>
> In further pursuing a 'Production Rollout' ready implementation of
> sipXecs, I had some final questions, mostly in regards to what can
> and cannot be Virtualized. Currently it is looking like anything
> that actually handles voice traffic (whether recorded messages or
> ongoing conversations) should remain physical due to timing
> constraints, but other Roles can be Virtualized.
>
> What I am loosely looking at then, in a server layout fashion, would
> be something along the lines of:
>
> SIPX1 - Physical Server (Internal network) - Management/Primary SIP Router
> SIPX2 - Physical Server (Internal Network) - Redundant SIP Router
> SBC1 - Virtual Server (DMZ) - Primary ITSP Gateway (SBC)
> SBC2 - Virtual Server (DMZ) - Redundant ITSP Gateway (SBC)
> SIPCN1 - Physical Server (Internal Network) - Conferencing
> SIPWM1 - Physical Server (Internal Network) - Voicemail
> SIPX3 - Virtual Server (Internal Network) - ACD/Instant Messaging
>
> Physical and Virtual Servers would all be 64bit, running a minimum
> of 8GB of RAM, the VM1 machine having extra storage space, and all
> with a good processors (well above the recommended listed in
> Michael's book) and GB Ethernet. Virtual Machines would have
> slightly less power, but the Roles are slightly less power hungry
> anyway. In this instance, Remote Workers would be connected via VPN
> to our internal network, so Remote Worker traffic would act just
> like 'inside user' traffic.
>
> Does the above seem like a plausible solution?
>
> As a secondary necessity - in regards to load testing - what tools
> of those available (like WinSIP) would any of you recommend?
>
> Peter Talbot
> [v1.0.07.109]_______________________________________________
>
> sipx-users mailing list
> [email protected]
> List Archive:
> <http://list.sipfoundry.org/archive/sipx-users/>
http://list.sipfoundry.org/archive/sipx-users/
>
> _______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive: <http://list.sipfoundry.org/archive/sipx-users/>
http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> --
> ======================
> 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/>
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/>
http://list.sipfoundry.org/archive/sipx-users/
> _______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive: <http://list.sipfoundry.org/archive/sipx-users/>
http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
======================
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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
