Send me a link to that post on the pfsense board if you would. On Fri, Sep 30, 2011 at 12:24 PM, Max DiOrio <[email protected]> wrote: > That was the setup that pfSense support recommended. I'm surprised that > being the firewall experts, they didn't recommend a different configuration > like the one that Tony offered me. Our office is quite slow today and > Monday, so Tuesday would be the first good test of call quality with higher > volume. > > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Tony Graziano > Sent: Friday, September 30, 2011 12:10 PM > To: Discussion list for users of sipXecs software > Subject: Re: [sipx-users] pfSense QoS > > He was prioritizing an IP address in his firewall. The problem with that is > he was not prioritizing the ports only, so when he hits the webgui for the > firewall, it cannot discern that traffic from voice traffic. > > On Fri, Sep 30, 2011 at 12:07 PM, <[email protected]> wrote: >> Anyhow, increase the bandwidth for Voip, I think you have no other >> important stuff over this line, so give it 100% (or just 80%). >> The question is what is going on so that 1 call can be affected and 4 >> can be OK, it must be some non-voip traffic that is eating up the bandwidth. >> Question is also what bandwidth, internally or internet. It would be >> nice to see whether your captures show packet loss. >> >> Paul >> >> Max DiOrio <[email protected]> wrote on 30-09-2011 17:18:57: >> >> >>> Sorry, my day had already ended here at work by the time I got around >>> to seeing these posts. >>> >>> I am using the pfSense admin interface remotely. The interfaces are >>> set to default for both, which is detected as 100baseTX full-duplex. >>> >>> The system is a Pentium D 3.4GHz with 1GB of RAM, only 20% used. >>> The system is oversized. >>> >>> I can't connect a phone to the modem since it's in bridged mode. >>> Phones are connected to my DLink PoE switch and straight into >>> pfsense. Our office is almost always quiet. Only one or two calls >>> going on at any given moment. We only have 10 phones. It's totally >>> random when the call quality is affected. Could be on a single call, >>> but it could be fine when 4 calls are going on at the same time. >>> >>> I have packet captures taken all day yesterday on the pfSense box on >>> both the LAN and the WAN side of the box. I need to copy them over >>> to my PC to look. I have the caps from two calls in which I know the >>> voice quality was affected. >>> >>> [image removed] >>> >>> From: [email protected] [mailto:sipx-users- >>> [email protected]] On Behalf Of [email protected] >>> Sent: Friday, September 30, 2011 3:07 AM >>> To: Discussion list for users of sipXecs software >>> Subject: Re: [sipx-users] pfSense QoS >>> >>> I think Max has a local problem. Especially if he is using the >>> pfsense gui from the local network (never saw an answer to that >>> question if I am not mistaken). >>> Either the pfsense box has a duplex mismatch, is heavily under >>> dimensioned or something else is wrong. >>> >>> I would connect a phone to the ADSL modem (so as close to the >>> internet, separated from the rest of the network through the pfsense >>> box, but not the internet) and do some tests from the user phones. >>> If you don't have traffic monitoring it would be good to look at port >>> utilization and queueing in the switch(es). >>> QoS is certainly nice and needed, but it only kicks in when an >>> outgoing port queues anything, so you need to be generating quite >>> some traffic before it kicks in. >>> (At home I have a 2Mbps/256kbps ADSL (because of distance issues) and >>> voip-voice is A-OK without QoS, but when daughter-dear starts a >>> Youtube it's byebye decent audio (only for me, not for the other >>> side, so the 2Mbps is the problem, not the 256 Kbps, this also shows >>> how much effort ITSP's put in in providing decent services >>> (ISP=ITSP))))))))). >>> >>> BTW: If you have any managed switches in the flow where you did not >>> configure QoS then the QoS is normally back to 0, normally a managed >>> switch by default does not trust QoS settings in packets and resets >>> it to nada. Cisco style: mls qos trust dscp and mls qos trust cos >>> >>> BTW2: Have you placed test calls when the network was relatively >>> quiet (out-of-office hours)? >>> >>> Paul >>> >>> Tony Graziano <[email protected]> wrote on 30-09-2011 02:18:46: >>> >>> > I would do a traceroute to somewhere like googledns, 8.8.8.8, then >>> > look at the first few hops and see if they are also on the >>> > providers network and whst your latency to those points are and >>> > also to the itsp gateway/proxy you use. >>> > >>> > I just went through a dozen sites for a customer to make >>> > recommendations. After doing the basic reports, and wasting a lot >>> > of time with teeny providers saying they were fine, we started >>> > replacing the connection with something better than 2.5mb down/512k >>> > up no name dsl providers. We saw instant results and none of these >>> > sites are running voice services over the internet. >>> > >>> > Always look at the entire network and if your internet is crappy, >>> > set expectations accordingly and have it fixed or replaced. Whether >>> > it is used just to get to the provider pop and not the internet >>> > doesnt matter. What matters is whether it is a quality connection. >>> > If you dont have the quality, there a whole lot you just cant pull of. >>> >>> > On Thu, Sep 29, 2011 at 2:56 PM, Max DiOrio <[email protected]> >>> > wrote: >>> > Given my ISP is my ITSP, shouldn' tmy delay be lower than 16ms avg? >>> > >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Tony Graziano >>> > Sent: Thursday, September 29, 2011 2:52 PM >>> > >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > Kick yerself in the pants or not. Make sure your QUALITY is good. >>> > Look at your quality graphs and make sure you don't have latency. >>> > If it was easy, everybody would be doing it. >>> > On Thu, Sep 29, 2011 at 2:50 PM, Max DiOrio <[email protected]> >>> > wrote: >>> > The thing that is kicking me in the pants is, should all this be >>> > necessary for 10 phones on a dedicated VoIP only 9 x 1.5 >>> > connection? The only data traffic on this ISP is administration >>> > websites. >>> > >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Tony Graziano >>> > Sent: Thursday, September 29, 2011 2:42 PM >>> > >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > Let's not confuse qos with shaping. In the meantime I've emailed >>> > you my beta version of the pfsense shaper wizard for sipxecs using >>> > pfsense 2.0. I'd backup your config, and the files you are >>> > replacing in the event you want to revert it. I'm running it without >>> > issues. >>> > >>> > If the ITSP is not your ISP the qos is probably lost on them. If >>> > not, it's a "switch" function which means a procurve/cisco/juniper >>> > or something a little more smartie pants'ish is in your near future. >>> > >>> > Re-run the shaper with the same bandwdith and type and see if it >>> > properly shapes bot call directions. This one is particular to your >>> > provider, as it markes UDP 49152-53000 and 30000-31000 instead of >>> > only 10000-20000 and 30000-31000 udp. >>> > >>> > It should ignore the IP and also use just 5060/tcp/udp and 5080udp >>> > along with the ports above to queue the bandwidth according to the >>> > best available. >>> > On Thu, Sep 29, 2011 at 2:33 PM, Josh Patten <[email protected]> wrote: >>> > Life would be much easier if you set your QoS precedence (priority) >>> > to 5. Read on for why >>> > >>> > 5 in binary is 101 >>> > 6 in binary is 110 >>> > 7 in binary is 111 >>> > DSCP 46, which is what all RTP traffic normally uses and what most >>> > routers/switches/gateways/phones are set to use by default to tag/ >>> > prioritize RTP traffic, in binary is 101 110 (notice how I put a >>> space there) >>> > >>> > The first three bits are the precedence field which can be 0-7 (000 >>> > to 111). Only 0-5 should be used for user traffic. 6 and 7 are >>> > reserved for internetwork control and network control, respectively. >>> > The remaining 3 bits are, in order, delay (0=normal, 1=low), >>> > throughput (0=normal, 1=high), and reliability (0=normal, 1=high) >>> > - >>> > -So for DSCP 46 you have a precedence value of 5 (101), low delay >>> > (1), high throughput (1), and normal reliability (0). Put all this >>> > together and you have 101110 binary which is equal to 46 decimal. >>> > >>> > Also, if you are using sipXbridge then the VoIP traffic that is >>> > reaching it is not being tagged. This needs to be done at the >>> > switch level it possible. >>> > >>> > Try getting all your voice stuff back to precedence level 5 and >>> > setting your QoS stuff for VoIP to precedence level 5. >>> > >>> > On Thu, Sep 29, 2011 at 1:09 PM, Max DiOrio <[email protected]> >>> > wrote: >>> > pfSense is set with floating rules, defining any UDP traffic >>> > destined for my sip trunks gets put into the qVoIP. Also any UDP >>> > traffic from my VoIP server to any destination gets put into the qVoIP. >>> > >>> > Wouldn't this be enough to pull all RTP packets into the qVoIP >>> > priority queue and therefore be set to a priority of 7 in this >>> > case. and >>> > >>> > >>> > I'm wondering if we're running into problems with the way the >>> > bandwidth and SC is configured on the qVoIP queues. Shouldn't the >>> > bandwidth be set to 86Kbits/s and an RealTime SC m2 of 860Kb? >>> > >>> > WAN HFSC Bandwidth 1572 Kbit/s >>> > WAN qACK Priority 6, Bandwidth 19.602%, Link Share SC m2 of 19.602% >>> > WAN qDefault has priority 3, Bandwidth 9.801% WAN qVoIP priority 7, >>> > bandwidth of 32Kbits/s, with Real time SC and an m2 of 240Kb. >>> > >>> > LAN HFSC >>> > LAN qLink priority 2, queue limit 500, Bandwidth 20% LAN qInternet, >>> > Priority 1, Bandwidth 9Mbit/s, Upperlimit SC m2 of 9Mb, LinkShare >>> > SC m2 of 9Mb LAN qInternet qACK priority 6, Bandwidth 19.48%, >>> > Linkshare SC m2 of 19.48% LAN qInternet qVOIP priority 7, bandwidth >>> > of 32Kbits/s, with Real time SC and an m2 of 240Kb >>> > >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Max DiOrio >>> > Sent: Thursday, September 29, 2011 1:35 PM >>> > >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > Using Polycom 550's with their default QoS settings. >>> > >>> > We are using sipXbridge for our ITSP connection. >>> > >>> > How do you recommend I set up QoS for sipXbridge? >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Michael Picher >>> > Sent: Thursday, September 29, 2011 12:36 PM >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > Right but the point here is that the sipXecs server does not flag >>> > its traffic for QoS (dscp or cos). Most people don't realize this. >>> > >>> > Also, if you use sipXbridge it's on the sipXecs server. >>> > >>> > Mike >>> > On Thu, Sep 29, 2011 at 12:00 PM, Max DiOrio >>> > <[email protected]> >>> > wrote: >>> > All VoIP traffic is showing up in the correct qVoIP queue in both >>> directions. >>> > >>> > pfSense support set up floating rules to match traffic based on IP >>> > address. >>> > >>> > I don't have access to the switch right now, I'm working on that, >>> > but it's just a typical DLink smart switch, which I believe passes >>> > QoS through. >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Tony Graziano >>> > Sent: Thursday, September 29, 2011 11:32 AM >>> > >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > >>> > On Thu, Sep 29, 2011 at 11:13 AM, Max DiOrio >>> > <[email protected]> >>> > wrote: >>> > Tony, >>> > >>> > Here's a response from my ITSP: >>> > >>> > "Hm, that's odd. If there's no other traffic and the DSL circuit is >>> > clean then you shouldn't have any packet loss. Why do you have such >>> > a large circuit if you're only doing voice? >>> > >>> > They didn't really say that did they? Give me a break. How many >>> > calls simultaneous *85'ish k sets your needed bandwidth. >>> > >>> > >>> > Sounds like there's something else going on. A packet capture would >>> > be helpful, and at least tell us if you're receiving all the >>> > packets or not. Sometimes packet loss can be the result of late >>> > arrivals to the jitter buffer - what's the jitter buffer set to? >>> > Normally defaults are at 50ms. >>> > >>> > Regardless, we're coming from 64.246.135.202, SIP is on UDP 5080, >>> > and RTP is on UDP ports 49152 - 53000." >>> > >>> > >>> > OK, so we need to add ports 49152-53000 to this for them. I'll whip >>> > you up a set set of files and send them to you. >>> > >>> > Let me know what your pfSense 2.0 wizard is now. >>> > >>> > Jitter buffer in sipXecs for 711u is 40ms isn't it? Would 10ms >>> > added to the jitter buffer help? >>> > >>> > My users are having problems today actually. And this time, the >>> > people outside are the ones hearing the choppy audio. My users say >>> > what they hear is fine. >>> > >>> > I'm working with pfSense on an issue with the QoS queues that >>> > appear to be broken. If I'm using the pfSense administration page >>> > and transmitting HTTP data like refreshing the RRD page, while on a >>> > call, the call audio gets choppy. The HTTP data is going through >>> > the default Queue however, so I'm not sure why my VoIP queue >>> > priority isn't taking over. >>> > >>> > It most likely because the calls are not recognized in the status/ >>> > queues. You should see voice calls shaped in both directions in in >>> > in/out queue when someone is talking. >>> > >>> > >>> > Now this isn't a huge deal as I'm almost never in the admin pages >>> > of pfSense or sipXecs, but if the queue isn't working for this, >>> > maybe it's not working under load. I am seeing a lot of queue >>> > drops in VoIP queue on occasion though. Love the RRD graphs. >>> > >>> > >>> > Drops make me think there is a quality isssue/latency. Look at the >>> > wan interface in question and look at the quality graph. Is ou >>> > switch set for qos internally? >>> > >>> > Thanks! >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Max DiOrio >>> > Sent: Friday, September 23, 2011 1:38 PM >>> > >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > That makes sense. I'll find out what the ports they use are and >>> > get back to you. >>> > >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Tony Graziano >>> > Sent: Friday, September 23, 2011 1:15 PM >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > OK. I updated MY scripts for 1.2.3, 2.0 is "very different" too. >>> > What I found is that I need to also specifiy the media ports the >>> > ITSP uses when they send me calls. >>> > >>> > So while I shape ports 5060, 5080, 30000-31000, I am not >>> > necessarily applying anything to calls I receive from the ITSP if >>> > they specify duifferent ports (which they will). >>> > >>> > So find out what media ports they specify and I can help you get >>> > the new wizard working. As an example, maybe your outbound calls >>> > are fine, but you might be having more quality issues with calls >>> > from the itsp to you... >>> > On Fri, Sep 23, 2011 at 11:59 AM, Max DiOrio >>> > <[email protected]> >>> > wrote: >>> > CornerStone Telephone. They're a decent sized local carrier. They >>> > cover all of New York State, Western Mass, and Northern PA. >>> > >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Tony Graziano >>> > Sent: Friday, September 23, 2011 11:28 AM >>> > >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > who is the itsp? >>> > On Fri, Sep 23, 2011 at 11:18 AM, Max DiOrio >>> > <[email protected]> >>> > wrote: >>> > Yes, it is a 2.0 install. pfSense said that it can't be the QoS >>> > causing the problems as it doesn't show any dropped packets for the >>> > queues, so I'm not overflowing them. >>> > >>> > I have UDP 30000-31000, UDP 5080, TCP/UDP 5060 NAT'd to the sipX >>> > server. I believe I followed your wizard when I set this up back >>> > in August. Have you updated it at all? >>> > >>> > With choppy audio and dropped calls I'm not sure how it would be a >>> > port problem. I would think port problems would manifest >>> > themselves as no audio/no connection issues. >>> > >>> > [image removed] >>> > >>> > From: [email protected] [mailto:sipx-users- >>> > [email protected]] On Behalf Of Tony Graziano >>> > Sent: Friday, September 23, 2011 11:05 AM >>> > To: Discussion list for users of sipXecs software >>> > Subject: Re: [sipx-users] pfSense QoS >>> > >>> > pfsense does floating rules but my guess is not all of the ports >>> > are properly specified. Is this a 2.0 install? If so, you might >>> > want my new wizard for setting that up. >>> > On Fri, Sep 23, 2011 at 10:57 AM, Max DiOrio >>> > <[email protected]> >>> > wrote: >>> > I was hoping someone can take a quick look at my QoS settings and >>> > let me know if anything is off. My users are complaining that >>> > they're having choppy audio and an occasional dropped call. Our >>> > ITSP/ISP says everything is fine on their end. The QoS settings >>> > were tweaked by pfSense. We have a DSL connection that's supposed >>> to be 9/1.5 >>> > >>> > I'm just trying to figure out a way to pin the troubles back on >>> the ITSP/ISP. >>> > >>> > <shaper> >>> > <queue> >>> > <interface>lan</interface> >>> > <name>lan</name> >>> > <scheduler>HFSC</scheduler> >>> > <bandwidth/> >>> > <bandwidthtype/> >>> > <enabled>on</enabled> >>> > <queue> >>> > <name>qLink</name> >>> > <interface>lan</interface> >>> > <qlimit>500</qlimit> >>> > <priority>2</priority> >>> > <bandwidth>20</bandwidth> >>> > <bandwidthtype>%</bandwidthtype> >>> > <enabled>on</enabled> >>> > <default>on</default> >>> > <ecn>on</ecn> >>> > </queue> >>> > <queue> >>> > <name>qInternet</name> >>> > <interface>lan</interface> >>> > <bandwidth>9</bandwidth> >>> > <bandwidthtype>Mb</bandwidthtype> >>> > <enabled>on</enabled> >>> > <ecn>on</ecn> >>> > <linkshare3>9Mb</linkshare3> >>> > <linkshare>on</linkshare> >>> > <upperlimit3>9Mb</upperlimit3> >>> > <upperlimit>on</upperlimit> >>> > <queue> >>> > <name>qACK</name> >>> > <interface>lan</interface> >>> > <priority>6</priority> >>> > <bandwidth>19.48</bandwidth> >>> > <bandwidthtype>%</bandwidthtype> >>> > <enabled>on</enabled> >>> > <ecn>on</ecn> >>> > <linkshare3>19.48%</linkshare3> >>> > <linkshare>on</linkshare> >>> > </queue> >>> > <queue> >>> > <name>qVoIP</name> >>> > <interface>lan</interface> >>> > <priority>7</priority> >>> > <bandwidth>32</bandwidth> >>> > <bandwidthtype>Kb</bandwidthtype> >>> > <enabled>on</enabled> >>> > <ecn>on</ecn> >>> > <realtime3>240Kb</realtime3> >>> > <realtime>on</realtime> >>> > </queue> >>> > </queue> >>> > </queue> >>> > <queue> >>> > <interface>wan</interface> >>> > <name>wan</name> >>> > <scheduler>HFSC</scheduler> >>> > <bandwidth>1572</bandwidth> >>> > <bandwidthtype>Kb</bandwidthtype> >>> > <enabled>on</enabled> >>> > <queue> >>> > <name>qACK</name> >>> > <interface>wan</interface> >>> > <priority>6</priority> >>> > <bandwidth>19.602</bandwidth> >>> > <bandwidthtype>%</bandwidthtype> >>> > <enabled>on</enabled> >>> > <ecn>on</ecn> >>> > <linkshare3>19.602%</linkshare3> >>> > <linkshare>on</linkshare> >>> > </queue> >>> > <queue> >>> > <name>qDefault</name> >>> > <interface>wan</interface> >>> > <priority>3</priority> >>> > <bandwidth>9.801</bandwidth> >>> > <bandwidthtype>%</bandwidthtype> >>> > <enabled>on</enabled> >>> > <default>on</default> >>> > <ecn>on</ecn> >>> > </queue> >>> > <queue> >>> > <name>qVoIP</name> >>> > <interface>wan</interface> >>> > <priority>7</priority> >>> > <bandwidth>32</bandwidth> >>> > <bandwidthtype>Kb</bandwidthtype> >>> > <enabled>on</enabled> >>> > <ecn>on</ecn> >>> > <realtime3>240Kb</realtime3> >>> > <realtime>on</realtime> >>> > </queue> >>> > </queue> >>> > </shaper> >>> > >>> > >>> > [image removed] >>> > >>> > >>> > _______________________________________________ >>> > 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.465.6833 >>> > >>> > Email: [email protected] >>> > >>> > LAN/Telephony/Security and Control Systems Helpdesk: >>> > Telephone: 434.984.8426 >>> > sip: [email protected] >>> > >>> > Helpdesk Contract Customers: >>> > http://support.myitdepartment.net >>> > >>> > Blog: >>> > http://blog.myitdepartment.net >>> > >>> > Linked-In Profile: >>> > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> > >>> > Ask about our Internet faxservices! >>> > >>> > >>> > _______________________________________________ >>> > 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.465.6833 >>> > >>> > Email: [email protected] >>> > >>> > LAN/Telephony/Security and Control Systems Helpdesk: >>> > Telephone: 434.984.8426 >>> > sip: [email protected] >>> > >>> > Helpdesk Contract Customers: >>> > http://support.myitdepartment.net >>> > >>> > Blog: >>> > http://blog.myitdepartment.net >>> > >>> > Linked-In Profile: >>> > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> > >>> > Ask about our Internet faxservices! >>> > >>> > >>> > _______________________________________________ >>> > 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.465.6833 >>> > >>> > Email: [email protected] >>> > >>> > LAN/Telephony/Security and Control Systems Helpdesk: >>> > Telephone: 434.984.8426 >>> > sip: [email protected] >>> > >>> > Helpdesk Contract Customers: >>> > http://support.myitdepartment.net >>> > >>> > Blog: >>> > http://blog.myitdepartment.net >>> > >>> > Linked-In Profile: >>> > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> > >>> > Ask about our Internet faxservices! >>> > >>> > >>> > _______________________________________________ >>> > 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.465.6833 >>> > >>> > Email: [email protected] >>> > >>> > LAN/Telephony/Security and Control Systems Helpdesk: >>> > Telephone: 434.984.8426 >>> > sip: [email protected] >>> > >>> > Helpdesk Contract Customers: >>> > http://support.myitdepartment.net >>> > >>> > Blog: >>> > http://blog.myitdepartment.net >>> > >>> > Linked-In Profile: >>> > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> > >>> > Ask about our Internet Fax services! >>> > >>> > >>> > _______________________________________________ >>> > sipx-users mailing list >>> > [email protected] >>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> > >>> >>> > >>> > -- >>> > Michael Picher >>> > eZuce >>> > Director of Technical Services >>> > O.978-296-1005 X2015 >>> > M.207-956-0262 >>> > @mpicher <http://twitter.com/mpicher> www.ezuce.com >>> > >>> > _______________________________________________ >>> > sipx-users mailing list >>> > [email protected] >>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> > >>> > >>> > >>> > -- >>> > Josh Patten >>> > eZuce >>> > Solutions Architect >>> > O.978-296-1005 X2050 >>> > M.979-574-5699 >>> > >>> > _______________________________________________ >>> > 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.465.6833 >>> > >>> > Email: [email protected] >>> > >>> > LAN/Telephony/Security and Control Systems Helpdesk: >>> > Telephone: 434.984.8426 >>> > sip: [email protected] >>> > >>> > Helpdesk Contract Customers: >>> > http://support.myitdepartment.net >>> > >>> > Blog: >>> > http://blog.myitdepartment.net >>> > >>> > Linked-In Profile: >>> > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> > >>> > Ask about our Internet Fax services! >>> > >>> > >>> > _______________________________________________ >>> > 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.465.6833 >>> > >>> > Email: [email protected] >>> > >>> > LAN/Telephony/Security and Control Systems Helpdesk: >>> > Telephone: 434.984.8426 >>> > sip: [email protected] >>> > >>> > Helpdesk Contract Customers: >>> > http://support.myitdepartment.net >>> > >>> > Blog: >>> > http://blog.myitdepartment.net >>> > >>> > Linked-In Profile: >>> > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> > >>> > Ask about our Internet Fax services! >>> > >>> > >>> > _______________________________________________ >>> > 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.465.6833 >>> > >>> > Email: [email protected] >>> > >>> > LAN/Telephony/Security and Control Systems Helpdesk: >>> > Telephone: 434.984.8426 >>> > sip: [email protected] >>> > >>> > Helpdesk Contract Customers: >>> > http://support.myitdepartment.net >>> > >>> > Blog: >>> > http://blog.myitdepartment.net >>> > >>> > Linked-In Profile: >>> > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> > >>> > Ask about our Internet Fax services! >>> > _______________________________________________ >>> > sipx-users mailing list >>> > [email protected] >>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> [attachment "Max DiOrio.vcf" deleted by Paul Scheepens/EPO] >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: >> 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.465.6833 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > > Helpdesk Contract Customers: > http://support.myitdepartment.net > Blog: > http://blog.myitdepartment.net > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > Ask about our Internet Fax services! > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > CONFIDENTIALITY NOTICE: > > The information contained in this message may be privileged and confidential. > If you are NOT the intended recipient, please notify the sender immediately > with a copy to [email protected] and destroy this message. Please be > aware that email communication can be intercepted in transmission or > misdirected. Your use of email to communicate protected health information > to us indicates that you acknowledge and accept the possible risks associated > with such communication. Please consider communicating any sensitive > information by telephone, fax or mail. If you do not wish to have your > information sent by email, please contact the sender immediately. > > _______________________________________________ > 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.465.6833 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
