PTT Call Flow

Introduction to PTT
PTT traffic in the 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 must 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.

Multicast
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 don’t 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 devices that multicast group address will always be 224.0.1.116. 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 isn’t 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 can 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 must 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’ll 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.

Spectralink Corporation 1
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’ll discuss that in a later.

Take a look at this diagram for a visual description of the packet flow described above.

Spectralink Corporation 2
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 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 signal 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’s beyond the scope of this document.

Another aspect of why you may need multicast routing is related to how many wireless
controllers operate. Because controllers and AP’s communicate via a secure tunnel using
a protocol known as CAPWAP, the traffic between the two is often sent over a
management VLAN. The client traffic is encapsulated across this tunnel to the controller
where it can then be placed onto the appropriate VLAN. In many situations the traffic
must first be routed from the management VLAN to its destination VLAN. This would
mean that your PTT traffic would have to traverse a router boundary. If you didn’t enable
multicast routing between the management VLAN that the controller sits on and the
VLAN the phones use the multicast traffic would get dropped at the router interface of
the management VLAN. But, by enabling multicast routing on the router and then

Spectralink Corporation 3
enabling IP PIM sparse or dense mode, note that Spectralink PTT is a dense mode
multicast application, any traffic received from the management VLAN that is multicast
will be allowed to traverse the router boundary onto the voice VLAN. You can use access
control lists to limit multicast traffic if you need to as well. Many environments have
other multicast traffic for things like IPTV and they don’t want that traffic getting mixed
in or being sent to their AP’s. You’ll need to decide which multicast groups you want and
which you don’t. Every router vendor has several useful multicast routing commands to
allow you to control and see what’s happening with your multicast traffic these days. It’s
not as evil as it once was and isn’t just another broadcast packet anymore.

Handset Compatibility Notes

Be aware that PTT is backwards compatible with prior Spectralink product models.
However, there are some configuration changes that are required in order to make the
prior 8030 handsets interoperate with all newer handset models. Newer handsets utilize
the G.722 audio codec for high definition audio while the 8030 handsets only support
G.711MuLaw. Additionally, the legacy 8030 handsets only supported up to 8 channels
while the newer handsets can support up to 25 channels. This means that you would be
unable to communicate with the legacy phones on any channel above channel 8 on the
newer models. The Spectralink 8030 handset and all its OEM equivalent models,
including the Avaya 3645, Nortel 6120 and NEC MH150 all offer similar support for
PTT. If you’re using the Spectralink 84-Series, 87-Series or Versity handsets you’ll
notice that you now can change the multicast group and ports used for PTT. Changing
these values would further prevent backwards compatibility with the legacy 80-Series
handsets.

Troubleshooting Tips
The following are some common troubleshooting tips that might help you with solving
why PTT might not be working in your environment. Some of these are things that we at
Spectralink have learned over time and others are just good things to verify while
troubleshooting a challenging problem.
1. PTT is not enabled via the handset’s User Interface.
2. Incorrect AP configuration – ensure recommended settings are set correctly, but
especially the DTIM setting. (usually the case if not all phones on the same AP
wake up or wake up together) DTIM will usually be set to 1 but reference the
VIEW guide for your AP model for the recommended setting.
3. IP Multicast being filtered by the AP (ensure IP filtering is disabled)
4. “Peer” mode being blocked by the AP configuration (The AP stops two clients
from exchanging packets via the AP – this is a new security feature employed in
many wireless controller products and AP’s focused on the wireless hotspot
environment that prevent clients from communicate with each other through the
same AP. Also known as Peer-to-Peer Blocking.
5. IP Multicast not enabled in the Network Switch layer. (IP multicast addresses are
used for the PTT streams - see below)
6. IGMP Snooping settings in the WLAN/switching layer affecting packet delivery –
this has proved to be vendor dependent and often tricky to pin down, e.g.

Spectralink Corporation 4
  It was identified that disabling IGMP on Cisco Catalyst 6500 core
switches enabled packet delivery even though IGMP is still enabled in the
edge switches. Packet delivery was blocked with IGMP enabled on the
6500. Configuring the 6500 to participate in the multicast group will
prevent it from being pruned.
 Extreme Summit 300 and Alpine 3804 series switches were found to stop
passing multicast packets after some amount of time.
 It was identified that the Alpine switch has an "IGMP snooping timer" that
was at a default setting of 260 seconds. So, after 260 seconds it would
remove or prune the multicast address from its group membership list and
stop passing multicast packets. The work around was to set the IGMP
snooping timer to the max value (68 years).

Spectralink uses the multicast group address 224.0.1.116 for PTT. All this
communication is done via UDP over port 5001-5025 (different ports for different
channels), and we use port 5454 for legacy Netlink inter-Gateway discovery. Spectralink
legacy infrastructure products will respond to IGMP membership packets on 224.0.0.1
when received.

Conclusion
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 multicasts
as a deviant traffic type and try to prevent it. It’s 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.

Spectralink Corporation 5
Copyright Notice
© 2019 Spectralink Corporation All rights reserved. SpectralinkTM, the Spectralink logo and the
names and marks associated with Spectralink’s products are trademarks and/or service marks of
Spectralink Corporation and are common law marks in the United States and various other
countries. All other trademarks are property of their respective owners. No portion hereof may be
reproduced or transmitted in any form or by any means, for any purpose other than the recipient’s
personal use, without the express written permission of Spectralink.
All rights reserved under the International and Pan-American Copyright Conventions. No part of
this manual, or the software described herein, may be reproduced or transmitted in any form or
by any means, or translated into another language or format, in whole or in part, without the
express written permission of Spectralink Corporation.
Do not remove (or allow any third party to remove) any product identification, copyright or other
notices.

Notice
Spectralink Corporation has prepared this document for use by Spectralink personnel and
customers. The drawings and specifications contained herein are the property of Spectralink and
shall be neither reproduced in whole or in part without the prior written approval of Spectralink,
nor be implied to grant any license to make, use, or sell equipment manufactured in accordance
herewith.
Spectralink reserves the right to make changes in specifications and other information contained
in this document without prior notice, and the reader should in all cases consult Spectralink to
determine whether any such changes have been made.
NO REPRESENTATION OR OTHER AFFIRMATION OF FACT CONTAINED IN THIS
DOCUMENT INCLUDING BUT NOT LIMITED TO STATEMENTS REGARDING CAPACITY,
RESPONSE-TIME PERFORMANCE, SUITABILITY FOR USE, OR PERFORMANCE OF
PRODUCTS DESCRIBED HEREIN SHALL BE DEEMED TO BE A WARRANTY BY
SPECTRALINK FOR ANY PURPOSE OR GIVE RISE TO ANY LIABILITY OF SPECTRALINK
WHATSOEVER.

Warranty
The Product Warranty and Software License and Warranty and other support documents are
available at http://support.spectralink.com.

Contact Information
US Location Denmark Location UK Location
+1 800-775-5330 +45 7560 2850 +44 (0) 20 3284 1536
Spectralink Corporation Spectralink Europe ApS Spectralink Europe UK
2560 55th Street Bygholm Soepark 21 E Stuen 329 Bracknell, Doncastle Road
Boulder, CO 80301 8700 Horsens Bracknell, Berkshire, RG12 8PE
USA Denmark United Kingdom
info@spectralink.com infoemea@spectralink.com infoemea@spectralink.com

Spectralink Corporation 6