I'm talking about their actually paid support technicians.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Friday, September 30, 2011 12:28 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] pfSense QoS 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/ 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.
<<attachment: Max DiOrio.vcf>>
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
