Greetings Voice Operators, 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. 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 *private IP, port 5060*. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to *public IP, port 49123*. What we're seeing is that the home router passes the response back to *private IP, port 49123*, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails. 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. 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? Thanks, Pete
Two things I would try 1. Point the phone to alternate port (5090) . You will need a realm configured on the HNT SBC to accept 5090 2. Downgrade the phone firmware Kumudu Suriyaarachchi ksuriyaarachchi at alteva.com<mailto:ksuriyaarachchi at alteva.com> P 484.534.4427 [Alteva-Logo-horizontal] From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Pete E Sent: Tuesday, October 06, 2015 5:10 PM To: voiceops at voiceops.org Subject: [VoiceOps] Cisco 7941 SIP Greetings Voice Operators, 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. 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 private IP, port 5060. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to public IP, port 49123. What we're seeing is that the home router passes the response back to private IP, port 49123, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails. 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. 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? Thanks, Pete This communication (including any attachments) may contain privileged or confidential information of Alteva and is intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, you should notify the author and delete this communication from your system, including any attachments. Any disclosure, copying, saving or distribution of this communication, or the taking of any action based on it, is strictly prohibited. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Alteva.
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"). 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. 3. The best thing to do with a customer's old device is trade in credit then liquidate. 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). But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip. mailto:mark at ecg.co <mark at ecg.co> tel:+1-229-316-0013 <+1-229-316-0013> http://ecg.co/lindsey On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com> wrote: Greetings Voice Operators, 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. 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 *private IP, port 5060*. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to *public IP, port 49123*. What we're seeing is that the home router passes the response back to *private IP, port 49123*, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails. 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. 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? Thanks, Pete _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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. I'll share your comments with those that believe the opposite about BYOD and scale. It will make for an interesting debate. On Oct 6, 2015, at 22:52, Mark Lindsey <lindsey at e-c-group.com> wrote: 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"). 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. 3. The best thing to do with a customer's old device is trade in credit then liquidate. 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). But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip. mailto:mark at ecg.co tel:+1-229-316-0013 http://ecg.co/lindsey
On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com> wrote:
Greetings Voice Operators,
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.
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 private IP, port 5060. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to public IP, port 49123. What we're seeing is that the home router passes the response back to private IP, port 49123, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails.
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.
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?
Thanks, Pete _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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. Aryn H. K. Nakaoka anakaoka at trinet-hi.com Direct: 808.356.2901 Fax : 808.356.2919 Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com https://twitter.com/AlohaTone Aloha Tone PBX <https://www.youtube.com/watch?v=96YWPY9wCeU> https://www.youtube.com/watch?v=96YWPY9wCeU <http://youtu.be/27v2wbnFIDs> Aloha Tone (HA) High Availability <http://youtu.be/rJsr4k0RBH8> http://youtu.be/rJsr4k0RBH8 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. On Tue, Oct 6, 2015 at 5:03 PM, Peter E <peeip989 at gmail.com> wrote:
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.
I'll share your comments with those that believe the opposite about BYOD and scale. It will make for an interesting debate.
On Oct 6, 2015, at 22:52, Mark Lindsey <lindsey at e-c-group.com> wrote:
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").
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.
3. The best thing to do with a customer's old device is trade in credit then liquidate.
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).
But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip.
mailto:mark at ecg.co <mark at ecg.co> tel:+1-229-316-0013 <+1-229-316-0013> http://ecg.co/lindsey
On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com> wrote:
Greetings Voice Operators,
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.
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 *private IP, port 5060*. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to *public IP, port 49123*. What we're seeing is that the home router passes the response back to *private IP, port 49123*, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails.
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.
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?
Thanks, Pete
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Maybe Polycom will give you a discount for replacing a Cisco. Aryn H. K. Nakaoka anakaoka at trinet-hi.com Direct: 808.356.2901 Fax : 808.356.2919 Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com https://twitter.com/AlohaTone Aloha Tone PBX <https://www.youtube.com/watch?v=96YWPY9wCeU> https://www.youtube.com/watch?v=96YWPY9wCeU <http://youtu.be/27v2wbnFIDs> Aloha Tone (HA) High Availability <http://youtu.be/rJsr4k0RBH8> http://youtu.be/rJsr4k0RBH8 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. On Wed, Oct 7, 2015 at 6:11 AM, Aryn Nakaoka 808.356.2901 < anakaoka at trinet-hi.com> wrote:
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.
Aryn H. K. Nakaoka anakaoka at trinet-hi.com
Direct: 808.356.2901 Fax : 808.356.2919
Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com
Aloha Tone PBX <https://www.youtube.com/watch?v=96YWPY9wCeU> https://www.youtube.com/watch?v=96YWPY9wCeU <http://youtu.be/27v2wbnFIDs>
Aloha Tone (HA) High Availability <http://youtu.be/rJsr4k0RBH8> http://youtu.be/rJsr4k0RBH8
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.
On Tue, Oct 6, 2015 at 5:03 PM, Peter E <peeip989 at gmail.com> wrote:
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.
I'll share your comments with those that believe the opposite about BYOD and scale. It will make for an interesting debate.
On Oct 6, 2015, at 22:52, Mark Lindsey <lindsey at e-c-group.com> wrote:
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").
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.
3. The best thing to do with a customer's old device is trade in credit then liquidate.
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).
But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip.
mailto:mark at ecg.co <mark at ecg.co> tel:+1-229-316-0013 <+1-229-316-0013> http://ecg.co/lindsey
On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com> wrote:
Greetings Voice Operators,
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.
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 *private IP, port 5060*. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to *public IP, port 49123*. What we're seeing is that the home router passes the response back to *private IP, port 49123*, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails.
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.
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?
Thanks, Pete
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
They used to. I think that program has ended. On Wed, Oct 7, 2015 at 9:12 AM, Aryn Nakaoka 808.356.2901 < anakaoka at trinet-hi.com> wrote:
Maybe Polycom will give you a discount for replacing a Cisco.
Aryn H. K. Nakaoka anakaoka at trinet-hi.com
Direct: 808.356.2901 Fax : 808.356.2919
Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com
Aloha Tone PBX <https://www.youtube.com/watch?v=96YWPY9wCeU> https://www.youtube.com/watch?v=96YWPY9wCeU <http://youtu.be/27v2wbnFIDs>
Aloha Tone (HA) High Availability <http://youtu.be/rJsr4k0RBH8> http://youtu.be/rJsr4k0RBH8
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.
On Wed, Oct 7, 2015 at 6:11 AM, Aryn Nakaoka 808.356.2901 < anakaoka at trinet-hi.com> wrote:
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.
Aryn H. K. Nakaoka anakaoka at trinet-hi.com
Direct: 808.356.2901 Fax : 808.356.2919
Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com
Aloha Tone PBX <https://www.youtube.com/watch?v=96YWPY9wCeU> https://www.youtube.com/watch?v=96YWPY9wCeU <http://youtu.be/27v2wbnFIDs>
Aloha Tone (HA) High Availability <http://youtu.be/rJsr4k0RBH8> http://youtu.be/rJsr4k0RBH8
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.
On Tue, Oct 6, 2015 at 5:03 PM, Peter E <peeip989 at gmail.com> wrote:
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.
I'll share your comments with those that believe the opposite about BYOD and scale. It will make for an interesting debate.
On Oct 6, 2015, at 22:52, Mark Lindsey <lindsey at e-c-group.com> wrote:
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").
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.
3. The best thing to do with a customer's old device is trade in credit then liquidate.
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).
But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip.
mailto:mark at ecg.co <mark at ecg.co> tel:+1-229-316-0013 <+1-229-316-0013> http://ecg.co/lindsey
On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com> wrote:
Greetings Voice Operators,
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.
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 *private IP, port 5060*. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to *public IP, port 49123*. What we're seeing is that the home router passes the response back to *private IP, port 49123*, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails.
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.
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?
Thanks, Pete
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Wayne Wenthin Wide Area Network Administrator Cascade Technology Alliance (CTA North - Multnomah ESD) Ph: 503.257.1562 wayne.wenthin at cascadetech.org www.cascadetech.org
The ?Tradeup2Polycom? landing page is returning a page not found error so you may be right. There are however third party companies that will still buy the 79X1 phones for refurb and parts so you could still do the trade-in as a two-step process. [cid:image006.png at 01D101A5.74DCE400]<http://www.force3.com/> Rob Dawson Solutions Architect 2151 Priest Bridge Dr. Crofton, MD 21114 O 410-774-7153 M 571-234-2621 Check out our upcoming Events<http://www.force3.com/category/events/> ! [Facebook]<https://www.facebook.com/force3inc>[Twitter]<https://twitter.com/force3>[LinkedIn]<http://www.linkedin.com/company/force-3> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Wayne Wenthin Sent: Wednesday, October 07, 2015 12:20 PM To: Aryn Nakaoka 808.356.2901 Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Cisco 7941 SIP They used to. I think that program has ended. On Wed, Oct 7, 2015 at 9:12 AM, Aryn Nakaoka 808.356.2901 <anakaoka at trinet-hi.com<mailto:anakaoka at trinet-hi.com>> wrote: Maybe Polycom will give you a discount for replacing a Cisco. Aryn H. K. Nakaoka anakaoka at trinet-hi.com<mailto:anakaoka at trinet-hi.com> Direct: 808.356.2901<tel:808.356.2901> Fax : 808.356.2919<tel:808.356.2919> Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com https://twitter.com/AlohaTone Aloha Tone PBX <https://www.youtube.com/watch?v=96YWPY9wCeU> https://www.youtube.com/watch?v=96YWPY9wCeU<http://youtu.be/27v2wbnFIDs> Aloha Tone (HA) High Availability<http://youtu.be/rJsr4k0RBH8> http://youtu.be/rJsr4k0RBH8 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. On Wed, Oct 7, 2015 at 6:11 AM, Aryn Nakaoka 808.356.2901<tel:808.356.2901> <anakaoka at trinet-hi.com<mailto:anakaoka at trinet-hi.com>> wrote: 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. Aryn H. K. Nakaoka anakaoka at trinet-hi.com<mailto:anakaoka at trinet-hi.com> Direct: 808.356.2901<tel:808.356.2901> Fax : 808.356.2919<tel:808.356.2919> Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com https://twitter.com/AlohaTone Aloha Tone PBX <https://www.youtube.com/watch?v=96YWPY9wCeU> https://www.youtube.com/watch?v=96YWPY9wCeU<http://youtu.be/27v2wbnFIDs> Aloha Tone (HA) High Availability<http://youtu.be/rJsr4k0RBH8> http://youtu.be/rJsr4k0RBH8 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. On Tue, Oct 6, 2015 at 5:03 PM, Peter E <peeip989 at gmail.com<mailto:peeip989 at gmail.com>> wrote: 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. I'll share your comments with those that believe the opposite about BYOD and scale. It will make for an interesting debate. On Oct 6, 2015, at 22:52, Mark Lindsey <lindsey at e-c-group.com<mailto:lindsey at e-c-group.com>> wrote: 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"). 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. 3. The best thing to do with a customer's old device is trade in credit then liquidate. 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). But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip. mailto:mark at ecg.co tel:+1-229-316-0013 http://ecg.co/lindsey On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com<mailto:peeip989 at gmail.com>> wrote: Greetings Voice Operators, 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. 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 private IP, port 5060. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to public IP, port 49123. What we're seeing is that the home router passes the response back to private IP, port 49123, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails. 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. 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? Thanks, Pete _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops -- Wayne Wenthin Wide Area Network Administrator Cascade Technology Alliance (CTA North - Multnomah ESD) Ph: 503.257.1562 wayne.wenthin at cascadetech.org<mailto:wayne.wenthin at cascadetech.org> www.cascadetech.org<http://www.cascadetech.org/>
I think it's still good. Just a name change. https://www.dropbox.com/s/8gz0gfifpsjlc0d/polycom%20rebate%20program%20-%20g... Thanks, Shripal
On Oct 8, 2015, at 8:43 AM, Rob Dawson <rdawson at force3.com> wrote:
The ?Tradeup2Polycom? landing page is returning a page not found error so you may be right. There are however third party companies that will still buy the 79X1 phones for refurb and parts so you could still do the trade-in as a two-step process.
<image006.png>
Rob Dawson Solutions Architect 2151 Priest Bridge Dr. Crofton, MD 21114
O 410-774-7153 M 571-234-2621 Check out our upcoming Events ! <image003.png><image004.png>
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Wayne Wenthin Sent: Wednesday, October 07, 2015 12:20 PM To: Aryn Nakaoka 808.356.2901 Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Cisco 7941 SIP
They used to. I think that program has ended.
On Wed, Oct 7, 2015 at 9:12 AM, Aryn Nakaoka 808.356.2901 <anakaoka at trinet-hi.com> wrote: Maybe Polycom will give you a discount for replacing a Cisco.
Aryn H. K. Nakaoka anakaoka at trinet-hi.com
Direct: 808.356.2901 Fax : 808.356.2919
Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com
Aloha Tone PBX https://www.youtube.com/watch?v=96YWPY9wCeU
Aloha Tone (HA) High Availability http://youtu.be/rJsr4k0RBH8
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.
On Wed, Oct 7, 2015 at 6:11 AM, Aryn Nakaoka 808.356.2901 <anakaoka at trinet-hi.com> wrote: 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.
Aryn H. K. Nakaoka anakaoka at trinet-hi.com
Direct: 808.356.2901 Fax : 808.356.2919
Tri-net Solutions 733 Bishop St. #1170 Honolulu, HI 96813 http://www.trinet-hi.com
Aloha Tone PBX https://www.youtube.com/watch?v=96YWPY9wCeU
Aloha Tone (HA) High Availability http://youtu.be/rJsr4k0RBH8
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.
On Tue, Oct 6, 2015 at 5:03 PM, Peter E <peeip989 at gmail.com> wrote: 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.
I'll share your comments with those that believe the opposite about BYOD and scale. It will make for an interesting debate.
On Oct 6, 2015, at 22:52, Mark Lindsey <lindsey at e-c-group.com> wrote:
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").
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.
3. The best thing to do with a customer's old device is trade in credit then liquidate.
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).
But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip.
mailto:mark at ecg.co tel:+1-229-316-0013 http://ecg.co/lindsey
On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com> wrote:
Greetings Voice Operators,
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.
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 private IP, port 5060. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to public IP, port 49123. What we're seeing is that the home router passes the response back to private IP, port 49123, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails.
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.
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?
Thanks, Pete _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Wayne Wenthin Wide Area Network Administrator Cascade Technology Alliance (CTA North - Multnomah ESD) Ph: 503.257.1562 wayne.wenthin at cascadetech.org www.cascadetech.org _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Important thing to bear in mind is that the Cisco best practice for remote endpoints was and still is to use VPN Phone via AnyConnect licensing, or in the newer endpoints via the Collaboration Edge architecture and Expressway. The phone determines if it can communicate directly to CUCM and if not it tries to establish an SSLVPN connection back to an ASA located at the provider edge, or in newer endpoints (8800 series for example) it establishes a session with Expressway just like a mobile device or tablet would. NAT across a WAN was never really a ?thing?. That being said, there are three config options related to NAT that you can try - <natEnabled>true</natEnabled> <natAddress>xx.xx.xx.xx</natAddress> <natReceivedProcessing>true</natReceivedProcessing> natAddress would be the phones local WAN IP address. Enabling natReceivedProcessing causes the phone to look at the 'received' tag in the via header of the 200 OK registration response for it's NAT address. I am not sure if natEnabled actually forces symmetrical NAT or not. Would be easy enough to test and find out I guess. If you think that the phone is requiring the reply to 5060 then you could also try rewriting the port on the outbound packets. Since the traffic didn?t originate from 5060 on the phone that would probably not be considered stateful and may require a static NAT on the firewall though. WRT to the SOHO router ALG issue, you can try running an alternate SIP listening port. it breaks most of the ALGs and lets your SBC handle far-end NAT traversal as it should. It also allows for some security through obscurity. Guarantee your SIP scans will go down. Just make sure that you don?t select another well-known port. I've almost never dealt with an instance where large deployments of unsupported endpoints turned out well. I realize that the usual tendency is for engineering to push back on a lot of requests, but there is good rationale for it in these cases. Allowing sales to force adoption of unsupported devices just so they can book revenue will usually result in a less than stellar onboarding experience, painful day one and beyond support issues, and a customer that leaves after a few months anyway wasting all of the dollars spent in engineering and operations to support the effort in the first place. One way to get around these issues is to tie your product offering to your selected endpoints. Probably 70% of the folks on this board sell Polycom phones, why? Is there any functionality that you deliver with your whizzbang VVX600 that a customer can't get on a 15 year old 79xx? Or a 2600 set with CENTREX features for that matter? OK, maybe BLF, but other than that probably not . . . If you develop a bespoke product offering that requires specific endpoints for delivery (presence integration, content delivery, video and collaboration features, integration with business systems) and train your sales force to sell based on value and using your unique feature set to wow and delight your customers, instead of selling on price point, then no customer will be able to build a strong business case for keeping their legacy endpoints. Not to mention that you have differentiated yourself from the other 10,000 guys selling Broadworks and Polycom and elevated yourself above the commodity vendors. Rob From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Mark Lindsey Sent: Tuesday, October 06, 2015 10:52 PM To: Pete E Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Cisco 7941 SIP 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"). 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. 3. The best thing to do with a customer's old device is trade in credit then liquidate. 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). But I remember Cisco 79xx configs having a "nat_enable" or similar flag that actually enable the symmetric sip. mailto:mark at ecg.co tel:+1-229-316-0013 http://ecg.co/lindsey On Oct 6, 2015, at 17:10, Pete E <peeip989 at gmail.com<mailto:peeip989 at gmail.com>> wrote: Greetings Voice Operators, 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. 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 private IP, port 5060. So when the SBC sees the private address it assumes it is being NAT'd through a firewall and replies back to public IP, port 49123. What we're seeing is that the home router passes the response back to private IP, port 49123, which the phone doesn't accept (because it wants it on 5060) and the REGISTER fails. 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. 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? Thanks, Pete _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
participants (7)
-
anakaoka＠trinet-hi.com -
ksuriyaarachchi＠alteva.com -
lindsey＠e-c-group.com -
peeip989＠gmail.com -
rdawson＠force3.com -
shripald＠gmail.com -
wayne.wenthin＠cascadetech.org