8AL90880USBA

IP-DECT:
Network and troubleshooting manual

4080 IP-DECT
8340 Smart IP-DECT
8AL 90880 USBA ed01

10/2013
IP-DECT: Network and troubleshooting manual
1. IP-DECT SYSTEM .................................................................................................................................................... 4
1.1 GENERAL ................................................................................................................................................................. 4

1.2 SYSTEM CONFIGURATIONS ........................................................................................................................................... 5
2. DAP CHARACTERISTICS ........................................................................................................................................ 12
2.1 GENERAL ............................................................................................................................................................... 12

2.2 POE SPECIFICATIONS ................................................................................................................................................ 12
2.3 IP SPECIFICATIONS ................................................................................................................................................... 12
2.4 RTP SPECIFICATIONS ................................................................................................................................................ 13
2.5 IP PORTS ............................................................................................................................................................... 13
3. DAP CONTROLLER BEHAVIOUR IN THE NETWORK ............................................................................................... 14
3.1 GENERAL ............................................................................................................................................................... 14

3.2 VIRTUALIZATION...................................................................................................................................................... 14
3.3 DAP CONTROLLER PORT USAGE .................................................................................................................................. 14
3.4 IP ADDRESS ............................................................................................................................................................ 14
3.5 IP MULTICAST ......................................................................................................................................................... 14
4. IP SWITCH SETTINGS ............................................................................................................................................ 15
4.1 REQUIREMENTS FOR IP SWITCHES IN AN IP-DECT NETWORK ........................................................................................... 15

4.2 EXAMPLE OF SWITCH CONFIGURATION ......................................................................................................................... 16
5. IP ROUTER SETTINGS ........................................................................................................................................... 16
5.1 GENERAL ............................................................................................................................................................... 16

5.2 CONNECTIVITY ON IP ROUTERS IN AN IP-DECT “ROUTED HEAD QUARTER CONFIGURATION” ................................................ 17
5.3 CONNECTIVITY ON IP ROUTERS IN AN IP-DECT “BRANCH OFFICE CONFIGURATION” ............................................................ 17
5.4 QUALITY OF SERVICE ISSUES....................................................................................................................................... 18
5.5 EXAMPLE OF ROUTER CONFIGURATION ........................................................................................................................ 18
6. PRIORITY / QOS / VLAN SUPPORT ....................................................................................................................... 19
7. DHCP SERVER ...................................................................................................................................................... 19
7.1 GENERAL ............................................................................................................................................................... 19

7.2 RECOMMENDED DHCP SERVERS ................................................................................................................................ 20
7.3 BUILT-IN DHCP SERVER IN DAP CONTROLLER .............................................................................................................. 20
8. TFTP SERVER ........................................................................................................................................................ 20
9. DHCP-LESS / TFTP-LESS ........................................................................................................................................ 20
10. IP MULTICAST BEHAVIOUR .............................................................................................................................. 21
10.1 INTRODUCTION ....................................................................................................................................................... 21

10.2 RFC REFERENCES..................................................................................................................................................... 21
10.3 DECT ACCESS POINT NETWORK INTERFACE .................................................................................................................. 21
10.4 MULTICAST CONFIGURATION ..................................................................................................................................... 21
10.5 THE IGMP SNOOPING PROBLEM ................................................................................................................................ 22
10.6 THE IGMP SNOOPING SOLUTION................................................................................................................................ 23
10.7 MULTICAST HOST BEHAVIOUR OF A DAP ...................................................................................................................... 23
10.8 MULTICAST ............................................................................................................................................................ 24
8AL 90880 USBA ed01 2

10.9 MULTICAST “PING” TEST MECHANISM ......................................................................................................................... 25
11. TROUBLESHOOTING AND DEBUGGING ............................................................................................................ 30
11.1 DEBUG TOOL: DAP VIEWER....................................................................................................................................... 30

11.2 DEBUG TOOL: DECT PERFORMANCE ANALYZER............................................................................................................. 35
11.3 DEBUG TOOL: PERFORMANCE MANAGER INTERFACE ...................................................................................................... 48
11.4 DEBUG TOOL: IP-DECT WEB PAGE OF A DAP ............................................................................................................... 50
11.5 SUPPORTIVE TOOLS .................................................................................................................................................. 52
11.6 ROUTER MULTICAST COMMANDS................................................................................................................................ 53
11.7 HOW TO SOLVE MULTICAST ISSUE ON A PC ................................................................................................................... 55
11.8 HOW TO SEE THE HOST NAME USED IN DHCP OPTION 12 WITH WIRESHARK ....................................................................... 57
11.9 HOW TO CALCULATE THE AGGREGATED SUBNET MASK .................................................................................................... 57
11.10 MOVE SUBSCRIPTIONS OF NON OPERATIONAL DAP AND ABSENT DAP THRESHOLD .......................................................... 58
12. APPENDIX 1: IP MULTICAST TECHNOLOGY OVERVIEW .................................................................................... 59
12.1 CONCEPT OF IP MULTICAST GROUP ............................................................................................................................. 59

12.2 MULTICAST / IGMP ................................................................................................................................................ 59
12.3 MULTICAST / ROUTERS............................................................................................................................................. 67
12.4 MULTICAST / DAPS ................................................................................................................................................. 70
13. APPENDIX 2: EXAMPLE OF ROUTED HEADQUARTER CONFIGURATION WITH IGMP AND PIM-SM ................... 72
14. APPENDIX 3: EXAMPLE OF ROUTED HEADQUARTER WITH BO ........................................................................ 74
15. APPENDIX 4: ROUTING TABLE OF THE DAP CONTROLLER ................................................................................ 75
16. APPENDIX 5: WIRESHARK EXAMPLE OF A MULTICAST “PING” FROM A DAP ................................................... 76
17. APPENDIX 7: RFC2236 (IGMP V2) .................................................................................................................... 79
17.1 INTRODUCTION ....................................................................................................................................................... 79

17.2 PROTOCOL DESCRIPTION ........................................................................................................................................... 80
17.3 COMPATIBILITY WITH IGMPV1 ROUTERS..................................................................................................................... 82
17.4 COMPATIBILITY WITH IGMPV1 HOSTS ........................................................................................................................ 82
17.5 HOST STATE DIAGRAM ............................................................................................................................................. 83
17.6 ROUTER STATE DIAGRAM.......................................................................................................................................... 85
17.7 LIST OF TIMERS AND DEFAULT VALUES .......................................................................................................................... 88
17.8 MESSAGE DESTINATIONS........................................................................................................................................... 90
17.9 SECURITY CONSIDERATIONS ....................................................................................................................................... 90
8AL 90880 USBA ed01 3

1. IP-DECT system
1.1 General
The IP DECT system offers an implementation of the proven DECT techniques in an IP network. It
is important to understand the network behaviour of the various components in the IP DECT system.
First of all, it is important to understand the IP-DECT system configuration.
Figure 1: IP-DECT system configuration
The simple system consists of the following components:
 DAPs
A DAP (DECT Access Point) is the actual transceiver. There are various types of DAP available. For
detailed information about the DAPs, consult the chapter 2 ―DAP CHARATERISTICS‖. The DAPs
have a built-in WEB server.
 IP Switch with PoE
Normally, the customer offers the IP Network, and therefore, in general, the customer determines
the type of IP Switch. For more info, consult chapter 4 ―IP SWITCH SETTINGS‖.
 DAP Controller
The DAP Controller is the software to initialize the system and to maintain the system. Please note:
in some cases the DAP Controller should be running permanently.
It runs under MS Windows:
- Windows 7 (not the home edition),

- Windows 2008.
- Windows 2012.
8AL 90880 USBA ed01 4

For older versions of Windows, please consult the ―IP-DECT CE manual for SIP connectivity‖.
For more information about the network characteristics, consult chapter 3 ―DAP CONTROLLER
BEHAVIOUR ON THE NETWORK‖.
The DAP Controller uses IIS (Internet Information Services) as WEB server.
 OmniPCX
ALE IP-DECT supports OmniPCX Enterprise and OmniPCX office
 Handsets
There is a variety of ALE DECT handsets available: 8232 DECT Handset, 400 DECT Handset, 500
DECT Handset, 500 EX DECT Handset.
The following sections show the possible system configurations of IP-DECT.
1.2 System configurations

The IP-DECT system must be implemented in a company infrastructure.
As mind setting tool, this chapter gives you the three system configurations including all typical
network configurations.
You should consider which configuration you must implement at the customer site.
In the ―IP-DECT CE manual for SIP connectivity‖ you will find more information about the network
configurations.
You can select the type of system that you want to use. Once you have decided which network
configuration you need, setup the appropriate system configuration.
The three system configurations are given hereafter:
In the ―IP DECT Advance Data Manual‖, you will find more information about the system behaviour
over a router, in chapter ―System Behavior over Router‖.
1.2.1 Simple Configuration

Figure below shows an example of a simple configuration. All IP-DECT devices are put in one
subnet. This subnet is based on one or more IP switches. If the switches serve more than one
VLAN, all IP DECT devices are put in one VLAN (therefore behaving as one subnet).
8AL 90880 USBA ed01 5

Figure 2: "Example of Simple IP DECT network configuration"
Note: The figure above is based on IPv4 Private IP addressing. However, it is of course
possible to use IPv4 Public addressing.
1.2.2 Routed Head Quarter

Figure below shows an example of a Routed Head Quarter configuration with a head quarter and
two subnets connected via one or more routers. The subnets in the network are part of one
company network.
The general characteristics of an IP DECT Routed Head Quarter configuration are as follows:
− Used for a Large Campus network that is split up into different (geographical) subnets.
− The network supports QoS and IP connectivity all over the Campus.
− IP DECT configuration behaves as one large IP DECT system.
− Full support of seamless handover between all DAPs in the IP DECT system.
− Routers must support IP Multicast routing.
− The IP Multicast address for IP DECT is the same in all segments.
− Multicast TTL > 1, which means that the routers pass on the IP multicast packages.
− In the IP DECT configuration, you must enter the subnet mask that is needed to cover all
networks for up to four subnets as in the previous example.
Note: The DAP manager is always mandatory in a Head Quarter configuration.
8AL 90880 USBA ed01 6

Figure 3: "Example of an IP-DECT Routed Head Quarter configuration"
Note: The figure above is based on IPv4 Private IP addressing. However, it is of course possible to
use IPv4 Public addressing.
1.2.3 Multiple subnets

This system configuration allows you to have the IP-DECT system over various subnets. A number
of configurations are possible. You will need this configuration window to setup:
 A Head Quarter with Branch Office.
 A Routed Head Quarter with Branch Office.
 A Routed Head Quarter with a Routed Branch Office.
In the ―IP-DECT CE manual for SIP connectivity‖ you will find more information about the network
configurations.
Note: The window “Multiple Subnets” offers the possibility to specify a certain RPN range per
Branch Office Subnet. Note that you should set the RPN range wide enough to allow future system
expansion.
8AL 90880 USBA ed01 7

1.2.3.1 Head Quarter with Branch Office(s)

Figure hereafter shows an example of a Branch Office configuration with a main office (head
quarter) and two Branch Offices.
Main Office and Branch Offices are in different subnets connected via routers. Routers can be
connected over the WAN.
The general characteristics of an IP DECT configuration with Branch Offices are as follows:
− Allows interconnections with poor QoS between Head Quarter and Branch office(s).
(Radio Links, ADSL etc.).

Note: The bandwidth is always sufficient for signalling (considering low throughput LAN).
− No OXE PBX needed in Branch Office(!).
− Seamless handover is supported in Branch Offices and in Main Office.
− No handset handover between Head Quarters and (individual) Branch Offices.
− Head Quarter and individual Branch Offices must be in separate subnets (router(s) needed).
− No IP multicast support required for Routers.
− Multicast TTL = 1, which means that IP multicast packages does not cross a router.
Figure 4: "Example of an IP DECT Head Quarter configuration with Branch Offices"
8AL 90880 USBA ed01 8

Note: The figure above is based on IPv4 Private IP addressing. However, it is of course possible to
use IPv4 Public addressing. However, each Branch Office location must be in a different network
segment, compared to other Branch Office locations and the Head Quarter.
A distance greater than 600 meters is needed between “headquarter location and BO
locations” and between “all BO locations”.
1.2.3.2 Routed Head Quarter with Branch Office(s)

Figure below shows an example of a Routed Head Quarter with Branch Office configuration with a
routed head quarter, one subnet connected via one or more routers and a Branch Office.
The subnets in the network are part of one company network, the Branch Office is connected over
the WAN (or low throughput LAN).
The general characteristics of an IP DECT Routed Head Quarter configuration with Branch Office(s)
are as follows:
− Hybrid of Routed Head Quarter and Branch Offices (see previous sections).
− Used for a Large Campus network that is split up into different (geographical) subnets in
combination with (remote) Branch Offices.
− In the Routed Head Quarter part, all characteristics which are mentioned previously for the
Routed Head Quarter are applicable.
− For the Branch Office, all characteristics which are mentioned in the section covering the
Branch Offices are applicable.
− In the Head Quarter the Multicast TTL >1, in the branch Office the Multicast TTL =1(!).
− Edge Router, connected to the WAN, should not forward Multicast packages to the WAN.
− Full support of seamless handover between all DAPs in the Head Quarters configuration with
the subnet.
− Routers in the Head Quarter must support IP Multicast routing.
− In the IP DECT configuration, you must define which subnets are in the Head Quarters and
which subnet(s) is/are Branch Office subnets. You must do that by means of specifying the subnet
mask that is needed to cover all Head Quarters subnetworks.
8AL 90880 USBA ed01 9

Figure 5a: "Example of an IP DECT Routed Head Quarter configuration with Branch Office"
Note: A distance greater than 600 meters is needed between “routed headquarter location and BO
locations” and between “all BO locations”.
1.2.3.3 Routed Head Quarter with Routed Branch Office(s)

Figure below shows an example of a Routed Head Quarter with Routed Branch Office configuration
with a routed head quarter, one subnet connected via one or more routers and a Branch Office.
The subnets in the network are part of one company network, the Branch Office is connected over
the WAN (or low throughput LAN).
The general characteristics of an IP DECT Routed Head Quarter configuration with Branch Office(s)
are as follows:
− Hybrid of Routed Head Quarter and Branch Offices (see previous sections).
− Used for a Large Campus network that is split up into different (geographical) subnets in
combination with (remote) Branch Offices.
− In the Routed Head Quarter part, all characteristics which are mentioned previously for the
Routed Head Quarter are applicable.
 In the Routed Branch Office part, all characteristics which are mentioned previously for the
Routed Head Quarter are applicable, except for that the Routed Branch Office must be in
different subnets than the Routed Head Quarter.
8AL 90880 USBA ed01 10

− In the Head Quarter the Multicast TTL >1, in the branch Office the Multicast TTL >1(!).
− Edge Router, connected to the WAN, should not forward Multicast packages to the WAN.
 The Routers between the Routed Head Quarter and the Routed Branch Office should block
Multicast!
 Full support of seamless handover between all DAPs in the Head Quarter configuration with the
subnet. Full support of hand over in the Routed Branch Office. No handover between the Routed
Head Quarter and the Routed Branch Office.
 Routers in the Head Quarter must support IP Multicast routing.
 Routers in the Routed Branch Office should support IP Multicast Routing.
 In the IP DECT configuration, you must define which subnets are in the Head Quarters and
which subnet(s) is/are Branch Office subnets. You must do that by means of specifying the
Aggregated subnet mask that is needed to cover all Head Quarters subnetworks.
Also in the Routed Branch Office, you must calculate the Aggregated subnet mask that covers
all subnets in the Routed Branch Office.
Figure 5b: "Example of an IP DECT Routed Head Quarter configuration with Routed Branch Office"
Note: A distance greater than 600 meters is needed between “routed headquarter location and
routed BO locations” and between “all routed BO locations”.
8AL 90880 USBA ed01 11

2. DAP characteristics
2.1 General
In this chapter, you see an overview of the network characteristics of a DAP. Please note that there
are minor differences between the DAP types: 4080 IP DECT (AP300) and 8340 Smart IP DECT
(AP400).
2.2 PoE specifications
Item Value
Power over Ethernet IEEE 802.3af
Voltage via PoE 36 . . . . 57 V. DC
PoE Class Class 2
Power Consumption 6 Watt maximum
Table 2-1: PoE specifications
Note: PoE source must comply with EN 60950-1 clause 2.5 (Limited Power Source)
2.3 IP specifications
Item Value
Network 10/100Base-T IEEE802.3
Auto-negotiate Yes
Connector type: RJ45
Cable Cat 5 / Cat 6 UTP. Cat 7 is not supported!
IP Version IPv4
DHCP/TFTP support Yes
Quality of Service IEEE802.1q, IEEE802.1p (optional)
IGMP Version 2 / AP300 (and older type AP200)
Version 3 / AP400
Default Multicast Address 239.192.49.49 (changeable)
DHCP Yes
TFTP Yes, to download configuration file and firmware.
Table 2-2: IP specifications
8AL 90880 USBA ed01 12

Note: IP Multicast is used for signaling only. It is NOT used for streaming audio. So, the IP Multicast
load on the network is very low.
2.4 RTP specifications
Item Value
AP300 / AP400, no Daughter Board G.711
AP300 / AP400 with Daughter Board G.711 and G.729
Table 2-3: Audio algorithm.
2.5 IP ports
Protocol Transport Default ports

Protocol
IP DECT Proprietary signalling (IP Unicast and IP UDP/TCP 3000-22635

Multicast), SIP Protocol and RTP (Real Time Protocol)
HTTP TCP 80
PrintF (Proprietary protocol) TCP 2050
Table 2-4: IP ports on DAPs.
Protocol Default ports
DHCP request to DHCP server 67
68
TFTP to TFTP server 69 (only for initial communication) then:1024-65535
Table 2-5: IP ports, outgoing.
8AL 90880 USBA ed01 13

3. DAP Controller behaviour in the network
3.1 General
The DAP controller software runs on a PC with a Windows operating system.
3.2 Virtualization
Virtualization is possible with DAP Controller Release 5.24 and higher, on VMWare and Xen.
3.3 DAP controller port usage
The DAP Controller software consists of a number of components. The DHCP server and the TFTP
server are optional:
- DAP Controller services

- DAP Manager WEB interface
- FWU software
- DHCP Server (optional)
- TFTP Server (optional)
In the following table you see an overview of the ports used by the DAP Controller
Service Protocol Default ports
DAP controller IP DECT Proprietary signalling 28000 - 28017

(IP Unicast and IP Multicast),
Firmware uploading.
DAP Manager HTTP 80
DHCP Server (Optional !) DHCP 67
TFTP Server (Optional) TFTP 69 (only for initial

communication) then:1024-
65535
Table 3-1: IP ports on DAP controller.
3.4 IP address
The DAP Controller should have a statically allocated IP address.
3.5 IP multicast
The DAP controller does not need to receive IP multicast packets. This means that the DAP
controller does not support IGMP.
However, the DAP controller transmits IP multicast packets to test the network and for diagnostic
purposes. The number of packets is very low.
8AL 90880 USBA ed01 14

4. IP switch settings
4.1 Requirements for IP switches in an IP-DECT network
The following settings should be set correct in the IP switches for an IP-DECT network.
 Make sure that the switch supports IP multicasting.
Switches used in an IP-DECT network must support IP multicast forwarding to all ports where DAPs
are connected.
 Make sure that “IGMP Snooping” is switched off.
This is the recommended setting. However, when there is multicast traffic besides the IP-DECT
multicast traffic, the network manager may request for having IGMP Snooping switched on.
When IGMP Snooping must be switched on in the switch, you must make sure that there is an IGMP
Querier in the network and you must make sure that the IGMP Querier timers are set correctly.
When the switch has a built-in IGMP Querier, it is recommended to make that querier active. If there
are more IGMP Queriers in the network segment, the one with the lowest IP Address will become
active. The other(s) will automatically shut down.
(Note that the timers in the Queriers can be different).
Note: For more information about IP multicast and IGMP, please consult chapter 10.
 Disable Spanning Tree Protocol on the ports where DAPs are connected.
As soon as the DAPs are powered up, they perform a DHCP request almost immediately.
This means that the switch must allow IP traffic immediately (and does not go through the Spanning
Tree scanning stages).
Therefore, if possible, make sure that a Spanning Tree Protocol is disabled on a port where DAPs
are connected. If Spanning Tree is switched on, on IP Switch level, and Spanning Tree cannot be
switched off per port, please make sure that Port Fast Forward is switched on.
 Enable Port Fast forward on IP Switch ports where DAPs are connected.
This setting is required.
 Auto-Negotiation
The DAPs use auto-negotiation on IP switch ports. Set the IP switch ports, where DAPs are
connected, to auto-negotiate.
As a result both parties will determine to use full-duplex and 100BaseT (unless a hub is in between
the switch port and DAP).
 Using VLAN Ids and Priority (IEEE 802.1q and IEEE 802.1p)
There are two options to work with VLAN IDs and priority:
- Port Based (Strongly recommended)

- Trunk based.
8AL 90880 USBA ed01 15

When using Port Based, the Switch port should not accept any IEEE802.1q tagging from the DAP.
The VLAN ID and priority are set on the switch port manually.
Since a DAP is an end-point, it is strongly recommended to use the ‖Port Based‖ option.
If VLAN tagging and QoS by DAP are required, QoS on layer 2 and VLAN ID need to be configured
in the DAP Configurator.
 QoS on Layer 3 (if used on the IP switch)
The DAPs support Differentiated Services (QoS) on layer 3 (optional).

The DSCP value at the DAP side can be configured by using the DAP configurator.
The default value is 46 (Expedited Forwarding).
4.2 Example of switch configuration
Edge switch (Ex: 172.24.190.218 with DAPs on port 3/47 and port 3/48)
.
ip multicast status enable
vlan 426 enable name "Alfatests IPDECT BUR"

vlan 426 port default 3/47
vlan 426 port default 3/48
interfaces 3/47 alias "IPDECT-7 P41"

interfaces 3/48 alias "IPDECT-9 P41"
lanpower start 3/47

lanpower start 3/48
5. IP router settings
5.1 General
The following items are important for routers in an IP-DECT network.
Determine whether you have a Routed Head Quarter configuration or a Main Site with Branch
Offices. (Consult chapter 1: ―IP-DECT system‖).
In a Routed Head Quarter, the DAPs are in one IP-DECT system with handover from DAP to DAP,
but the DAPs are connected over one or more routers. In such a configuration, the routers must
support IP multicast forwarding.
In a Branch Office configuration, there is a main site and there are one or more Branch Office
locations. The Main site and the Branch office location(s) are in different network segments. This
means that there are routers in between the network segments. These routers do not need to be
multicast enabled.
8AL 90880 USBA ed01 16

5.2 Connectivity on IP routers in an IP-DECT “Routed Head Quarter Configuration”
(For more info on a Routed Head Quarter configuration, consult Section ―Routed Head Quarter‖.)
 IP Unicast Routing.
Unicast routing depends on routing mechanisms/protocols like OSPF (Open Short Path First).
Routing rules/tables in the router determine the IP connectivity between the subnets. Routers must
allow IP Unicast connectivity between the network segments with IP DECT Equipment. This is
applicable for Routed Head Quarter configurations as well as Branch Office configurations.
 IP Multicast Routing.
The router(s) must support IP multicast packet forwarding to all subnets where multicast packets for
the IP DECT multicast group are required. IP multicast routing between routers depends on routing
mechanisms/protocols. The most commonly used routing mechanism is PIM-SM.
The choice of a routing mechanism/protocol depends on the customers IT department. No matter
what protocol is chosen, in general, the IP Network over the router must be transparent for IP
multicast to allow DAP to DAP multicast over the router(s).
 IGMP (Required for Multicast Routing)
A router uses IGMP (Internet Group Management Protocol) to find out where multicast packets
should be send to. IP DECT uses IGMP version 2 (AP300) and IGMP version 3 (AP400).
IGMP is required for forwarding IP multicast packets in the IP switch, if IGMP snooping is switched
on in the IP switches.
Please note that nowadays, IP switches can be equipped with an IGMP Querier function as well.
Either the router IGMP Querier is used, or the IP switch Querier.
The Querier with the lowest IP Address will be activated automatically (in IGMP V2 and V3)
Note: For more information about IP multicast and IGMP, please consult chapter “IP multicast
behaviour”.
5.3 Connectivity on IP routers in an IP-DECT “Branch Office Configuration”
(For more info on a Branch Office configuration, consult Section ―Multiple subnets‖).
 IP Unicast Routing.
Unicast routing depends on routing mechanisms/protocols as OSPF (Open Short Path First).
Routing rules/tables in the router determine the IP connectivity between the subnets. Routers must
allow IP unicast connectivity between the network segments with IP DECT equipment. This is
applicable for Routed Head Quarter configurations as well as Branch Office configurations.
 IP Multicast Routing.
IP multicast routing is not required for IP-DECT in a Branch Office configuration.

IP-DECT will use TTL = 1 in the multicast packets, which means that these multicast packets will not
cross a router.
8AL 90880 USBA ed01 17

 IGMP (Required for Multicast Routing)
A router uses IGMP (Internet Group Management Protocol) to find out to which IP network
segments IP multicast packets should be send to. As a matter of fact, IP-DECT in a Branch Office
Configuration does not need IP multicast packet forwarding over the router to other segments.
However, if ―IGMP Snooping‖ in the IP switches is enabled, they need an IGMP Querier. So, in that
case, an IGMP Querier in the router is required, unless the IP switch has an activated IGMP Querier
on-board.
Either the router IGMP Querier is used, or the IP switch Querier. The Querier with the lowest IP
address will be activated automatically. IP-DECT uses IGMP version 2 (AP300) and IGMP version 3
(AP400).
Note: For more information about IP multicast and IGMP, please consult chapter “IP multicast
behaviour”.
5.4 Quality of Service issues
IP Routers have the following effects on the QoS:
 Routers introduce a (significant) delay, because of the store-forward technique (layer 3).
Make sure that the settings for Priority Queuing Techniques are set to minimize the delay and
maximize the throughput for IP DECT traffic.
 When the delay varies, it causes jitter as well.
The delay and jitter depends on:

- Available bandwidth
- Traffic load
- Number of routers to pass
So, ensure that the settings for Priority Queuing Techniques are set to minimize the delay and
maximize the throughput for IP DECT traffic.
Routers may use Priority Queuing Techniques, to limit the delay of time sensitive traffic.
This is normally a combination of settings in the Router and ―Differentiated Services‖ (Diffserv)
settings on the IP traffic (Layer 3).
The DAPs support Differentiated Services (QoS) on layer 3 (optional). When enabled, the default
setting is 46, but it can be changed easily.
5.5 Example of router configuration
Edge router (Ex: 172.24.190.2):
! IPMS :
ip multicast status enable

ip multicast querying enable
! The following lines below may not be necessary for networks when you do not need multicast
routing with all DAPs in one network.
! IP multicast :
ip load pim
ip pim interface <all concerned IP networks, here 172.24.190.0/24 and 172.24.191.0/24>
8AL 90880 USBA ed01 18

ip pim cbsr 172.24.190.2 priority 254

ip pim candidate-rp 172.24.190.2 239.192.49.49/32 priority 0
ip pim sparse status enable
ip pim dense status disable
ipv6 pim sparse status disable
ipv6 pim dense status disable
+conf to reach the dhcp server:

ip helper per-vlan only
ip helper address <dhcp_server> vlan <172.24.191.0-vlan>
5.5.1 Router multicast commands
To check multicast behaviour of a router you can use the following commands:
- show ip multicast
- show ip multicast group
Examples: See appendix “Troubleshooting and debugging”
6. Priority / QoS / VLAN support
The DAPs optionally support:
 Priority on Layer 2 (IEEE802.1p)
The default setting is 5, (Voice, < 10 ms latency). This setting can be set to 0 ...7.
 VLAN Tagging on Layer 2 (IEEE802.1Q)
 Differentiated Services (QoS) on layer 3.
Note: For more important information on Priority / QoS / VLAN Support, please consult chapter 4
and chapter 5 in this manual.
7. DHCP server
7.1 General
The DAPs support DHCP. The DHCP Server must provide the following data to the DAPs:
 IP Address
 Subnet Mask
 Default Gateway IP address
 Next Boot Server IP address
This is the IP Address of the TFTP Server. (In MS Windows DHCP Server option 66).
 Configuration file name
The configuration file name is dapcfg.txt by default. This field can be left empty, the DAP will request
for the default file name. However, in the Windows DHCP server, the check box for option 67 must
be checked, although you do not fill in a file name.
The Vendor class id of the DAPs is ―D(ECT)AP 49‖.
8AL 90880 USBA ed01 19

Note: Once an IP address has been issued to a DAP, it should not change anymore.
Therefore, you should use reservations for the DAP IP addresses in the DHCP Server or use an
infinite lease time for the IP addresses to the DAPs.
7.2 Recommended DHCP servers
The following DHCP servers are recommended:
- DHCP Server under Windows 2003, Windows 2008

- Linux DHCP server: dhcpd (Internet Systems Consortium, ISC)
7.3 Built-in DHCP server in DAP controller
The DAP controller software comes with a DHCP server (optional). This DHCP server should not be
used in systems other than simple systems with up to 16 DAPs.
8. TFTP server
A TFTP server is necessary to upload the configuration file (dapcfg.txt) and the DAP firmware file.
Please note that DAP firmware file is stored in flash memory in the DAPs.
Only when a change in firmware package is required, new firmware will be uploaded via TFTP.
A TFTP server for the DAPs must be capable of handling as many simultaneous accesses as the
number of DAPs in the system.
The DAP controller software comes with a built-in TFTP server (optional). This TFTP server should
not be used for systems other than simple systems with up to 16 DAPs.
9. DHCP-less / TFTP-less
The DAPs offer a possibility to store the IP configuration in flash and to store the configuration file
(dapcfg.txt) in flash memory.
A DHCP Server and TFTP server are initially required to get the data into the DAP. Once stored, the
DAPs will boot-up with the data that is stored and no DHCP or TFTP server is required anymore.
8AL 90880 USBA ed01 20

10. IP multicast behaviour
10.1 Introduction
The Alcatel-Lucent IP-DECT product is a combination of advanced technologies in both wireless

communications and networking. Wireless communications are implemented by means of proven
DECT technology, while on the networking side various IPv4 and other network technologies are
used as a supporting infrastructure for VoIP communications.
This document focuses on a specific network technology which is core to the IP-DECT product:
―IPv4 multicast‖, and its network configuration management.
10.2 RFC references
[RFC1122] Requirements for Internet Hosts - Communication Layers
[RFC4291] IP Version 6 Addressing Architecture
[RFC2236] Internet Group Management Protocol, Version 2
[RFC3376] Internet Group Management Protocol, Version 3
[RFC4541] Considerations for Internet Group Management Protocol (IGMP) and Multicast
Listener Discovery (MLD) Snooping Switches
Table 10-1: RFC references
10.3 DECT Access Point network interface
The DECT Access Point (DAP) network interface is an industry standard Ethernet interface which
can be wired to a 10/100Mbps UTP switch port, with Power-over-Ethernet.
These are the most common installations.
One or more network switches are combined to provide the backbone through which the IP-DECT
VoIP solution is provided. In many cases the DAPs are put on a specific VLAN (by means of switch
port configuration) in order to provide certain guarantees for Quality of Service and separation of
network traffic.
These techniques are primarily focused on IPv4 unicast and broadcast. The IP-DECT product also
utilizes IPv4 multicast, which is handled separately from the other traffic.
These characteristics of IPv4 multicast make that some additional planning and configuration has to
take place. Part of this is done in the configuration of the IPv4 multicast nodes (the DAPs) and some
in the involved network infrastructure.
10.4 Multicast configuration
10.4.1 General
Configuration of multicast groups depends on the scope, or reach, the multicast traffic has to have.
This is reflected in the multicast address and the Time-To-Live of the IPv4 multicast packet. Here
we give an overview of the involved parameters for the involved components.
8AL 90880 USBA ed01 21

10.4.2 DAP configuration
The IP-DECT configuration contains the definition of the IPv4 multicast address the IP-DECT
system is to use. A default of 239.192.49.49 is proposed, and usually accepted. This address is
considered to have Organization-Local scope, which means, according to [RFC4291]:
―Organization-Local scope is intended to span multiple sites belonging to a single organization.‖
Even though this is not a set rule, it most closely matches the intended scope of the IP-DECT
multicast traffic. More detailed scoping is achieved by the setting of the Time-To-Live parameter.
10.4.3 Network configuration
Many different network topologies are possible, but the most common elements are switches and
routers. When routers are deployed in the network and the multicast traffic needs to pass through
them, the routers need to be multicast aware. That means they have to know what multicast group
topology is needed to connect all members of the multicast group(s). Various different routing
technologies are defined for these purposes.
The main issue is that the router needs to know on which networks the various multicast group
members are.
For this purpose Internet Group Management Protocol (IGMP) was designed. The AP300 uses
IGMPv2 [RFC2236], while the AP400 uses IGMPv3 [RFC3376], and they act as a multicast host.
The DAP indicates that it is member of a multicast group so that the routers can take appropriate
measures to forward the multicast traffic. This group membership is indicated during startup of the
DAP and when asked for, by a ―Querier‖, elected as defined in [RFC2236] or [RFC3376].
When switches are deployed in the network they do not have the same knowledge as routers to
distribute multicast traffic to specific network ports. Unlike IPv4 unicast of broadcast, with multicast
the switches do not have the option to learn and filter on Ethernet MAC address. This results in
multicast traffic being flooded on all network ports of the switch (usually restricted to the VoIP
VLAN), so that the individual connected hosts can process the multicast packets.
With the development of more advanced switches (so called Layer 3 switches, which take
information from the Network layer (Layer 3) and use that to make decisions on the Link layer
(Layer 2)) more intelligence came into the distribution of network packets, including multicast
packets. In order to make intelligent decisions on the distribution of multicast packets the layer 3
switch listens in on the IGMP traffic and uses that information to distribute the multicast traffic on
network ports on which it knows multicast members are present. This feature is called IGMP
snooping.
10.5 The IGMP snooping problem
IGMP snooping in itself is a valuable technique to limit and shape (multicast) network traffic. But
since it’s a technique based upon eavesdropping on other protocols one must make sure that the
whole IGMP infrastructure is there. Also when the topology changes (e.g. changes in spanning tree,
due to switch maintenance) the network administrator must make sure IGMP information remains
consistent. These issues are fully described in [RFC4541].
The DAPs act as multicast host, the network has to provide for a node that performs the Querier
function, otherwise no IGMP traffic will be generated besides on host startup. In a full multicast
routed network this function is performed by the multicast aware router (see above), but many
networks do not contain such router since there is usually no need for it.
The result is that the Querier function is also not performed.
8AL 90880 USBA ed01 22

The absence of the Querier function, hence absence of regular IGMP traffic, makes it difficult for the
IGMP snooping layer 3 switches to determine where the multicast hosts are. Even though they may
know locally which of the switch ports are connected to multicast hosts, for the uplink connections
this is usually not known.
Experience tells us that unless IGMP snooping is disabled multicast problems frequently occur, due
to incorrect configuration of the network.
10.6 The IGMP snooping solution
From the problem description above a few solutions become apparent.
By far the simplest solution, and most implemented, is to switch off IGMP snooping in the Layer 3
switches for the VoIP VLAN. Even though this causes multicast traffic to reach ports which are not
connected to multicast group members (e.g. other parties on the VoIP VLAN) this is usually not an
issue.
When IGMP snooping cannot be switched off the network administrator has to assure the Querier
function is implemented at the correct location in the network. This has to be done in such a way
that all the involved IGMP snooping Layer 3 switches converge their multicast groups so that the
multicast group members in all locations of the network can communicate via multicast. This has to
be assured across changes in the topology of the network.
The way in which this is done completely depends on the capabilities of the IGMP snooping Layer 3
switch and the network topology. Some switches can act as Querier, others have to be statically
configured.
Note: See appendix “Multicast / IGMP” for more detailed information
10.7 Multicast host behaviour of a DAP
To illustrate the behaviour of a DECT Access Point as multicast host a network capture is made of
the traffic on its network interface. A textual representation of this traffic is added below.
First the DAP is powered up, after which the boot program retrieves update information through
DHCP and TFTP (frames 2-10). Then the Firmware is started which reinitializes the network stack,
retrieves provisioning information through DHCP and TFTP (frames 13-22), after which it opens the
multicast port.
Note: Other paragraph to add for AP400.
The opening of the multicast port is followed by joining the multicast group, hence initiates sending
of unsolicited IGMP join messages (frame 23 and 26). This fulfills the first multicast host
requirement.
Next a General Query is sent from the Querier (frame 40), to which the DAP responds with its
multicast group membership report (frame 41). This fulfills the second multicast
host requirement.
These are the two behaviours a multicast host has to show when joined in a group.
8AL 90880 USBA ed01 23

10.8 Multicast
The IP multicast is required for switches and routers
 At the level 2,
o Data equipment must be compatible with IGMP v2,
o The Spanning Tree Protocol (STP) must be disabled on the ports used for DAPs, or
have STP PortFast enabled, or configured as RSTP edge port.
o Switches must support IP multicast, with IGMP (snooping) disabled or a proper IGMP
network setup.
o It is strongly recommended to set the switch port in ―Fast Forwarding‖ mode,
 At the level 3, ALE recommends using the PIM SM protocol (or the PIM DM protocol).
The router(s) must support IP multicast packet forwarding to all subnets where multicast packets for
the IP DECT multicast group are required. IP multicast routing between routers depends on routing
mechanisms/protocols. The most commonly used routing mechanism is PIM-SM.
The choice of a routing mechanism/protocol depends on the customers IT department. No matter
what protocol is chosen, in general, the IP Network over the router must be transparent for IP
multicast to allow DAP to DAP multicast over the router(s).
Note: The PIM Dense Mode protocol is a multicast routing protocol that uses the underlying unicast
routing information base to flood multicast datagrams to all multicast routers. Prune messages are
used to prevent future messages from propagating to routers without group membership
information.
The PIM-Sparse Mode protocol is a multicast routing protocol that can use the underlying unicast
routing information base or a separate multicast- capable routing information base. It builds
unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates
shortest-path trees per source.
ALE recommends using the PIM Sparse Mode or PIM Dense Mode protocol.
Nevertheless the tree creation takes more time in the PIM Sparse Mode protocol, when several
DAPs (DECT Access Points) reset at the same time.
Spanning Tree Protocol (STP) and PortFast: The time

that Spanning Tree Protocol (STP) takes to transition ports over to the Forwarding state can cause problems.
PortFast is a network function which can be configured to resolve this problem. This factor of time is not an
issue for many people, but it can cause problems for some. PortFast is the solution to this problem of delays
when client computers are connecting to switches. PortFast is not enabled by default. With PortFast enabled
on a port, you effectively take the port and tell spanning tree not to implement STP on that port.
8AL 90880 USBA ed01 24

10.9 Multicast “ping” test mechanism
10.9.1 Working of the multicast ping test mechanism
The Ping Test mechanism works as follows:
About every 65 minutes, the DAP Controller (DDS Service) issues a multicast packet onto the
network. The DAPs receive this packet and will transmit 6 multicast packets.
All DAPs listen to other DAPs to see if they receive 6 times a multicast packet from other DAPs.
Please note that a ―ping test‖ is not based on the commonly known type of Ping, the ICMP ping, but
base on multicast packets.
Example:
―Pingtest problem detected by 022:6, 011:-6, 012:-6, 013:-6 etc…‖
In the line above, you see that RPN 022 transmits the multicast package 6 times (022:6). The first
RPN in the line is the transmitter.
You also see that RPN 011 did not receive the packets from 022 (011:-6).
Also RPN 012 did not receive the packets (012:-6,) etc...
When there is an indication like 014:3, it indicates that RPN014 has received the packet, 3 times too
much. So this gives a reliable indication about the network behavior and multicast problems.
It is important that the network is transparent for IP multicast and that there are no loop(s)! (duplicate
data)
As long as the system shows Ping Test failures, there are multicast problems in the network.
After the DAP Controller has started a ping test, it will get the results back from the DAPs.
However, if the DAP does not receive result data back from one or more DAPs, the DAP Controller
will issue an unicast to the DAPs that did not send the results back.
Note that ping test is not a real ICMP ping test but a multicast test. It works as follows:
• The DAP Controller PC commands the DAPs to start the ping test
• The DAPs will respond by sending a multicast packet to the IP DECT multicast address. This
response is done with a variable time interval to avoid congestion.
• The response packets are normally sent in bursts of 2 and with an interval of a couple of seconds.
• The protocol in the packets is proprietary.
• All DAPs collect data about the received multicast packets from the other DAPS.
• After a specified time period, the DAP Controller sends a packet with a request to the DAPs to
send the reports of the received multicast packets.
• The results are available in the system ―Archive‖ and can be analyzed using the DECT
Performance Analyzer.
8AL 90880 USBA ed01 25

Note about multicast packets:
6 multicast packets at t0:
- First packet: t0
- Second packet: t0 + 0.3 s
- Third packet: t0 + 17 s
- Fourth packet: t0 + 17.3 s
- Fifth packet: t0 + 34 s
- Sixth packet: t0 + 34.3 s
6 multicast packets at t1: t1≈ t0 + 01:06:10
- First packet: t1
6 multicast packets about every 66 minutes.
Remark: Congestion time depends on RPN numbers. Starting time is different per DAP.
The commands to the DAPs from the DAP controller are not necessarily sent via multicasting. That
depends on whether the DAP controller is in the same subnet or not.
The focus is about DAPs sending and receiving multicast test messages.
All DAPs should send 6 messages via multicasting and receive 6 multicast messages from all other
DAPs. Any failures are reported, i.e. when the number of sent packets is not the same as the
number of received packets.
Note: A wireshark trace, where we can see more detailed information about the multicast
sequences between DAP Controller and DAPs and between DAPs together, is not provided as
template because the protocol is not ALE proprietary and is also subject to changes over SW
releases.
Most of the time the problem is not linked to the multicast ping test protocol.
The majority of multicast field problems are caused by not understanding how to setup the IGMP
querier function.
In some situation it can also be caused by queues in routers and switches that are not large enough.
As an exception some information about the relevant messages:

The relevant test messages that are sent and thus should also be received at each DAP are UDP
messages to port 3000 and start with 43 46 03 09 (in hex)
8AL 90880 USBA ed01 26

10.9.2 Examples of ping error files
10.9.2.1 Example of a “Ping_errors_0.txt” file
Note: The file “Ping_errors_0.txt” is written in archive
192.168.3.0 /24
Pingtest problem detected by 011:6,010:-6,012:-6,013:-6,014:-6,015:-6,016:-6,017:-6

Pingtest problem detected by 016:6,011:4,012:-6,014:-1,015:-1
Pingtest problem detected by 010:6,011:4,012:-6,014:-1,015:-1,016:-1
Pingtest problem detected by 012:6,010:11,011:18,013:3,014:11,015:10,016:6,017:9
Ping test ready, with 8 problems counted
- Explanation of a line of the “Ping_errors_0.txt” file
This means 013 sent 6 messages

It received 4 messages too many from 011
It received 6 messages too few from 012
It received 1 message too few from 014
So after the first comma, it is only indicated the number of messages that are too few (negative) or
too many (positive) from a DAP.
Note that ―too many‖ should not occur at all in a healthy system.
If occasionally (a few times per day) there is one message too few received, that would not be
blocking.
10.9.2.2 Example of a “PingError.txt” file
File obtained with the ―Performance manager interface → View multicast problem(s)‖.
Timestamp : 04/30/2013 15:47:37
Subnet : 155.132.29.128 /25
Details : Pingtest problem detected by 010:6,033:-1
Details : Pingtest problem detected by 02E:6,033:-1
8AL 90880 USBA ed01 27


Details : Pingtest problem detected by 019:6,014:-1,01B:-1,020:-1,021:-2,023:-1,030:-1,031:-
1,033:-1
Details : Pingtest problem detected by 01E:6,033:-1
Details : Ping test ready, with 15 problems counted
Remark: See appendix “Wireshark example of a multicast “ping” from a DAP” for additional
information
10.9.3 Ports used for multicast
The packets from port 28000 are from the DAP controller that starts the testing and collects the
results at the end.
These test runs are normally about every 66 minutes, but in case of failure the next starts already 5
minutes after previous run.
If the DAP controller is not in the same subnet as the DAPs you won’t see the messages we were
referring to. These go to port 3000.
10.9.4 Multicast in the “Performance manager interface”
The performance manager interface just shows that the last test run failed.
Then a next test run is scheduled after 5 minutes. As soon as a test run is ok, then the ―Multicast
problem(s) detected‖ red message disappears (see pictures given hereafter).
Figure 6: Performance interface manager with multicast issue
8AL 90880 USBA ed01 28

Figure 7: Performance interface manager without multicast issue
10.9.5 Multicast in the “DAP viewer” debug tool
The ―DAP viewer‖ debug tool is not recommended for verifying multicast problems.
Remark: The DAP viewer is an intrusive debug tool.
Note: See appendix “Troubleshooting and debugging” for additional information
8AL 90880 USBA ed01 29

11. Troubleshooting and debugging

The following debug tools show detailed information about the complete IP-DECT system, and can
therefore be used for troubleshooting as well as for performance analysis.
11.1 Debug tool: DAP viewer

License to be created every day with OneDayLicense.exe
The DAP Viewer is a tool that displays operational data of the DAPs. This operational data covers IP
networking data as well as detailed DAP data.
Note that the DAP Viewer is licensed! The license string is valid for one day only, based on the date
of the day! It cannot be used on another date! When you issue a request for a license string, make
sure to mention the date on which you want to use it!
Note: This chapter tells you how to start using the DAP Viewer but does not explain all the menu
options and windows. Using the DAP Viewer requires that you have detailed knowledge of the
architecture and operation of your IP DECT system. By means of this knowledge you should be able
to interpret the menus and the windows in the DAP Viewer.
* Getting Started with the DAP Viewer
PROCEDURE: Getting started with the DAP Viewer
Actions
1. Start the DAP Viewer tool, via Start, All programs, DAP Controller, DAP Applications, DAP
Viewer.
2. A window is displayed, where you must enter the license string. Enter the license string that is
valid for this day.
3. A window is displayed:
Click the top left icon.
4. A window is displayed:
Select the ―location of the configuration files‖. If you select ―Local‖ the default directory for the
configuration files is used: C:\Documents and Settings\All Users\Application Data\Philips\DAP
Controller\3.0.
Click the button ―Load Files‖.
5. In the bottom left pane, the available RPNs are displayed. Select the RPNs that you want to
monitor, and click ―Add‖ to move them to the pane ―RPNs in View‖.
6. A window is displayed.
In this RPN overview, you see overall data of the DAPs. To view detailed data, you must select
a DAP or select all DAPs. When a DAP is selected, there is a blue line displayed under the RPN
icon (see screen capture above.).
8AL 90880 USBA ed01 30

When you right mouse click an RPN, you will see a menu displayed: Select the DAPs (RPNs)
for which you want to display detailed information.
7. Now you can use the buttons in the tool bar in the top, to display detailed data.
Click the button that shows you the information that you need. The following overview gives
information about the functions of the buttons.
- Open configuration files
This allows you to import the configuration files (and data files) into the DAP Viewer.
Note that if a change is made (automatically) in one of the files (e.g. a new subscription), this is
detected and the DAP Viewer asks you if you want to use the new file contents.
- Change settings
Here you can change the RPN Monitoring interval. This is the interval between polling a DAP to
retrieve data from it. There is also a possibility to set alarm levels. If an alarm occurs, the bottom bar
in the DAP Viewer gets red and shows the message ―alarm‖.
Note that the E-mail function is not enabled in this configuration!
- Change services status
This allows you to stop/start the DAP Controller services.
- Show RPN data
This window shows you detailed data of the selected RPN/RPNs. Note that you see an
overview of the occupied timeslots on the selected DAP/DAPs. You can change the view from IPUI
to DNR by means of a check box.
- Start or stop the monitoring
Monitoring is done based on a polling mechanism. Based on this polling, DAPs sends their
data to the DAP Viewer. You can stop this polling via the ―Start or stop the monitoring‖.
- Start or stop tracing
This is used for third line tracing. For first line and second line maintenance, this tracing is not
useful because it is hard to interpret. (Use Diag@Net instead.) Note that this option does not
generate trace files. It only sends tracing data to a (dummy) destination, which is an IP socket. The
actual tracing must be done by means of monitoring this (dummy) IP socket using a sniffer (like
Ethereal).
- Show registrations
This button offers you the possibility to show the registrations (subscriptions) on a DAP in
Distributed mode. A nice overview of the subscribed numbers per DAP is available. Also you can
search a subscribed number on the DAPs.
8AL 90880 USBA ed01 31

- Location detection
This allows you to trace the subscription number-DAP relation for an active call. You can enter
the subscription number, and then a coloured block on the DAP icon is shown, when a call is active.
- Show alarms
This shows you a history log.
11.1.1 Summary to use the Dap Viewer

You need a license
Launch : OneDayLicense.exe
Figure 8: OneDayLicense
Launch DapViewer.exe
Figure 9: Launching of the DAP Viewer
8AL 90880 USBA ed01 32

Figure 10: DAP Viewer (Step 1)
Choose Open Configuration Files, Load Files, Add all and enter the password:
8AL 90880 USBA ed01 33

Type OK and the status of DAPs is shown on screen
Remark: You should have only one master (red square) if all the DAPs are air synchronized.
In the above picture there are 3 masters so air synchronization and network (multicast issues can
generate such behaviour) have to be checked.
To solve air synchronization issues see “DECT and IP-DECT Engineering Rules and Site Survey Kit
Manual” document.
8AL 90880 USBA ed01 34

Figure 13: DAP Viewer is OK

DAP viewer is OK (one master only with the lowest RPN) in the picture above (Simple configuration
with 3 DAPs).
11.2 Debug tool: DECT performance Analyzer

This tool shows detailed information about the complete IP-DECT system, and can therefore be
used for Performance Analysis as well as for Trouble Shooting.
The DECT Performance Analyzer must be installed separately.
PROCEDURE: Installing DECT Performance Analyzer
Actions
1. Get the DECT Performance Analyzer software (DECTPerfAnalyzer-1_30_0061-ALU.zip

directory)
2. In the install package, navigate to DISK1.
3. Run setup.exe in the subdirectory DISK1.
4. The installation is very straight forward. You are guided through the installation. Follow the
instructions on the screen.
5. When the installation is completed, you will find two menu items under: Start, All Programs,
DECT Performance Analyzer.
PROCEDURE: Starting the DECT Performance Analyzer
8AL 90880 USBA ed01 35

Actions
1. To start the Performance Analyzer, use the following program item:
2. Note that there are two program items: ―DECT Performance Analyzer‖ and ―DECT
Performance Analyser Help‖. Click DECT Performance Analyzer to start the program.
3. The DECT Performance Analyzer has various analysis levels. Analysis levels can be entered
by means of a License key. If you do not have a key, you will have level ―0‖. If you have a key for a
higher level, enter the key via menu Help followed by Register.
Help -> register -> Serial Number
4. You can import various types of Performance data files. Go to menu File, Import. Select the file
type that you want to enter: ―DECT Archive‖, EPM/UPM File(s), DECT Folder.
When you import an Archive file (archive.zip) you will see the maximum of performance data.
Note: For more information on the DECT Performance Analyzer, click the ―DECT Performance
Analyzer Help‖ program item.
Available reports:
- Full Report
- Sanity Report
- Problem Report
11.2.1 Summary to use the DECT performance analyzer

To start Dect Performance Analyzer, use the icon on your desktop and once the screen is open, do :
File -> Import -> DECT Archive
Figure 14: DECT Performance analyzer (Step 1)
8AL 90880 USBA ed01 36

Select a zip file
Run the application
8AL 90880 USBA ed01 37

Read the available reports
11.2.2 Features of the DECT performance analyzer
DECTPerfAnalyzer-1_30_0061-ALU has the following features:
- IP-DECT installation: It covers the analysis of most common installation-related issues.

- DECT configuration: It covers the analysis of the overall DECT configuration.
- DECT quality: It covers the analysis of the DECT quality.
- IP quality: It covers the analysis of the IP quality.
- PBX configuration: It covers analysis of the PBX (OXE) configuration and DECT registration
issues.
8AL 90880 USBA ed01 38

Figure 18: DECT Performance analyzer (Reports)
11.2.2.1 Useful information
DAP Channel occupation:

Full Report → DECT Quality → DAP Channel Ranking
Synchronization
Full Report → DECT Quality → Synchronization
Full Report → DECT Quality → Clusters
Ping test failures

Full Report → IP Quality → Ping Test Failures
Problem Report → IP Quality → Excessive ping test failures
Packet loss
Problem Report → IP Quality → List of calls with packet loss
Dropped Call Problems

Full Report → DECt quality → Calls → Call Details
Reports → Sanity Report → DECT Quality → Calls
DNR Registration problems

Full Report → PBX Configuration → DNRs
8AL 90880 USBA ed01 39

11.2.2.2 DAP Channel Occupation - Channel Ranking
Figure 19: DECT Performance analyzer (Channel occupation / Channel ranking)
The ―Occupation grade‖ is the number of seconds that channels were occupied.
The value is calculated as follows:
(Seconds that a maximum number of channels were occupied x 10000) + (Seconds that maximum -
1 channels were occupied x 100) + (Seconds that maximum -2 channels were occupied).
11.2.2.3 Synchronization
Figure 20: DECT Performance analyzer (Synchronization)
8AL 90880 USBA ed01 40

- Synch/Day: It may happen and normally it does not give problems.
It means that a DAP switched from one DAP to another for listening. As the DAP remains
synchronized, it will normally not give problems.
- Align/day: This means that a DAP was not aligned anymore with other DAPs. One align per day is
acceptable. When the number of aligns per day is higher than 3, you must check the
synchronization structure and the IP multicast network behaviour.
11.2.2.4 Multicast ping tests
Figure 21a: DECT Performance analyzer (Multicast ping tests)
Figure 21b: DECT Performance analyzer (Multicast ping tests)
- Each 65 minutes the IP-DECT system performs a multicast test. It is called ―Ping test‖, but it is not
an ICMP ping.
- The multicast ping test means that ALL DAPs will send 6 multicast packets (of course, spread over
the time, to avoid flooding).
8AL 90880 USBA ed01 41

- All DAPs listen to the network for multicast packets from other DAPs. They keep track of the
received packets from all other DAPs.
- After the multicast ping test is finished, the DAP controller gets the status of the received multicast
ping tests from other DAPs.
- This means that the DAP Controller has a total overview of how many multicast ping packets has
been received on one DAP from all other DAPs.
- When there are no problem(s) detected on a DAP, there is no notification in the Performance
Analyzer report. However when packets were lost or duplicated (six sent but less than six received,
or more than six received), it is shown in the Performance Analyzer.
Note: See the next sections for more detailed information.
- There is a difference between the reporting of the multicast ping tests between DAP firmware
before release 6.00.100 and DAP firmware release 6.00.100 and higher. For the firmware release
6.00.100 and higher you should have the latest Performance Analyzer: 1.30.0062 or higher.
11.2.2.4.1 Ping Test Failures / Release < 6.00.100

- Sending the multicast packets.
Please note that you will only see the DAPs which have sent packets, when there were problems
receiving the packets by other DAPs.
Figure 22a: DECT Performance analyzer (Ping test failures)
- Failures receiving the multicast ping packets.
Example 1:
8AL 90880 USBA ed01 42

Figure 22b: DECT Performance analyzer (Ping test failures)
Example 2:
Figure 22c: DECT Performance analyzer (Ping test failures)
8AL 90880 USBA ed01 43

11.2.2.5 Ping Test Failures / Release ≥ 6.00.100

- In release 6.00.100 and higher, the ping test failure detection mechanism has been improved.
This is explained hereafter.
Figure 23a: DECT Performance analyzer (Ping test failures / Release ≥ 6.00.100)
- Ping test reporting
Figure 23b: DECT Performance analyzer (Ping test failures / Release ≥ 6.00.100)
For explanation, see information given hereafter.
- In release 6, the ping test failure detection mechanism has been improved.
How to read the ping results?
8AL 90880 USBA ed01 44

Figure 23c: DECT Performance analyzer (Ping test failures / Release ≥ 6.00.100)
Note: If the ping test failure detection mechanism shows that the first ping packets are not received
successfully, it is maybe due to a “source learning” issue at the switch level.
- In release 6, the ping test failure detection mechanism has been improved.
How to read the multicast ping delay results?
Figure 23d: DECT Performance analyzer (Ping test failures / Release ≥ 6.00.100)
8AL 90880 USBA ed01 45

11.2.2.6 Dropped Call Problems

Note that dropped call may happen because it is radio communication !
- Active Calls = Call having a voice connection
- Passive Calls = Call in ringing phase
- Page Failures = Handset was paged, but didn’t respond, after a number of page retries
- Page retry = The handset was paged, but didn’t respond. The page action is retried.
Figure 24: DECT Performance analyzer (Dropped call problems)
Note that dropped calls may happen because it is radio communication!
- Maximum acceptable Active Dropped Call ratio = 0,5 %
- Maximum acceptable Passive Dropped Call ratio = 3 times the actual Active Dropped call ratio.
8AL 90880 USBA ed01 46

11.2.2.7 DNR registration

- Note that the registration state is not (always) reliable when using SIP! There is no feed back from
the SIP Proxy to indicate the registration status.
- Shared means: Logged in via portable sharing.
Figure 25: DECT Performance analyzer (DNR registration)
8AL 90880 USBA ed01 47

11.2.2.8 Settings
Figure 26: DECT Performance analyzer (Settings)
11.3 Debug tool: Performance Manager interface

To open the Performance Manager interface, use URL: http://localhost/CDS/PerfFormMan.aspx
The term Performance Manager (not Analyzer!) is a web page in the IP-DECT system. It offers
some performance data retrieval options.
The phase difference between DAPs is given and must be ffff with a maximum deviation of 7.
11.3.1 Summary to use the Performance manager interface

To start Dect Performance Manager, type in an IE window the command:
http://localhost/CDS/PerfForm.aspx
8AL 90880 USBA ed01 48

Figure 27a: DECT Performance Manager (Step 1)
Note: Synchronize subscription data
Subscription data is stored in the sm.xml file. The subscription data that is visible in the DECT
Manager window is stored in the CDSdata.xml file. If there is inconsistency between the two files,
use this menu option to make the files consistent. Missing subscription records in the CDSdata.xml
file will be copied from the sm.xml to the CDSdata.xml file.
Select Update visibility and Get visibility file to see the status of the sync clock
8AL 90880 USBA ed01 49

Figure 27b: DECT Performance Manager (Step 2)
11.4 Debug tool: IP-DECT web page of a DAP
For instance, if DAP (with RPN=046) IP address is 172.25.12.20, type in the navigator the following
URL: http:// 172.25.12.20
8AL 90880 USBA ed01 50

Figure 28a: IP-DECT Web page of a DAP
Figure 28b: IP-DECT Web page of a DAP. Network status.
Number of visible DAPs: For instance (see picture above), there are 3 visible DAPs for DAP 046.
8AL 90880 USBA ed01 51

Note: Visibility Information
Shows an overview of the RSSI values. “Sees” means that the selected DAP sees the other
DAPs with a certain signal strength. “Seen” means that the other DAPs can see the signal
strength of the selected DAP. Note that although the radio signal connection is reciprocal
there can be differences in the “seen” and “sees” RSSI value. This difference is caused by
the fact that this visibility information is based on a snapshot.
Remark: If you click the “Ping GK” button, the gatekeepers will be pinged. Please pay attention that ping takes
1 second for each gatekeeper
11.5 Supportive tools
11.5.1 Diag@Net Monitor
To establish diagnostics, do:
Start -> Programs -> DAP Controller -> Supportive Tools -> Diag@Net Monitor
Figure 29: Diag@Net Monitor
11.5.2 System Info Console
To see System Info Console, do:
Start -> Programs -> DAP Controller -> Supportive Tools -> System Info Console
8AL 90880 USBA ed01 52

Note: “Duplicate Data Received” error
When you see this information: “Duplicate Data Received”, it means that the DAPs has sent the
results back to the DAP Controller, but the DAP Controller didn’t receive it and the DAP Controller
issue an unicast request. Then the DAP Controller did receive the multicast (but too late!) and also
received a response on the unicast, so duplicate data.
This indication “Duplicate data received” indicates that there is a high delay (on multicast) in the
network.
So this indicates also network problems. How are the priority settings in the switches, how are the
buffer settings in the network components (Switches etc…)?
Do the switches have a kind of logging, which can give more information?
It is important to check the network accurately (Switch settings etc...)!
These “duplicate data received” messages indicate multicast loop(s) in the network (probably
between IP Switches).
It does not say anything about unicast loops in the network.
Anyway, it indicates a network problem, and although this should normally not give problems on the
voice quality, these problems should be solved first.
Take care that there are no unicast loops in the network (that will cause voice problems).
11.6 Router multicast commands
To check multicast behaviour of a router you can use the following commands:
- show ip multicast
- show ip multicast group
See examples given hereafter:
router1> show ip multicast
Status = enabled,
Querying = enabled,
Proxying = disabled,
Spoofing = disabled,
Zapping = disabled,
Querier Forwarding = disabled,
Flood Unknown = disabled,
Version = 2,
Robustness = 2,
Query Interval (seconds)
Query Interval (seconds) = 125,

Query Response Interval (tenths of seconds) = 100,
Last Member Query Interval (tenths of seconds) = 10,
Unsolicited Report Interval (seconds) = 1,
8AL 90880 USBA ed01 53

Router Timeout (seconds) = 90,

Source Timeout (seconds) = 30,
Max-group = 0,
Max-group action = none
Helper-address = 0.0.0.0
router1> show ip multicast group
Total 1 Groups
Group Address Source Address VLAN Port Mode Static Count Life RVLAN
---------------+---------------+-----+-----+--------+-------+------+-----+------
239.192.49.42 0.0.0.0 429 1/27 exclude no 264 172 -
router2> show ip multicast
Status = enabled,
Querying = enabled,
Proxying = disabled,
Spoofing = disabled,
Zapping = disabled,
Querier Forwarding = disabled,
Flood Unknown = disabled,
Version = 2,
Robustness = 2,
Query Interval (seconds)
Query Interval (seconds) = 125,

Query Response Interval (tenths of seconds) = 100,
Last Member Query Interval (tenths of seconds) = 10,
Unsolicited Report Interval (seconds) = 1,
Router Timeout (seconds) = 90,
Source Timeout (seconds) = 30,
Max-group = 0,
Max-group action = none
Helper-address = 0.0.0.0
router2> show ip multicast group
Total 2 Groups
Group Address Source Address VLAN Port Mode Static Count Life RVLAN
---------------+---------------+-----+-----+--------+-------+------+-----+------
239.192.49.42 0.0.0.0 430 1/25 exclude no 200 207 -
239.192.49.42 0.0.0.0 430 1/26 exclude no 299 205 -
8AL 90880 USBA ed01 54

11.7 How to solve multicast issue on a PC

It you use applications generating multicast messages (such as DAP configurator in certain network
configurations) it is necessary be on a PC that is able to send multicast messages.
To see if your PC is able to send multicast messages you can test it, in a first time, with an
application such as MultiCastor that is able to send and receive multicast data steams.
Note: MultiCastor is an open source tool very handy to create and monitor multicast flows.
In case of troubleshooting check the configuration of the antivirus.
Example if you use McAfee antivirus:
On network card (network connections) disable:

McAfee NDIS intermediate Filter‖
―Network Monitoring Driver‖
Note: It is not necessary to disable IPSec Client
"Network Monitoring Driver" is a Netmon packet capture driver that allows the Network Monitor user
interface to make the acquisition of packets from the local network.
Restart the PC
(Launch: cmd -> services.msc)
Stop the following McAfee service: McAfee Host Intrusion Prevention Service
Note: It is not possible to stop the following service: McAfee Validation Trust protection Service
It is normally not necessary to stop the following McAfee services:

McAfee Engine Service
McAfee Framework Service
McAfee HIPSCore Service
McAfee McShield
McAfee Task Manager
Note: McAfee Host Intrusion Prevention Service

Host-based intrusion prevention component that blocks exploits and hacks in real-time, including
malicious buffer overflow code execution and privilege escalations.
If this service is disabled or stopped, the system is no longer protected against intrusions.
The path for this service is: "C:\Program Files\McAfee\Host Intrusion Prevention\FireSvc.exe"
To have this service always stopped change the properties of the service as follows:
Start: Manual (instead of automatic)
Remark: It is recommended to deactivate "Wireless network connection".
8AL 90880 USBA ed01 55

Figure 30: McAfee_services
Figure 31a: Network card
Figure 31b: Network card (Cont’d)
8AL 90880 USBA ed01 56

11.8 How to see the host name used in DHCP option 12 with wireshark
Look at DHCP request with wireshark that should be connected to USB with an Ethernet adapter
in order to see the host name used in DHCP option 12.
Note: It is requested that the IP-DECT Access Points (DAPs) use DHCP option 12 (Host name).
This request is based on the OBS network management policy requesting a single central DHCP
server associating hostname with IP address and they are unwilling to use the specific DHCP option
43 for IPDECT devices alone.
We expect to have a hostname conforming to the following format:

"manufacturer-model-mac",
where mac is the equipment MAC address without punctuation, eg. "aabbccddeeff".
Complete examples:
"nec-ap400-aabbccddeeff"
"nec-ap400e-aabbccddeeff"
"nec-ap500-aabbccddeeff"
The model name is derived from the hardware version.
The APs with SMA connectors should be distinguished from APs with internal antennas by the suffix
"e" if the SW is able to distinguish the two hardware variants.
Allowed characters: [0-9][a-z][-]

Name must not start with a digit and should be in all-lowercase. It is a continuous set of characters
without interior spaces.
Option 12 should be present both on first and second DHCP requests.
(Request from boot loader as well as request from application)
References:
See RFC 2132 - DHCP Options and BOOTP Vendor Extensions
See RFC 1035 (DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION) for character set
restrictions.
11.9 How to calculate the aggregated subnet mask
The ―Agg. subnet mask‖ is the subnet mask for the DAPs to determine the network boundaries for
an IP-DECT Network in which seamless handover is possible. It should cover the network segments
that are connected together using routers that supports IP Multicast. If there are DAPs outside this
Aggregated Subnet Mask, the DAP(s) is/are regarded as in a Branch Office. If the IP addresses are
in the same Aggregated Subnet, according to this mask, the system assumes that they are in the
same subnet. The term ―Aggregated‖ means that the subnet consists of smaller subnets which are
connected over a router, but according to the subnet mask, all behaving as one subnet. This is
applicable for the ―Routed Head Quarter‖ network solution either with or without Branch Offices.
- Routed Head Quarter configuration:

Note that the aggregated subnet mask is the subnet mask that includes all the sub-networks in the
Routed Head Quarter.
So, this is NOT the IP subnet mask of the IP segments. Do not mix up the aggregated subnet mask
and the normal IP subnet mask.
Ex: Consider 3 subnets:

192.168.1.0 /24 11000000.10101000.00000001.00000000
192.168.2.0 /24 11000000.10101000.00000010.00000000
192.168.3.0 /24 11000000.10101000.00000011.00000000
11111111.11111111.11111100.00000000 => Aggregated subnet mask: /22
e.g. 255.255.252.0
8AL 90880 USBA ed01 57

- Routed Head Quarter configuration with Branch Office(s):

In the IP DECT configuration, you must define which subnets are in the Routed Head Quarter and
which subnet(s) is/are Branch Office subnet(s).
You must do that by means of specifying the aggregated subnet mask that is needed to cover all
Routed Head Quarter sub-networks.
Also in the Routed Branch Office, you must calculate the aggregated subnet mask that covers all
subnets in the Routed Branch Office.
11.10 Move subscriptions of non operational DAP and absent DAP threshold
- Move subscriptions non operational DAP after
When a DAP is down and the DAP Controller is up- and-running the subscription records from that
DAP will be moved to other DAPs. The time interval can be specified in the DAP configurator.
- Absent DAP threshold
When the number of absent DAPs is more than 2 at the same time, the subscription data will NOT
be moved to other DAPs.
Please note that this is a fixed system parameter and cannot be changed.
Note: When you replace a DAP be aware that it may contain subscription data. Therefore, you need
to open the DAP Manager WEB interface and execute a delete DAP. Then the subscription data that
was in this DAP is put into the remaining DAPs. If you put a new DAP in place, initially it will not
contain subscription data. Only after executing a subscription procedure, it may contain subscription
data.
When more than 2 DAPs are down (for instance a switch with more than 2 DAPs is out of service)
note that the time to change DAPs is lower than the time interval specified (for instance 10 minutes).
Most of the time it will take more than the specified time interval so in order to recover the handsets
registered on the DAPs that are down delete them from the DAP manager and reboot the DAP
manager.
When more than 2 DAPs are removed (once and for all or for service), you have to delete the
removed DAPs from the DAP manager and to reboot the DAP manager in order to recover the
handsets registered on the removed DAPs.
Note: See “IP-DECT CE manual for SIP connectivity” document for more detailed information.
8AL 90880 USBA ed01 58

12. Appendix 1: IP multicast technology overview
Note: Types of transport:

- Multicast: Point-to-multipoint, able to cross routers.
- Broadcast: Point-to-multipoint but limited to the broadcast domain.
- Unicast: Point-to-point, able to cross routers.
12.1 Concept of IP multicast group
Figure A1: Concept of IP multicast group
12.2 Multicast / IGMP
12.2.1 IGMP v2
Note: For more detailed information see RFC2236 given in appendix “RFC2236 (IGMP v2)”.
Request to a specific group: A router checks the latest receiver interested in a group has left the
group before stopping sending its data on a subnet.
Message to explicitly leave a group: A station sends a message if it leaves the group (reduced
latency time of disappearance of a group compared to IGMPv1).
Note: DAP does not send a leave group message. It is not applicable for IP-DECT.
Election mechanism querier router: On multi-access networks, a querier IGMP router is elected on
the basis of the lowest IP address. Only the querier router sends requests
8AL 90880 USBA ed01 59

Figure A2: IGMP v2: Join a group

IGMP state in router 1 (rt1)
rt1> show ip multicast group
IGMP Connected group membership
Group Address Interface Uptime Expires Last Reporter

--------------------+---------------+-----------+---------------+---------------------+
239.192.49.42 Ethernet0 5d14h 00:02:29 155.192.29.212
Last reporter is only displayed
Figure A3: IGMP v2: Election of the querier router
8AL 90880 USBA ed01 60

Figure A4: IGMP v2: Maintain a group
Figure A5: IGMP v2: Leave a group (Not applicable for IP-DECT)
IGMP state in rt1 after DAP ―155.192.29.212” left the group

--------------------+---------------+-----------+---------------+---------------------+
239.192.49.42 Ethernet0 5d14h 00:01:44 155.192.29.213
8AL 90880 USBA ed01 61

Figure A6: IGMP v2: Last member leaves a group (Not applicable for IP-DECT)
IGMP state in rt1 after the last DAP ―155.192.29.213” left the group

--------------------+---------------+-----------+---------------+---------------------+
12.2.1.1 IGMP Messages

Here is the list of IGMP messages as well as their destination address.
G represents the address of the group concerned (Ex: G = 239.192.49.42)
IGMP version Message Type Destination address
2 Request 0x11 224.0.0.1
2 Request G 0x11 G
2 Report 0x16 G
2 Leave 0x17 224.0.0.2
Table A1: IGMP messages
Example of wireshark IGMP messages:
Router IP address: 155.132.29.209
DAP IP address: 155.132.29.213
Multicast address: 239.192.49.42
8AL 90880 USBA ed01 62

Figures A7- A8 - A9: Wireshark IGMP messages
Note: Figures A8 - A9 are given hereafter
8AL 90880 USBA ed01 63

8AL 90880 USBA ed01 64

Figure A10: Wireshark IGMP messages (Leave Group for a member that is not a DAP)
12.2.1.2 IGMP snooping
The disadvantage with a switch without multicast control is the flooding of multicast frames.
Some switches treat multicast traffic as unknown or as broadcast and sends the frames on all ports.
Stations (as DAPs) not concerned receive multicast streams.
Even though ―to switch off IGMP snooping‖ causes multicast traffic to reach ports which are not
connected to multicast group members, this is usually not an embarrassing issue.
When IGMP snooping cannot be switched off the network administrator has to assure that the
Querier function is implemented at the correct location in the network.
8AL 90880 USBA ed01 65

Figure A11: Switch without multicast control
With ―IGMP snooping‖ enabled, only the interested stations (as DAPs) receive the multicast stream.
Figure A12: Switch with ―IGMP snooping‖ allowing multicast control
―IGMP snooping‖ gives to the switch a ―Layer 3‖ capacity and limits the multicast on ―Layer 2‖
switches
- IGMP packets are intercepted by the processor of the switch or by a specific ASIC.
- The switch examines each packet to determine whether it is a IGMP message (join or leave).
- The switch examines the contents of the packets to determine which ports want what traffic.
Impact on the switches:

- The processing load increases with multicast traffic
- IGMP snooping processed by hardware on some switches.
8AL 90880 USBA ed01 66

- Operations performed in hardware do not affect performance.

- The network administrator has to assure that the Querier function is implemented correctly.
12.3 Multicast / Routers
12.3.1 Multicast Forwarding

In unicast routing, traffic is routed through the network along a single path from the source to the
destination host. A unicast router does not really care about the source address—only the
destination address and how to forward the traffic towards that destination. The router scans through
its routing table and then forwards a single copy of the unicast packet out the correct interface in the
direction of the destination.
In multicast routing, the source is sending traffic to an arbitrary group of hosts that are represented
by a multicast group address. The multicast router must determine which direction is upstream
(towards the source) and which direction (or directions) is downstream. If there are multiple
downstream paths the router will replicate the packet and forward it down the appropriate
downstream paths—which is not necessarily all paths. The concept of forwarding multicast traffic
away from the source, rather than to the receiver, is called Reverse Path Forwarding .
12.3.1.1 Reverse Path Forwarding (RPF)
RPF is a fundamental concept in multicast routing that enables routers to correctly forward multicast
traffic down the distribution tree. RPF makes use of the existing unicast routing table to determine
the upstream and downstream neighbors. A router will only forward a multicast packet if it is
received on the upstream interface. This RPF check helps to guarantee that the distribution tree will
be loop free.
12.3.1.2 RPF Check

When a multicast packet arrives at a router, the router will perform an RPF check on the packet. If
the RPF check is successful, the packet will be forwarded. Otherwise it will be dropped.
For traffic flowing down a source tree, the RPF check procedure works as follows:
Step 1. Router looks up the source address in the unicast routing table to determine if it has arrived
on the interface that is on the reverse path back to the source.
Step 2. If packet has arrived on the interface leading back to the source, the RPF check is
successful and the packet will be forwarded.
Step 3. If the RPF check in 2 fails, the packet is dropped.
12.3.2 Protocol Independent Multicast (PIM)
PIM gets its name from the fact that it is IP routing protocol independent. PIM can leverage
whichever unicast routing protocols are used to populate the unicast routing table including EIGRP,
OSPF, BGP or static routes. PIM uses this unicast routing information to perform the multicast
forwarding function, therefore it is IP protocol independent. Although PIM is called a multicast
8AL 90880 USBA ed01 67

routing protocol it actually uses the unicast routing table to perform the Reverse Path Forwarding
(RPF) check function instead of building up a completely unrelated multicast routing table. PIM does
not send and receive multicast routing updates between routers like other routing protocols.
12.3.2.1 PIM Dense Mode (PIM-DM)

PIM-DM uses a push model to flood multicast traffic to every corner of the network. This is a brute
force method for delivering data to the receivers but in certain applications this might be an efficient
mechanism if there are active receivers on every subnet in the network.
PIM-DM initially floods multicast traffic throughout the network. Routers that do not have any
downstream neighbors prune back the unwanted traffic. This process repeats every three minutes.
The flood and prune mechanism is how the routers accumulate their state information—by receiving
the data stream. These data streams contain the source and group information so that downstream
routers can build up their multicast forwarding table. PIM-DM can only support source trees—(S,G)
entries. It cannot be used to build a shared distribution tree.
12.3.2.2 PIM Sparse Mode (PIM-SM)

PIM-SM uses a pull model to deliver multicast traffic. Only network segments that have active
receivers which have explicitly requested the data will be forwarded the traffic. PIM-SM is defined in
RFC 2362.
PIM-SM uses a shared tree to distribute the information about active sources. Depending on the
configuration options the traffic can remain on the shared tree or switch over to an optimized source
distribution tree.
The traffic starts to flow down the shared tree and then routers along the path determine if there is a
better path to the source. If a better, more direct path exists the designated router (router closest to
the receiver) will send a "join" message towards the source and then re-route the traffic along this
path.
Since PIM-SM does use shared trees—at least initially—it does have the concept of a Rendez-vous
Point (RP). The RP must be administratively configured in the network. Sources register with the RP
and then data is forwarded down the shared tree to the receivers. If the shared tree is not an optimal
path between the source and the receiver the routers will dynamically create a source tree and stop
traffic from flowing down the shared tree. This is the default behavior in IOS. Network Administrators
can force traffic to stay on the shared tree by using a configuration option (ip pim spt-threshold
infinity).
PIM-SM scales well to a network of any size including those with WAN links. The explicit join
mechanism will prevent unwanted traffic from flooding the WAN links.
8AL 90880 USBA ed01 68

Figure A13: PIM SM and Rendez-vous Point (RP)
12.3.2.3 Sparse-dense Mode

It is possible to implement an alternative to choosing just dense mode or just sparse mode on a
router interface. This was necessitated by a change in the paradigm for forwarding multicast traffic
via PIM that became apparent during its development. It turned out that it was more efficient to
choose sparse or dense on a per group basis rather than a per router interface basis. Sparse-dense
mode facilitates this ability.
Network administrators can also configure "sparse-dense" mode. This configuration option will allow
individual groups to be run in either sparse or dense mode depending on whether RP information is
available for that group. If the router learns RP information for a particular group it will be treated as
sparse mode, otherwise that group will be treated as dense.
12.3.3 Multicast Source Discovery Protocol (MSDP)

In the PIM Sparse mode model, multicast sources and receivers must register with their local
Rendez-vous Point (RP). Actually, the closest router to the sources or receivers registers with the
RP but the point is that the RP knows about all the sources and receivers for any particular group.
RPs in other domains have no way of knowing about sources located in other domains. MSDP is an
elegant way to solve this problem. MSDP is a mechanism that connects PIM-SM domains and
allows RPs to share information about active sources. When RPs in remote domains know about the
active sources they can pass on that information to their local receivers and multicast data can be
forwarded between the domains. A nice feature of MSDP is that it allows each domain to maintain
an independent RP which does not rely on other domains but it does enable RPs to forward traffic
between domains.
8AL 90880 USBA ed01 69

The RP in each domain establishes an MSDP peering session using a TCP connection with the RPs
in other domains or with border routers leading to the other domains. When the RP learns about a
new multicast source within its own domain (through the normal PIM register mechanism), the RP
encapsulates the first data packet in a Source Active (SA) message and sends the SA to all MSDP
peers. The SA is forwarded by each receiving peer using a modified RPF check, until it reaches
every MSDP router in the interconnected networks—theoretically the entire multicast internet. If the
MSDP peer is an RP, and the RP has a (*,G) entry for the group in the SA (there is an interested
receiver), the RP will create (S,G) state for the source and join to the shortest path tree for the
source. The encapsulated data is decapsulated and forwarded down that RP's shared tree. When
the packet is received by a receiver's last hop router, the last-hop may also join the shortest path
tree to the source. The source's RP periodically sends SAs which include all sources within that
RP's own domain. Figure 12 shows how data would flow between a source in domain A to a receiver
in domain E.
MSDP was developed for peering between Internet Service Providers (ISPs). ISPs did not want to
reply on an RP maintained by a competing ISP to service to their customers. MSDP allows each ISP
to have their own local RP and still forward and receive multicast traffic to the Internet.
12.4 Multicast / DAPs
Multicast is used in the Business Mobility IP-DECT system for two functions:
♦ Communication between IP-DECT network components to locate/address a handset. The main

reason is that in the DECT environment, you don’t know where a handset is. If a handset must be
reached, the request must go to all DAPs simultaneously.
Example: The "page" function during an incoming call. A single multicast message to all DAPs is
used to find the DAP for this handset in fast and efficient way.
For an incoming call, the registration DAP has to find the current DAP to forward SIP signaling
and media to it. IP multicast is used to find the current DAP.

For an outgoing call, the current DAP has to find the registration DAP to forward SIP signaling and
media to it. IP multicast is used to find the registration DAP.
8AL 90880 USBA ed01 70

Figure A14: Multicast / Incoming call to DECT handset and outgoing call from DECT handset
♦ Seamless handover from one DAP to the other. If inter-cell handover is necessary, the media path
must be re-directed from the existing DAP, to another DAP. A handover is always initiated by the
handset. The handset does a request on another DAP (not the DAP where the connection is at the
moment). This DAP issues a multicast on the network to find out on which DAP the existing voice
connection is. The DAP with the existing voice connection will respond and then the connection can
be re-directed from the DAP with the existing voice connection to the new DAP.
8AL 90880 USBA ed01 71

13. Appendix 2: Example of Routed Headquarter configuration with IGMP

and PIM-SM
Figure A15: Example of Routed Headquarter configuration with IGMP and PIM-SM
8AL 90880 USBA ed01 72

Figure A16: Block diagram example of Routed Headquarter configuration with IGMP and PIM-SM
Remark: You can see that PIM-SM works between routers (layer 3) and that IGMP works in the
subnets (layer 2).
8AL 90880 USBA ed01 73

14. Appendix 3: Example of Routed Headquarter with BO
Figure A17: Example of Routed Headquarter with BO
Remark: External DHCP settings: Do not forget to write the IP address of the DAP controller in the
field “ tftp server name”.
Note: Router used is « 6850-P48 » with system AOS 6.4.3.575.R01.
8AL 90880 USBA ed01 74

15. Appendix 4: Routing table of the DAP controller
Figure A18: Example of routing table
Recommendations for routing table of the Dap controller: Use persistent routes for DAPs subnets
that are not in the same subnet as the DAP controller.
Note: Network command to add a persistent route:

Route –p add Subnet_IP_Addr MASK GW_IP_Addr metric
Ex: route -p add 155.132.29.208 MASK 255.255.255.248 192.168.3.254 metric 1

route -p add 155.132.29.216 MASK 255.255.255.248 192.168.3.254 metric 1
8AL 90880 USBA ed01 75

16. Appendix 5: Wireshark example of a multicast “ping” from a DAP
IP address of the DAP: 155.132.29.211
Multicast address: 239.192.49.42
6 multicast packets at t0:
- First packet: t0 = 09:31:26.571793

6 multicast packets at t1: t1= t0 + 01: 06:09.6
- First packet: t1
Remark: Check that the 6 packets are transmitted using wireshark (for instance).
8AL 90880 USBA ed01 76

8AL 90880 USBA ed01 77

Figures A19-A20-A21: Wireshark trace example of a multicast ―ping‖
Figure A22: Wireshark graph analysis example of a multicast ―ping‖
8AL 90880 USBA ed01 78

17. Appendix 7: RFC2236 (IGMP v2)
This RFC2236 appendix documents IGMPv2, used by IP hosts to report their multicast group
memberships to routers. It updates STD 5, RFC 1112.
IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is
important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.
17.1 Introduction
The Internet Group Management Protocol (IGMP) is used by IP hosts to report their multicast group
memberships to any immediately-neighboring multicast routers. This memo describes only the use
of IGMP between hosts and routers to determine group membership.
Routers that are members of multicast groups are expected to behave as hosts as well as routers,
and may even respond to their own queries. IGMP may also be used between routers, but such use
is not specified here.
Like ICMP, IGMP is a integral part of IP. It is required to be implemented by all hosts wishing to
receive IP multicasts. IGMP messages are encapsulated in IP datagrams, with an IP protocol
number of 2. All IGMP messages described in this appendix are sent with IP TTL 1, and contain the
IP Router Alert option [RFC 2113] in their IP header. All IGMP messages of concern to hosts have
the following format:
17.1.1 Type
There are three types of IGMP messages of concern to the host-router interaction:
0x11 = Membership Query

There are two sub-types of Membership Query messages:
- General Query, used to learn which groups have members on an attached network.
- Group-Specific Query, used to learn if a particular group has any members on an attached
network.
These two messages are differentiated by the ―Group Address‖, as described in the ―Group
Address‖ section . Membership Query messages are referred to simply as "Query" messages.
0x16 = Version 2 Membership Report
0x17 = Leave Group
There is an additional type of message, for backwards-compatibility with IGMPv1:
0x12 = Version 1 Membership Report
This appendix refers to Membership Reports simply as "Reports". When no version is specified, the
statement applies equally to both versions.
8AL 90880 USBA ed01 79

Unrecognized message types should be silently ignored. New message types may be used by
newer versions of IGMP, by multicast routing protocols, or other uses.
17.1.2 Max Response Time
The ―Max Response Time‖ field is meaningful only in Membership Query messages, and specifies
the maximum allowed time before sending a responding report in units of 1/10 second. In all other
messages, it is set to zero by the sender and ignored by receivers.
Varying this setting allows IGMPv2 routers to tune the "leave latency" (the time between the moment
the last host leaves a group and when the routing protocol is notified that there are no more
members). It also allows tuning of the burstiness of IGMP traffic on a subnet.
17.1.3 Checksum
The checksum is the 16-bit one’s complement of the one’s complement sum of the whole IGMP
message (the entire IP payload). For computing the checksum, the checksum field is set to zero.
When transmitting packets, the checksum MUST be computed and inserted into this field.
When receiving packets, the checksum MUST be verified before processing a packet.
17.1.4 Group Address
In a Membership Query message, the group address field is set to zero when sending a General
Query, and set to the group address being queried when sending a Group-Specific Query.
In a Membership Report or Leave Group message, the group address field holds the IP multicast
group address of the group being reported or left.
17.1.5 Other fields
Note that IGMP messages may be longer than 8 octets, especially future backwards-compatible
versions of IGMP. As long as the Type is one that is recognized, an IGMPv2 implementation MUST
ignore anything past the first 8 octets while processing the packet. However, the IGMP checksum is
always computed over the whole IP payload, not just over the first 8 octets.
17.2 Protocol description
Note that defaults for timer values are described later in this document. Timer and counter names
appear in square brackets.
The term "interface" is sometimes used in this document to mean "the primary interface on an
attached network"; if a router has multiple physical interfaces on a single network this protocol need
only run on one of them. Hosts, on the other hand, need to perform their actions on all interfaces
that have memberships associated with them.
Multicast routers use IGMP to learn which groups have members on each of their attached physical
networks. A multicast router keeps a list of multicast group memberships for each attached network,
and a timer for each membership. "Multicast group memberships" means the presence of at least
one member of a multicast group on a given attached network, not a list of all of the members. With
respect to each of its attached networks, a multicast router may assume one of two roles: Querier or
Non-Querier. There is normally only one Querier per physical network. All multicast routers start up
as a Querier on each attached network. If a multicast router hears a Query message from a router
8AL 90880 USBA ed01 80

with a lower IP address, it MUST become a Non-Querier on that network. If a router has not heard a
Query message from another router for [Other Querier Present Interval], it resumes the role of
Querier. Routers periodically [Query Interval] send a General Query on each attached network for
which this router is the Querier, to solicit membership information. On startup, a router SHOULD
send [Startup Query Count] General Queries spaced closely together [Startup Query Interval] in
order to quickly and reliably determine membership information. A General Query is addressed to
the all-systems multicast group (224.0.0.1), has a Group Address field of 0, and has a Max
Response Time of [Query Response Interval].
When a host receives a General Query, it sets delay timers for each group (excluding the all-
systems group) of which it is a member on the interface from which it received the query. Each
timer is set to a different random value, using the highest clock granularity available on the host,
selected from the range (0, Max Response Time] with Max Response Time as specified in the
Query packet. When a host receives a Group-Specific Query, it sets a delay timer to a random value
selected from the range (0, Max Response Time] as above for the group being queried if it is a
member on the interface from which it received the query. If a timer for the group is already running,
it is reset to the random value only if the requested Max Response Time is less than the remaining
value of the running timer. When a group’s timer expires, the host multicasts a Version 2
Membership Report to the group, with IP TTL of 1. If the host receives another host’s Report
(version 1 or 2) while it has a timer running, it stops its timer for the specified group and does not
send a Report, in order to suppress duplicate Reports.
When a router receives a Report, it adds the group being reported to the list of multicast group
memberships on the network on which it received the Report and sets the timer for the membership
to the [Group Membership Interval]. Repeated Reports refresh the timer. If no Reports are received
for a particular group before this timer has expired, the router assumes that the group has no local
members and that it need not forward remotely-originated multicasts for that group onto the attached
network.
When a host joins a multicast group, it should immediately transmit an unsolicited Version 2
Membership Report for that group, in case it is the first member of that group on the network. To
cover the possibility of the initial Membership Report being lost or damaged, it is recommended that
it be repeated once or twice after short delays [Unsolicited Report Interval]. (A simple way to
accomplish this is to send the initial Version 2 Membership Report and then act as if a Group-
Specific Query was received for that group, and set a timer appropriately).
When a host leaves a multicast group (not applicable for IP-DECT), if it was the last host to reply
to a Query with a Membership Report for that group, it SHOULD send a Leave Group message to
the all-routers multicast group (224.0.0.2). If it was not the last host to reply to a Query, it MAY send
nothing as there must be another member on the subnet. This is an optimization to reduce traffic; a
host without sufficient storage to remember whether or not it was the last host to reply MAY always
send a Leave Group message when it leaves a group. Routers SHOULD accept a Leave Group
message addressed to the group being left, in order to accommodate implementations of an earlier
version of this standard. Leave Group messages are addressed to the all-routers group because
other group members have no need to know that a host has left the group, but it does no harm to
address the message to the group.
When a Querier receives a Leave Group message for a group that has group members on the
reception interface, it sends [Last Member Query Count] Group-Specific Queries every [Last
Member Query Interval] to the group being left. These Group-Specific Queries have their Max
Response time set to [Last Member Query Interval]. If no Reports are received after the response
time of the last query expires, the routers assume that the group has no local members, as above.
Any Querier to non-Querier transition is ignored during this time; the same router keeps sending the
Group-Specific Queries. Non-Queriers MUST ignore Leave Group messages, and Queriers
SHOULD ignore Leave Group messages for which there are no group members on the reception
interface.
8AL 90880 USBA ed01 81

When a non-Querier receives a Group-Specific Query message, if its existing group membership
timer is greater than [Last Member Query Count] times the Max Response Time specified in the
message, it sets its group membership timer to that value.
17.3 Compatibility with IGMPv1 Routers
An IGMPv2 host may be placed on a subnet where the Querier router has not yet been upgraded to
IGMPv2. The following requirements apply:
The IGMPv1 router will send General Queries with the Max Response Time set to 0. This MUST
be interpreted as a value of 100 (10 seconds).
The IGMPv1 router expects Version 1 Membership Reports in response to its Queries, and will
not pay attention to Version 2 Membership Reports. Therefore, a state variable MUST be kept for
each interface, describing whether the multicast Querier on that interface is running IGMPv1 or
IGMPv2. This variable MUST be based upon whether or not an IGMPv1 query was heard in the
last [Version 1 Router Present Timeout] seconds, and MUST NOT be based upon the type of the
last Query heard. This state variable MUST be used to decide what type of Membership Reports
to send for unsolicited Membership Reports as well as Membership Reports in response to
Queries.
An IGMPv2 host MAY suppress Leave Group messages on a network where the Querier is using
IGMPv1. An IGMPv2 router may be placed on a subnet where at least one router on the subnet has
not yet been upgraded to IGMPv2. The following requirements apply:
If any IGMPv1 routers are present, the querier MUST use IGMPv1. The use of IGMPv1 must be
administratively configured, as there is no reliable way of dynamically determining whether
IGMPv1 routers are present on a network. Implementations MAY provide a way for system
administrators to enable the use of IGMPv1 on their routers; in the absence of explicit
configuration, the configuration MUST default to IGMPv2. When in IGMPv1 mode, routers MUST
send Periodic Queries with a Max Response Time of 0, and MUST ignore Leave Group
messages. They SHOULD also warn about receiving an IGMPv2 query, although such warnings
MUST be rate-limited. If a router is not explicitly configured to
use IGMPv1 and hears an IGMPv1 Query, it SHOULD log a warning. These warnings MUST be
rate-limited.
17.4 Compatibility with IGMPv1 Hosts
An IGMPv2 host may be placed on a subnet where there are hosts that have not yet been upgraded
to IGMPv2. The following requirement applies:
The host MUST allow its Membership Report to be suppressed by either a Version 1 Membership
Report or a Version 2 Membership Report.
An IGMPv2 router may be placed on a subnet where there are hosts that have not yet been
upgraded to IGMPv2. The following requirements apply:
If a router receives a Version 1 Membership Report, it MUST set a timer to note that there are
version 1 hosts present which are members of the group for which it heard the report. This timer
should be the same as the [Group Membership Interval].
If there are version 1 hosts present for a particular group, a router MUST ignore any Leave Group
messages that it receives for that group.
8AL 90880 USBA ed01 82

17.5 Host State Diagram
Host behavior is more formally specified by the state transition diagram below. A host may be in one
of three possible states with respect to any single IP multicast group on any single network interface:
- "Non-Member" state, when the host does not belong to the group on the interface. This is the initial
state for all memberships on all network interfaces; it requires no storage in the host.
- "Delaying Member" state, when the host belongs to the group on the interface and has a report
delay timer running for that membership.
- "Idle Member" state, when the host belongs to the group on the interface and does not have a
report delay timer running for that membership.
There are five significant events that can cause IGMP state transitions:
- "join group" occurs when the host decides to join the group on the interface. It may occur only in
the Non-Member state.
- "leave group" (not applicable for IP-DECT) occurs when the host decides to leave the group on
the interface. It may occur only in the Delaying Member and Idle Member states.
- "query received" occurs when the host receives either a valid General Membership Query
message, or a valid Group-Specific Membership Query message. To be valid, the Query message
must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP
header must either be zero (a General Query) or a valid multicast group address (a Group-Specific
Query). A General Query applies to all memberships on the interface from which the Query is
received. A Group-Specific Query applies to membership in a single group on the interface from
which the Query is received. Queries are ignored for memberships in the Non-Member state.
- "report received" occurs when the host receives a valid IGMP Membership Report message
(Version 1 or Version 2). To be valid, the Report message must be at least 8 octets long and have a
correct IGMP checksum. A Membership Report applies only to the membership in the group
identified by the Membership Report, on the interface from which the Membership Report is
received. It is ignored for memberships in the Non-Member or Idle Member state.
- "timer expired" occurs when the report delay timer for the group on the interface expires. It may
occur only in the Delaying Member state.
All other events, such as receiving invalid IGMP messages, or IGMP messages other than Query or
Report, are ignored in all states.
There are seven possible actions that may be taken in response to the above events:
- "send report" for the group on the interface. The type of report is determined by the state of the
interface. The Report Message is sent to the group being reported.
- "send leave" for the group on the interface. If the interface state says the Querier is running
IGMPv1, this action SHOULD be skipped. If the flag saying we were the last host to report is
cleared, this action MAY be skipped. The Leave Message is sent to the ALL-ROUTERS group
(224.0.0.2).
- "set flag" that we were the last host to send a report for this group.
- "clear flag" since we were not the last host to send a report for this group.
- "start timer" for the group on the interface, using a delay value chosen uniformly from the interval
(0, Max Response Time], where Max Response time is specified in the Query. If this is an
unsolicited Report, the timer is set to a delay value chosen uniformly from the interval (0,
[Unsolicited Report Interval] ].
- "reset timer" for the group on the interface to a new value, using a delay value chosen uniformly
from the interval (0, Max Response Time], as described in "start timer".
- "stop timer" for the group on the interface.
8AL 90880 USBA ed01 83

In all of the following state diagrams, each state transition arc is labeled with the event that causes
the transition, and, in parentheses, any actions taken during the transition. Note that the transition is
always triggered by the event; even if the action is conditional, the transition still occurs.
The all-systems group (address 224.0.0.1) is handled as a special case. The host starts in Idle
Member state for that group on every interface, never transitions to another state, and never sends
a report for that group.
In addition, a host may be in one of two possible states with respect to any single network interface:
- "No IGMPv1 Router Present", when the host has not heard an IGMPv1 style query for the [Version
1 Router Present Timeout]. This is the initial state.
- "IGMPv1 Router Present", when the host has heard an IGMPv1 style query within the [Version 1
Router Present Timeout].
There are two events that can cause state transitions:
- "IGMPv1 query received", when the host receives a query with the Max Response Time field set to
0.
- "timer expires", when the timer set to note the presence of an IGMPv1 router expires.
And a single action that can be triggered by an event:
- "set timer", setting the timer to its maximum value [Version 1 Router Present Timeout] and
(re)starting it.
8AL 90880 USBA ed01 84

17.6 Router State Diagram
Router behavior is more formally specified by the state transition diagrams below.
A router may be in one of two possible states with respect to any single attached network:
- "Querier", when this router is designated to transmit IGMP Membership Queries on this network.
- "Non-Querier", when there is another router designated to transmit IGMP membership Queries on
this network.
The following three events can cause the router to change states:
- "query timer expired" occurs when the timer set for query transmission expires.
- "query received from a router with a lower IP address" occurs when an IGMP Membership Query is
received from a router on the same network with a lower IP address.
- "other querier present timer expired" occurs when the timer set to note the presence of another
querier with a lower IP address on the network expires.
There are three actions that may be taken in response to the above events:
- "start general query timer" for the attached network.

- "start other querier present timer" for the attached network [Other Querier Present Interval].
- "send general query" on the attached network. The General Query is sent to the all-
systems group (224.0.0.1), and has a Max Response Time of [Query Response Interval].
8AL 90880 USBA ed01 85

A router should start in the Initial state on all attached networks, and immediately move to Querier
state.
In addition, to keep track of which groups have members, a router may be in one of four possible
states with respect to any single IP multicast group on any single attached network:
- "No Members Present" state, when there are no hosts on the network which have sent reports for
this multicast group. This is the initial state for all groups on the router; it requires no storage in the
router.
- "Members Present" state, when there is a host on the network which has sent a Membership
Report for this multicast group.
- "Version 1 Members Present" state, when there is an IGMPv1 host on the network which has sent
a Version 1 Membership Report for this multicast group.
- "Checking Membership" state, when the router has received a Leave Group message but has not
yet heard a Membership Report for the multicast group.
There are six significant events that can cause router state transitions:
- "v2 report received" occurs when the router receives a Version 2 Membership Report for the group
on the interface. To be valid, the Report message must be at least 8 octets long and must have a
correct IGMP checksum.
- "v1 report received" occurs when the router receives a Version 1 Membership report for the group
on the interface. The same validity requirements apply.
- "leave received" occurs when the router receives an IGMP Group Leave message for the group on
the interface. To be valid, the Leave message must be at least 8 octets long and must have a
correct IGMP checksum.
- "timer expired" occurs when the timer set for a group membership expires.
- "retransmit timer expired" occurs when the timer set to retransmit a group-specific Membership
Query expires.
8AL 90880 USBA ed01 86

- "v1 host timer expired" occurs when the timer set to note the presence of version 1 hosts as group
members expires.
There are six possible actions that may be taken in response to the above events:
- "start timer" for the group membership on the interface – also resets the timer to its initial value
[Group Membership Interval] if the timer is currently running.
- "start timer*" for the group membership on the interface – this alternate action sets the timer to
[Last Member Query Interval] * [Last Member Query Count] if this router is a Querier, or the [Max
Response Time] in the packet * [Last Member Query Count] if this router is a non-Querier.
- "start retransmit timer" for the group membership on the interface [Last Member Query Interval].
- "start v1 host timer" for the group membership on the interface, also resets the timer to its initial
value [Group Membership Interval] if the timer is currently running.
- "send group-specific query" for the group on the attached network. The Group-Specific Query is
sent to the group being queried, and has a Max Response Time of [Last Member Query Interval].
- "notify routing +" notify the routing protocol that there are members of this group on this connected
network.
- "notify routing -" notify the routing protocol that there are no longer any members of this group on
this connected network.
The state diagram for a router in Querier state follows:
The state diagram for a router in Non-Querier state is similar, but non-Queriers do not send any
messages and are only driven by message reception.
Note that non-Queriers do not care whether a Membership Report message is Version 1 or Version
2.
8AL 90880 USBA ed01 87

17.7 List of timers and default values
Most of these timers are configurable. If non-default settings are used, they MUST be consistent
among all routers on a single link. Note that parentheses are used to group expressions to make the
algebra clear.
17.7.1 Robustness Variable
The Robustness Variable allows tuning for the expected packet loss on a subnet. If a subnet is
expected to be lossy, the Robustness Variable may be increased. IGMP is robust to (Robustness
Variable-1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be
one. Default: 2
17.7.2 Query Interval
The Query Interval is the interval between General Queries sent by the Querier. Default: 125
seconds.
By varying the [Query Interval], an administrator may tune the number of IGMP messages on the
subnet; larger values cause IGMP Queries to be sent less often.
17.7.3 Query Response Interval
The Max Response Time inserted into the periodic General Queries. Default: 100 (10 seconds).
By varying the [Query Response Interval], an administrator may tune the burstiness of IGMP
messages on the subnet; larger values make the traffic less bursty, as host responses are spread
out over a larger interval. The number of seconds represented by the [Query Response Interval]
must be less than the [Query Interval].
8AL 90880 USBA ed01 88

17.7.4 Group Membership Interval
The Group Membership Interval is the amount of time that must pass before a multicast router
decides there are no more members of a group on a network. This value MUST be ((the Robustness
Variable) times (the Query Interval)) plus (one Query Response Interval).
17.7.5 Other Querier Present Interval
The Other Querier Present Interval is the length of time that must pass before a multicast router
decides that there is no longer another multicast router which should be the querier. This value
MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query
Response Interval).
17.7.6 Startup Query Interval
The Startup Query Interval is the interval between General Queries sent by a Querier on startup.
Default: 1/4 the Query Interval.
17.7.7 Startup Query Count
The Startup Query Count is the number of Queries sent out on startup, separated by the Startup
Query Interval. Default: the Robustness Variable.
17.7.8 Last Member Query Interval
The Last Member Query Interval is the Max Response Time inserted into Group-Specific Queries
sent in response to Leave Group messages, and is also the amount of time between Group-Specific
Query messages. Default: 10 (1 second).
This value may be tuned to modify the "leave latency" of the network. A reduced value results in
reduced time to detect the loss of the last member of a group.
17.7.9 Last Member Query Count
The Last Member Query Count is the number of Group-Specific Queries sent before the router
assumes there are no local members. Default: the Robustness Variable.
17.7.10 Unsolicited Report Interval
The Unsolicited Report Interval is the time between repetitions of a host’s initial report of
membership in a group. Default: 10 seconds.
17.7.11 Version 1 Router Present Timeout
The Version 1 Router Present Timeout is how long a host must wait after hearing a Version 1 Query
before it may send any IGMPv2 messages. Value: 400 seconds.
8AL 90880 USBA ed01 89

17.8 Message destinations
This information is provided elsewhere in the document, but is summarized here for convenience.
Message Type Destination Group
------------------------------ --------------------------------------
General Query ALL-SYSTEMS (224.0.0.1)
Group-Specific Query The group being queried
Membership Report The group being reported
Leave Message ALL-ROUTERS (224.0.0.2)
Note: In older (i.e., non-standard and now obsolete) versions of IGMPv2, hosts send Leave
Messages to the group being left. A router SHOULD accept Leave Messages addressed to the
group being left in the interests of backwards compatibility with such hosts. In all cases, however,
hosts MUST send to the ALL-ROUTERS address to be compliant with this specification.
17.9 Security Considerations
We consider the ramifications of a forged message of each type.
Query Message:
A forged Query message from a machine with a lower IP address than the current Querier will
cause Querier duties to be assigned to the forger. If the forger then sends no more Query
messages, other routers’ Other Querier Present timer will time out and one will resume the role
of Querier. During this time, if the forger ignores Leave Messages, traffic might flow to groups
with no members for up to [Group Membership Interval].
A forged Query message sent to a group with members will cause the hosts which are members
of the group to report their memberships. This causes a small amount of extra traffic on the
LAN, but causes no protocol problems.
Report messages:
A forged Report message may cause multicast routers to think there are members of a group on
a subnet when there are not. Forged Report messages from the local subnet are meaningless,
since joining a group on a host is generally an unprivileged operation, so a local user may
trivially gain the same result without forging any messages. Forged Report messages from
external sources are more troublesome; there are two defenses against externally forged
Reports:
- Ignore the Report if you cannot identify the source address of the packet as belonging to a
subnet assigned to the interface on which the packet was received. This solution means that
Reports sent by mobile hosts without addresses on the local subnet will be ignored.
- Ignore Report messages without Router Alert options [RFC 2113], and require that routers not
forward Report messages. (The requirement is not a requirement of generalized filtering in the
forwarding path, since the packets already have Router Alert options in them). This solution
breaks backwards compatibility with implementations of earlier versions of this specification
which did not require Router Alert.
8AL 90880 USBA ed01 90

A forged Version 1 Report Message may put a router into "version 1 members present" state for
a particular group, meaning that the router will ignore Leave messages. This can cause traffic to
flow to groups with no members for up to [Group Membership Interval]. There are two defenses
against forged v1 Reports:
- To defend against externally sourced v1 Reports, ignore the Report if you cannot identify the
source address of the packet as belonging to a subnet assigned to the interface on which the
packet was received. This solution means that v1 Reports sent by mobile hosts without
addresses on the local subnet will be ignored.
- Provide routers with a configuration switch to ignore Version 1 messages completely. This
breaks automatic compatibility with Version 1 hosts, so should only be used in situations where
"fast leave" is critical. This solution protects against forged version 1 reports from the local
subnet as well.
Leave message:
A forged Leave message will cause the Querier to send out Group-Specific Queries for the
group in question. This causes extra processing on each router and on each member of the
group, but can not cause loss of desired traffic. There are two defenses against externally
forged Leave messages:
- Ignore the Leave message if you cannot identify the source address of the packet as
belonging to a subnet assigned to the interface on which the packet was received. This solution
means that Leave messages sent by mobile hosts without addresses on the local subnet will be
ignored.
- Ignore Leave messages without Router Alert options [RFC 2113], and require that routers not
forward Leave messages. (The requirement is not a requirement of generalized filtering in the
forwarding path, since the packets already have Router Alert options in them). This solution
breaks backwards compatibility with implementations of earlier versions of this specification
which did not require Router Alert.
8AL 90880 USBA ed01 91

8AL90880USBA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8AL90880USBA

Uploaded by

Copyright:

Available Formats

IP-DECT:

Network and troubleshooting manual

8AL 90880 USBA ed01

1. IP-DECT SYSTEM .................................................................................................................................................... 4

1.1 GENERAL ................................................................................................................................................................. 4

2. DAP CHARACTERISTICS ........................................................................................................................................ 12

2.1 GENERAL ............................................................................................................................................................... 12

3. DAP CONTROLLER BEHAVIOUR IN THE NETWORK ............................................................................................... 14

3.1 GENERAL ............................................................................................................................................................... 14

4. IP SWITCH SETTINGS ............................................................................................................................................ 15

4.1 REQUIREMENTS FOR IP SWITCHES IN AN IP-DECT NETWORK ........................................................................................... 15

5. IP ROUTER SETTINGS ........................................................................................................................................... 16

5.1 GENERAL ............................................................................................................................................................... 16

6. PRIORITY / QOS / VLAN SUPPORT ....................................................................................................................... 19

7. DHCP SERVER ...................................................................................................................................................... 19

7.1 GENERAL ............................................................................................................................................................... 19

8. TFTP SERVER ........................................................................................................................................................ 20

9. DHCP-LESS / TFTP-LESS ........................................................................................................................................ 20

10. IP MULTICAST BEHAVIOUR .............................................................................................................................. 21

10.1 INTRODUCTION ....................................................................................................................................................... 21

8AL 90880 USBA ed01 2

10.9 MULTICAST “PING” TEST MECHANISM ......................................................................................................................... 25

11. TROUBLESHOOTING AND DEBUGGING ............................................................................................................ 30

11.1 DEBUG TOOL: DAP VIEWER....................................................................................................................................... 30

12. APPENDIX 1: IP MULTICAST TECHNOLOGY OVERVIEW .................................................................................... 59

12.1 CONCEPT OF IP MULTICAST GROUP ............................................................................................................................. 59

14. APPENDIX 3: EXAMPLE OF ROUTED HEADQUARTER WITH BO ........................................................................ 74

15. APPENDIX 4: ROUTING TABLE OF THE DAP CONTROLLER ................................................................................ 75

16. APPENDIX 5: WIRESHARK EXAMPLE OF A MULTICAST “PING” FROM A DAP ................................................... 76

17. APPENDIX 7: RFC2236 (IGMP V2) .................................................................................................................... 79

17.1 INTRODUCTION ....................................................................................................................................................... 79

8AL 90880 USBA ed01 3

Figure 1: IP-DECT system configuration

The simple system consists of the following components:

 IP Switch with PoE

It runs under MS Windows:

- Windows 7 (not the home edition),

8AL 90880 USBA ed01 4

ALE IP-DECT supports OmniPCX Enterprise and OmniPCX office

The following sections show the possible system configurations of IP-DECT.

1.2 System configurations

The three system configurations are given hereafter:

1.2.1 Simple Configuration

8AL 90880 USBA ed01 5

Figure 2: "Example of Simple IP DECT network configuration"

possible to use IPv4 Public addressing.

1.2.2 Routed Head Quarter

− IP DECT configuration behaves as one large IP DECT system.

− Routers must support IP Multicast routing.

− The IP Multicast address for IP DECT is the same in all segments.

Note: The DAP manager is always mandatory in a Head Quarter configuration.

8AL 90880 USBA ed01 6

Figure 3: "Example of an IP-DECT Routed Head Quarter configuration"

1.2.3 Multiple subnets

 A Head Quarter with Branch Office.

 A Routed Head Quarter with Branch Office.

 A Routed Head Quarter with a Routed Branch Office.

8AL 90880 USBA ed01 7

1.2.3.1 Head Quarter with Branch Office(s)

(Radio Links, ADSL etc.).

− No OXE PBX needed in Branch Office(!).

− Seamless handover is supported in Branch Offices and in Main Office.

− No handset handover between Head Quarters and (individual) Branch Offices.

− No IP multicast support required for Routers.