Accessibility Avançar para o conteúdo
ID do artigo: 000040570
Last Modified Date: 10/12/2021
Access Level: Public

SpectraLink Wireless Telephone: PTT (Push To Talk) Call Flow

Introduction to PTT

PTT traffic in the SpectraLink SpectraLink system utilizes a proprietary technology to create a one-to-many call. In order to accomplish this multicast is used to ensure that only one instance of the session has to be generated by the transmitting handset. Multicast allows for a single stream of traffic to be duplicated and sent to multiple clients. This process allows for much less overhead and makes use of existing network technologies. In this design the phone can rely on the network to deliver the packet to each device that has subscribed to the multicast stream.


There are some limitations to multicast that every network administrator should be aware of before developing a multicast network. Likely the biggest limitation of multicast is how the network regards the traffic. A multicast packet is largely considered to be just like a broadcast and often gets the same treatment. This is frequently the case in networks that do not have multicast networking fully configured to support all the available features. Multicast packets will always be destined for a multicast group address. In the case of SpectraLink SpectraLink devices that multicast group address will always be The client transmitting the multicast stream directs its traffic to this group address and then other clients can subscribe to the group to receive the traffic. However, by default network devices, like switches, will simply forward multicast out all ports, hence treating it like a broadcast. This behavior is in place because the switch is not aware of which clients want to receive the stream so it will simply forward the traffic. Newer managed switches have implemented new features that allow them to ¿snoop¿. The switches have the ability to recognize the multicast messages from the clients that wish to join a particular multicast group and so they are able to generate a table of which ports should receive traffic for specific multicast groups. The benefit to this behavior is that the switch no longer has to flood the traffic out all ports which will reduce overhead in the network.   Another limitation of multicast once again relates to multicast being treated like broadcast traffic. Since routers in the network split up broadcast domains they will also segregate multicast traffic. What this really means is that a router will not forward any multicast traffic from one subnet or network to another subnet or network. It is possible to work around this limitation as most all network routers can be configured to support multicast routing. Multicast routing allows the router to receive multicast traffic on one network and pass that traffic to a different network. The configuration of multicast routing varies by manufacturer so be sure and check with your network hardware manufacturer on how best to configure your network for multicast routing. When configuring multicast on your network you will want to be sure and set the multicast mode to dense. There are two different modes which multicast can operate in, dense mode and sparse mode. But the SpectraLink products use only dense mode.

PTT in Practice

In the 802.11 world each packet between a phone and AP or from the AP to the phone much be acknowledge. When a phone transmits multicast push-to-talk packets the access point will ACK each packet from the phone so that the handset knows the packet has been received.   When a phone transmits push-to-talk the AP that first received the multicast traffic from the transmitting handset will need to retransmit those packets back out the AP¿s radio interface because there may be handsets associate to that AP that will need to receive this traffic. When the AP retransmits the packets it will take the transmitting phone¿s original packet and change the sequence number in the packets. Any phone that receives the multicast packets from the AP will also not acknowledge the packets because they are considered broadcast packets and in 802.11 broadcast packets are not acknowledged.   The AP that received the multicast packets will also send the packets out the Ethernet interface of the AP. The packets will be propagated through the network and depending on the switch types and their configuration the switches may flood the multicast traffic out all ports or simply forward it out ports that it has heard join requests for the multicast group. The packets will pass between switches and they will remain on the network they were generated on. If the packets encounter a router they will be forwarded only onto the same network they were received by the router on and will not be forwarded to any other network unless otherwise configured to do so, but we will discuss that later.   Take a look at this diagram for a visual description of the packet flow described above.   Once the packets have reached other AP¿s on the network the multicast traffic will be buffered and the AP will flag the Traffic Indication Map (TIM) for each client the traffic is destined for. When those clients come out of power save mode they will begin to receive the multicast stream. The packets will have the same sequence numbers as the packets from the original transmitting phone. This is because the AP¿s did not receive the multicast traffic on the radio interface and so they do not need to change the sequence number of the packets. The phones will receive the multicast packets in a burst of as many as 10 packets at a time and will be able to immediately begin buffering the audio payload in the packets into the jitter buffer of the phone so it can be played.   This process is continued throughout the PTT session and utilizes just as much bandwidth as a normal voice call. Keep in mind that because the multicast traffic is treated much like a broadcast in 802.11 there are no retries so if the phone misses one of the multicast packets there is the potential for audio loss. Because of this it is never possible to have audio quality in a PTT session as good as you would receive in a normal voice call. There is a higher likelihood of occasional choppy audio or small gaps in PTT, particularly while roaming, but overall the audio quality will be quite good.  

Multicast Routing

The topic of multicast routing is somewhat complex and is very dependent on the network manufacturer. Cisco implements multicast routing different from Nortel and so on so be sure and check with your manufacturer for the particulars of how to configure multicast routing.   In general, multicast routing will allow for multicast traffic to be available to multiple networks with a single source. An example of why one would configure multicast routing might be a site using push-to-talk but they have phones on two distinct subnets or networks. But even with this router boundary they need to have the PTT traffic from one subnet delivered to phones in the other subnet. This is very easy to configure on most routers and will allow all multicast traffic to traverse the router between those two subnets. On many routers it is possible to restrict the multicast traffic to specific multicast groups or even to specific devices but that is beyond the scope of this document.


As with any network deployment it is always important to consider the design and development necessary to make the system operate as expected. Many network administrators effectively use multicast to their advantage but many more view multicast as a deviant traffic type and try to prevent it. It is always best to understand the nature of the traffic and learn to control it in the best way possible. The push-to-talk traffic generated by SpectraLink handsets is a perfect example of a valuable tool that can be implemented in a safe and effective manner simply by understanding and designing the network appropriately.   All software versions