Limitations on Monitored Lines Version 1.0 April 7, 2014 1009 Pruitt Road The Woodlands, TX 77380 WWW.BROADSOFT.COM
Table of Contents 1. MONITORING LINES... 1 2. HOW MONITORING WORKS... 1 3. SIP MESSAGE TRANSPORT PROTOCOL AND FRAGMENTATION... 1 4. NUMBER OF BLF LINES SUPPORTED ON PHONES WITH EXPANSION MODULES... 2 5. RECOMMENDATION... 3 BroadSoft Confidential ii
1. Monitoring Lines As one of the functions offered by the BroadCloud PBX service, Monitoring allows a station in the network to view the call state of other stations in the network. This feature is based on the BroadWorks Busy Lamp Field (BLF) service. Conventionally, this application is found commonly used by executive assistants or front desk operators. The operators use an enhanced station type and a phone model that offers enough line keys to adequately monitor a large set of lines in the network. Some models of Polycom and Cisco phones can support expansion modules to add additional keys to a device. Keys on an expansion module are typically configured for speed dial and allow the attendant to monitor a larger number of users. 2. How Monitoring Works The BroadCloud PBX service uses SIP SUBSCRIBE and NOTIFY messages as defined in RFC 4235, RFC 4662 and RFC 3265 to communicate with phones about the list of resources to be monitored and the state of monitored phones. The end devices or IP phones send SUBSCRIBE requests for a resource list URL to BroadCloud PBX Application Servers. Once the server grants a subscription, it will notify the IP phones of the current state of all resources by sending NOTIFY requests with corresponding state information for all resources identified by the resource list. Once the NOTIFY messages are received, the IP phones will populate the keys based on the resource list contained in the NOTIFY message, the IP phone is ready to monitor the phones on the list. After receiving the NOTIFY packet, the IP phone must send a 200 OK response to the Application Server to show that the message was received. When a subscribed resource transitions to a different call state, the Application Server will send a NOTIFY request to the IP phones that have subscribed to the resource to inform them about the changes. Receipt of each NOTIFY packet will result in corresponding 200 OK response from the IP Phone. IP phones will refresh their subscription to the BLF service by sending additional SUBSCRIBE messages when the timer expires. The current SUBSCRIBE timer is 30 minutes in BroadCloud PBX network. The Application Servers will send corresponding NOTIFY requests to IP Phones upon receipt of the SUBSCRIBE refresh packet. 3. SIP Message Transport Protocol and Fragmentation BroadSoft Confidential 1
In the BroadCloud PBX network, SIP packets are transported using User Datagram Protocol (UDP). UDP is the de facto protocol for SIP in the industry. As part of SIP, SUBSCRIBE and NOTIFY messages are sent across network in UDP packets. Depending on the combined length of contact information fields of the users to be monitored, the NOTIFY packets are typically larger than the MTU (maximum transmission unit) defined in the routers, firewalls, and other data transmission equipment. As a result the UDP packets have to be fragmented into a number of smaller packets to fit the MTU size as they are sent out to the network. UDP does not have mechanism to ensure fragmented packets arrive at the remote end reliably, as it relies on Network or IP layer to fragment and reassemble large IP packets. Issues can arise when packets loss happens or when packets arrives out of order. UDP fragmentation could also cause issues with NAT and firewall traversal. In Ethernet networks, MTU size is typically set to 1500 bytes. A UDP datagram can be up to 65507 bytes in size. A UDP datagram of 65507 bytes will have to be fragmented into 45 packets ( Max UDP size of 65507 bytes / UDP size per packet of 1480 bytes ~ 45) to be transmitted across a network. With this many number of fragments, customer firewalls or NAT devices may prohibit the entire packet from being delivered to the endpoint. In addition, packet loss and arrival out-of-order may happen when network conditions are not in an optimal state. Either situation will prevent a phone from populating monitored phones properly. 4. Number of BLF Lines Supported on phones with Expansion Modules The maximum number of monitored or BLF lines supported on a VVX phone with Expansion Modules is 50. This is the limit on both the PBX call control platform and Polycom phones. The limit has to do with the maximum size of a UDP datagram. According to the TCP/IP specification, the maximum UDP datagram is 65507 bytes for pay load, the size can contain the information from up to 50 monitored phones with all the contact fields populated. However the maximum number of 50 BLF lines is not always guaranteed. The actual number of BLF lines that are populated on the phone can vary depending on network conditions, the type of customer premise firewalls or NAT devices, and their configurations. A common issue that has been observed is the firewall or NAT traversing issue. Some firewalls will simply drop any fragmented packets while the others will drop packets when the number of fragmented packets exceeds a configured or default limit. For example, the Cisco ASA 5500 firewall by default will drop a packet if the packet has been fragmented into more than 24 packets. When this happens, phones will not receive the BLF NOTIFY message. As a result phones can only display a certain number of BLF lines. BroadSoft Confidential 2
In some cases, the BLF list may disappear on a phone when the number of BLF lines exceeds the limit defined on a customer premise firewall. Following are the charts illustrating the relationship between number of contacts or BLF lines, the NOTIFY packet size and number of fragments. The first table assumes a total of 30 characters for first and last names; the second table assumes a total of 40 characters between first and last names. With the Ethernet MTU at 1500 bytes, a NOTIFY packet will have to be fragmented even with a single monitored line. As shown below, if a firewall is configured to not allow fragmented packets, the phones behind that firewall will fail to display any monitored lines; if 5 fragmented packets are allowed a phone will be able to monitor up to 7 other phones; or if 10 fragmented packets are allowed, a phone will be able to display up to 16 or 17 other phones depending if it s 30 or 40 characters, so on and so forth. # of Contacts in List 1 2 3 4 5 7 17 Pkt Size (30 char)(bytes) 1725 2475 3225 3975 4725 6225 13725 Fragments 2 2 3 3 4 5 10 # of Contacts in List 1 2 3 4 5 7 16 Pkt Size (40 char)(bytes) 1755 2535 3315 4095 4875 6435 13455 Fragments 2 2 3 3 4 5 10 5. Recommendation The recommended solution is to configure the firewalls and/or NAT routers at customer premises to handle fragmented UDP packets correctly. These firewall and NAT routers must be configured to support the maximum UDP payload size of 65507 bytes and to allow at least 45 fragmented packets per packet. As an example, the Cisco firewalls need to be configured to increase the allowed fragments per packet to 45 from the default 24 (The maximum supported fragments is 8500 in the case of Cisco firewalls). BroadSoft Confidential 3