<div dir="ltr">You can get Polycom phones VVX 101/201 probably for less than the labor hours you will lose on support, not to mention the marketing on that opportunity. I'm sure management would highly consider it.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br><br><br><br>Aryn H. K. Nakaoka<br><a href="mailto:anakaoka@trinet-hi.com" target="_blank">anakaoka@trinet-hi.com</a></div><div><br>Direct: 808.356.2901<br>Fax : 808.356.2919<br></div><div><br>Tri-net Solutions<br>733 Bishop St. #1170<br>Honolulu, HI 96813<br><a href="http://www.trinet-hi.com" target="_blank">http://www.trinet-hi.com</a></div><div><br></div><div><a href="https://twitter.com/AlohaTone" target="_blank">https://twitter.com/AlohaTone<br></a></div><div><br><div><a href="https://www.youtube.com/watch?v=96YWPY9wCeU" target="_blank">Aloha Tone PBX </a> <a href="http://youtu.be/27v2wbnFIDs" target="_blank">https://www.youtube.com/watch?v=96YWPY9wCeU</a><br><br></div><div><a href="http://youtu.be/rJsr4k0RBH8" target="_blank">Aloha Tone (HA) High Availability</a> <a href="http://youtu.be/rJsr4k0RBH8" target="_blank">http://youtu.be/rJsr4k0RBH8</a><br></div><br><div>CONFIDENTIALITY NOTICE:  The information contained in this email and any attachments may be privileged, confidential and protected from disclosure.  Any disclosure, distribution or copying of this email or any attachments by persons or entities other than the intended recipient is prohibited. If you have received this email in error, please notify the sender immediately by replying to the message and deleting this email and any attachments from your system. Thank you for your cooperation.<br><br></div><div><br></div><div><br><br></div><div><br><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Oct 6, 2015 at 5:03 PM, Peter E <span dir="ltr"><<a href="mailto:peeip989@gmail.com" target="_blank">peeip989@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>You're preaching to the choir, Mark. As a company, for BYOD, we take a stance of, we'll supply the SIP credentials but we won't support the device. But anyone in an operations role knows what that really means -- do whatever it takes to get them working and happy. </div><div><br></div><div>I'll share your comments with those that believe the opposite about BYOD and scale. It will make for an interesting debate.</div><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br></div><div><br>On Oct 6, 2015, at 22:52, Mark Lindsey <<a href="mailto:lindsey@e-c-group.com" target="_blank">lindsey@e-c-group.com</a>> wrote:<br><br></div><div><div>1. In Hosted PBX, accommodating new, non-productized devices that the customer just has to keep is the price you pay to enjoy slow growth (because the engineering effort for the customer is immense), poor reliability (because you can test much less), and an unsupportable customer deployments (because the support team isn't equipped to support this "product"). </div><div><br></div><div>2. In Hosted PBX, the demarc is the audible voice on the speaker and the input to the microphone. Supporting random devices the customer brings you makes it impossible for you to fulfill your end of the bargain: make this voice stuff work every time for every call. </div><div><br></div><div>3. The best thing to do with a customer's old device is trade in credit then liquidate.</div><div><br></div><div>4. Cisco 79xx SIP has gone back and forth on symmetric sip signaling over the past few decades. But generally, when nat is involved, the sip phone has to do symmetric sip ports -- I.e., it must use the same port numbers for both sending sip and receiving sip. (And when carrier SBCs are involved, it needs to use the same port number for all sip transactions, not just those related to direct call control).</div><div><br></div><div>But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip. <br><br><a href="mailto:mark@ecg.co" target="_blank">mailto:mark@ecg.co</a> <div><a href="tel:+1-229-316-0013" target="_blank">tel:+1-229-316-0013</a> <a href="http://ecg.co/lindsey" target="_blank">http://ecg.co/lindsey</a></div></div><div><br>On Oct 6, 2015, at 17:10, Pete E <<a href="mailto:peeip989@gmail.com" target="_blank">peeip989@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Greetings Voice Operators,<div><br></div><div><br></div><div>We have an interesting (code word for annoying) challenge that we've never dealt with before, probably because we don't do much with Cisco phones. We have a new customer coming on who wants to keep their very old Cisco 7941 phones. They have a few offices and the phones work as expected behind an Edgemarc. However, they also have 100+ home users, and that's where the issue comes in.</div><div><br></div><div>Apparently Cisco introduced a security "feature" where they create the session using a random high numbered port (e.g. 49123) but in the Via header, they say to respond to <b>private IP, port 5060</b>. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to <b>public IP, port 49123</b>. What we're seeing is that the home router passes the response back to <b>private IP, port 49123</b>, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails.</div><div><br></div><div>As you know most home routers are poor at handling ALG (and we've tested and found they are equally bad at handling this scenario). We (and the customer) don't want to troubleshoot 100+ individual home routers. </div><div><br></div><div>We haven't found a way to turn off this really awesome "feature" so we're trying to find other solutions. Anyone been through this and have any suggestions?</div><div><br></div><div><br></div><div>Thanks,</div><div>Pete</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>VoiceOps mailing list</span><br><span><a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a></span><br><span><a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a></span><br></div></blockquote>
</div></div></div></div><br>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br></blockquote></div><br></div>