We are seeking advice on the best mode to put the Adtran in for a network that has 15 phones, each with 12 lines registered. We have the Adtran is SIP Proxy Transparent mode now, but I don't think it is meant to handle this many registrations / Shared Call Appearances. The Phones are Polycom's, and the are connected to a Hosted VoIP providers Broadsoft/Acme Packet SBC implementation. The site has plenty of bandwidth (20 Mbps dedicated fiber), so I don't think its a bandwidth issue. Should we enable any SIP proxy?
All lines don't register upon bootup (takes a while for all 12 to finally register on each phone). Then the phones all don't update the status of the lines when someone is on the phone.
That's 240 registrations, and with SCA notifications to each phone things will get pretty chatty. The 908e Gen.3 will likely solve the problem but it sounds like you might be better off with a local solution such as a 7100 rather than hauling all of that SIP back to the remote softswitch.
Another thing that may be going on is UDP fragmentation. With 12 line appearances as BLF/SCA the SIP messages are going to be pretty big. You could change the phones to TCP-preferred which will bypass the TA900 proxy (doesn't support TCP) but this will likely solve the problem.
The system design of 12 line appearances on each of 15 phones isn't praticularly scalable. Can you convince the customer to lose the key-system mentality?
That's 240 registrations, and with SCA notifications to each phone things will get pretty chatty. The 908e Gen.3 will likely solve the problem but it sounds like you might be better off with a local solution such as a 7100 rather than hauling all of that SIP back to the remote softswitch.
Another thing that may be going on is UDP fragmentation. With 12 line appearances as BLF/SCA the SIP messages are going to be pretty big. You could change the phones to TCP-preferred which will bypass the TA900 proxy (doesn't support TCP) but this will likely solve the problem.
The system design of 12 line appearances on each of 15 phones isn't praticularly scalable. Can you convince the customer to lose the key-system mentality?
Jay,
I changed all the phones to TCP preferred, and that seems to correct most of the issues. Looking at the Broadsoft VVX provisioning guide it seems Broadsoft recommends TCP Preferred for SIP which surprises me. Isn't UDP recommending for real time voice traffic?
Before I made this change I was noticing lots of SIP parse errors being reported on the Adtran, and the Polycom's were saying "please try again" on the screen.
Now that we are using TCP Preferred we will not be able to utilize Adtran VQM right? Also, should I turn off SIP Proxy if all phones are using TCP Preferred? What firewall settings should be put in place? Should SIP Services still be enabled?
No, I can't seem to get them to drop the key system mentality. Have any advice on how to do so? Is call park/retrieve the solution? They are not willing to buy a 7100 or another PBX, so everything has to be done on the Broadsoft. I just hate to see these Advanced VVX 500's being used for a hosted line key system!
fiberman wrote:
Jay,
I changed all the phones to TCP preferred, and that seems to correct most of the issues. Looking at the Broadsoft VVX provisioning guide it seems Broadsoft recommends TCP Preferred for SIP which surprises me. Isn't UDP recommending for real time voice traffic?
The real-time voice (RTP) is still UDP. SIP signaling is now TCP (if supported, hence "preferred"). The advanatages for SIP over TCP are that it handles fragmentation of large datagrams better and also has fewer issues traversing simple firewalls. The advantage for UDP is that it consumes less overhead. TCP solves some issues particularly when there are large SIP messages that must be fragmented. Of course your SBC and SIP PBX must support it. Both TCP and UDP are specified in the SIP RFC but the default these days is UDP.
Before I made this change I was noticing lots of SIP parse errors being reported on the Adtran, and the Polycom's were saying "please try again" on the screen.
This is likely due to the multiple line appearances in the key system emulation. As of the last time I checked, Adtran's SIP proxy didn't support TCP although some other parts of the SIP stack do. So your phones are using the basic NAT firewall for SIP. The TA900 series are better at dealing with SIP UDP fragmentation than the 3120 but in corner cases with lots of shared-line appearances going to TCP seems to fix a lot of things.
Now that we are using TCP Preferred we will not be able to utilize Adtran VQM right? Also, should I turn off SIP Proxy if all phones are using TCP Preferred? What firewall settings should be put in place? Should SIP Services still be enabled?
You can still use VQM, you'll need to select "All RTP" and not just "SIP RTP". This may cause a bump in CPU as there is more to inspect. If the box gets taxed, tweak VQM for less than 100% of calls. Nothing really to change in the firewall as long as you have NAT and Internet connection sharing configured. You're going from the inside out so it should just work. I would leave SIP enabled, it shouldn't hurt anything.
No, I can't seem to get them to drop the key system mentality. Have any advice on how to do so? Is call park/retrieve the solution? They are not willing to buy a 7100 or another PBX, so everything has to be done on the Broadsoft. I just hate to see these Advanced VVX 500's being used for a hosted line key system!
The customer is always right, even when they're wrong they're still the customer. There are a few situations where a key system makes sense in terms of a warehouse or retail situation where hold-resume from different phones is common. The learning curve for call park is kind of steep for these environments. Shared call appearances and BLF generate a LOT of SIP. It's not just the registrations but the NOTIFY, SUBSCRIBE, and all of the messaging every time a call rings, is answered, or is put on or taken off of hold to change the lights on every single phone. This really doesn't scale well at all.
Fiberman,
I wanted to check back in with you on this post. Were you able to resolve the situation? The ADTRAN unit does not support SIP over TCP while in transparent mode; it can work in stateful mode though. If you do not need SIP survivability or some sort of normalization, the SIP proxy may not be necessary in your case. Please let us know if you have any other questions by responding to this post.
Thanks!
David
Fiberman,
I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
Thanks,
David
So I am still having some trouble with this client. All phones are now on TCP Perferred, and the Broadsoft does support TCP. I have the SIP proxy off. Do I need to make an allow policy in my public zone (applied to the internet interface) to all any traffic from the SIP network range of IPs? Should I enable stateless processing on this allow?
The client says the BLFs don't always update, they are missing calls (phone never rings at the office, but rings on the calling parties phone, they refuse to use voicemail either), and they phones are still saying "Please Try Again" in the background even when on an active call?