Booting or connecting a Poly SoundStation IP, SoundPoint IP, VVX Business Media, CCX, VVX IP Phone or a Poly Trio to a network switch initiates certain network protocol’s
NOTE: The below has been tested with a VVX600 running UC Software 5.3.1. Using a different phone and/or software version may vary in the result
INITIAL BOOT PROCESS
The below illustrates the initial => LLDP Discovery <=
Check Step 2 => here <= in order to disable LLDP
000016.816|lldp |1|00|Sending LLDP packet with length (lldpPktLen= 37) 000017.817|lldp |1|00|Sending LLDP packet with length (lldpPktLen= 369) 000018.817|lldp |1|00|Sending LLDP packet with length (lldpPktLen= 369) 000019.819|lldp |1|00|Sending LLDP packet with length (lldpPktLen= 369) 000020.820|lldp |1|00|Sending LLDP packet with length (lldpPktLen= 369) 000021.820|lldp |1|00|Sending LLDP packet with length (lldpPktLen= 369)
NOTE: Please check the UC Software Admin guide on details for configuration parameters to either disable LLDP or modify the LLDP Discovery !
Example:
<web device.set="1" device.net.lldpFastStartCount.set="1" device.net.lldpFastStartCount="10"/>
The above Parameter would send 10 LLDP packets instead of the original 5
Any reply to the LLDP and we do not send CDP packets!
Followed by the => CDP <= discovery
Check Step 2 => here <= in order to disable CDP
000024.844|cdp |1|00|Sending CDP packet with length (cdpPktLen= 141) 000025.844|cdp |1|00|Sending CDP packet with length (cdpPktLen= 141) 000026.845|cdp |1|00|Sending CDP packet with length (cdpPktLen= 141)
NOTE: Please check the UC Software Admin guide on details for configuration parameters to disable CDP !
Both of the above can be utilized to receive or send Data like a => VLAN <= from and to the phone
If any of the above receives data from a network switch the phone would process this.
The phone would then proceed with sending a => DHCP Discover <=
000032.166|dhcpc|3|00|dhcListener: Read succeeds: eth0 state: PREINIT Listening on LPF/eth0/00:04:f2:ac:89:bb Sending on LPF/eth0/00:04:f2:ac:89:bb Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Within this DHCP Discover message, the phone uses various Sub-Options
<test device.set="1" device.hostname="replace_with_own_value" device.hostname.set="1" />
Option 55 is actually a List of Sub Options
The phone can then receive one or multiple DHCP Offers:
NOTE: The Offer does not mandatorily need to contain all requested options!
DHCPOFFER from 10.252.149.249
The Phone would then Request the IP Address and everything else:
DHCPREQUEST on eth0 to 255.255.255.255 port 67
And the Server would ACKNOWLEDGE this exchange
DHCPACK from 10.252.149.249
The Details can be seen in the Phone logs:
000033.490|dhcpc|3|00|dhcListener: Read succeeds: eth0 ip: 10.252.149.109.
000033.493|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: subnet-mask 255.255.252.0.
000033.494|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: routers 10.252.149.1.
000033.494|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: domain-name-servers 10.252.149.120 10.252.130.10.
000033.495|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: domain-name sbaierhome.lab.
000033.497|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: time-offset 0.
000033.497|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: dhcp-lease-time 691200.
000033.498|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: dhcp-server-identifier 10.252.149.249.
000033.499|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: ntp-servers 10.252.149.249.
000033.500|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: time-servers 10.252.149.249.
000033.503|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: broadcast-address 10.252.151.255.
000033.506|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: dhcp-lease-time 691200.
000033.507|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: dhcp-message-type 5.
000033.508|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: dhcp-renewal-time 345600.
000033.509|dhcpc|3|00|dhcListener: Read succeeds: eth0 option: dhcp_rebinding_time 604800.
000033.532|dhcpc|3|00|dhcListener: Read succeeds: eth0 state: BOUND.
000033.536|cfg |*|00|RT|Do not do DHCP VLAN Discovery.
000033.536|cfg |*|00|RT| Phone IP address is 10.252.149.109.
000033.536|cfg |*|00|RT| Subnet mask is 255.255.252.0.
000033.536|cfg |*|00|RT| Gateway address is 10.252.149.1.
000033.536|cfg |*|00|RT| DNS server is 10.252.149.120.
000033.536|cfg |*|00|RT| DNS alternate server is 10.252.130.10.
000033.536|cfg |*|00|RT| DNS domain is sbaierhome.lab.
000033.536|cfg |*|00|RT| Time server is 10.252.149.249.
000033.536|cfg |*|00|RT| GMT offset is 0 seconds.
000033.538|dns |*|00|DNS resolver servers are '10.252.149.120' '10.252.130.10'
000033.538|dns |*|00|DNS resolver search domain is 'sbaierhome.lab'
000033.540|cfg |*|00|RT|Primary IP: 10.252.149.109 subnet mask 255.255.252.0
Proxy:
General Troubleshooting:
A correct setup Skype for Business infrastructure should not send any Option 43 details as defined in detail => here <= if the Vendor Class send by the device is not MS-UC-Client.
Only the MS-UC-Client Vendor option should request the Option 43.
In non LYNC mode our Polycom Phones, and other Vendors, can actually utilize the Option 60 / Option 43 combination as explained => here <=
Polycom phones running at least UC Software 4.0.0 are sending DHCP Discover message as listed in "Option 55 Parameter Requested List" and able to fulfill the purpose of the given sub-options from Option 43. This follows the RFC2132
Option 55 in the DHCP Discover:
An Option 43 reply to a DHCP Discover can actually contain the following supported DHCP Sub-Options:
The following table lists the individual sub-options and combination sub-options supported on Polycom phones.
Additional DHCP Option 43 Configuration Options
Option |
Result |
Option 1- Subnet mask |
The phone parses the value from Option 43. |
Option 2 - Time offset |
The phone parses the value. |
Option 3 - Router |
The phone parses the value. |
Option 4 - Time server |
The phone parses the value. |
Option 6 - Domain Name Server |
The phone parses the value. |
Option 7 - Domain Log server |
The phone parses the value. |
Option 15 - Domain Name |
The phone parses the value. |
Option 42 - Network Time Protocol server |
The phone parses the value. |
Option 66 - TFTP Server Name |
The phone parses the value. |
Options 128-255 |
|
Sub-options configured in Option 43 |
|
Options 1, 2, 3, 4, 5, 6, 7, 15, 42, and 66 |
The phone parses the value. |
Options 128-255 |
|
Example for a Provisioning Server:
Option Number |
Length |
Value |
42 |
1D |
66 74 70 3a 2f 2f 6d 75 6b 65 68 2e 61 73 69 61 2E 70 6f 6c 79 63 6f 6d 2e 63 6f 6d |
option66 |
24 |
000035.669|dhcpc|3|4122|dhcListener: Read succeeds: eth0 option: vendor-encapsulated-options 5:2:b:7:6:aa:aa:1:95:c3:2e:c8:0
Polycom WPAD Discovery
Please check => here <=
Polycom ZTP
The phone, from Factory default, tries to reach the Polycom ZTP Platform
Polycom Experience Cloud
The Polycom Labs feature can be activated to send analytics automatically to Polycom
The phone establishes a secure connection to the Polycom PEC server
Troubleshooting Option 43 / 120 Issues.
Taking a Wireshark trace during the Phone is booting up will show the DORA for discovery, offer, request, and acknowledgment (Source => here <=).
Current versions of UC Software already Identify themselves as a MS-UC-Client after booting up.
This happens after the initial DORA by sending a DHCP INFORM utilizing the Option: (60) Vendor class identifier.
This is being used to identify if the Option 43 is correctly setup so we can display the Extension & PIN sign in option.
The Option: (55) Parameter Request List requests Option 120 and Option 43.
Once the phone is booted up and presents the valid Sign-In Options and Extension and PIN screen can be selected and the user is expected to enter their details.
Older Software versions would during this stage identify itself (depending on the Model) in the DISCOVER and REQUEST as an example Polycom-VVX600.
The Process used for this is the Option: (60) Vendor class identifier.
We would not expect the DHCP server to send the Microsoft configured Option 43 or 120 if we are not identifying as MS-UC-Client.
Once the phone is booted up and presents the Extension and PIN screen the user is expected to enter these details.
Older Software Version would only now start sending a DHCP INFORM to the DHCP Server.
Please check => here <= for details
At this stage the Option: (60) Vendor class identifier is set as a MS-UC-Client instead.
The Option: (55) Parameter Request List now requests Option 120 and Option 43.
The DHCP server will respond with an ACK and present the requested Options.
The Option: (43) Vendor-Specific Information will not be in a human readable format.
Using the Copy => Bytes => Printable Text Only feature of Wireshark the Data can be displayed when copied into a text editor.
+]MS-UC-Clienthttpslyncfe01.t3voipuk.lab443%/CertProv/CertProvisioningService.svcNAP
The DHCP Server would show these options like this:
Our Polycom Guru Jeff Schertz explains this in greater detail => here <=
Setting the Logging via the Web Interface (UCS 5.2.0 or later only !)
Or via a Configuration File:
<PIN log.level.change.tickt="1"
log.level.change.cfg="3"
log.render.level="0"
log.render.file.size="1000"/>
Incorrect or incomplete:
0918144405|tickt|1|00|soWebTicketServersGet: request URI is /mex
Correct example:
0919080727|cfg |3|00|Prov|[CfgLyncSipSrvDiscover::cbFoundOption] Received STS-URI is 'https://lyncfe01.t3voipuk.lab:443/CertProv/CertProvisioningService.svc'
202646.012|tickt|1|00|soWebTicketServersGet: request URI is https://lyncfe01.t3voipuk.lab:443/CertProv/CertProvisioningService.svc/mex
Manually configuring an Option 43 STS-URI:
In an environment where there is no Option 43/120 or an incorrect setup STS URI this can be provided manually via:
<test dhcp.option43.override.stsUri="Specify URL here" />
Correct Example:
dhcp.option43.override.stsUri="https://lyncfe01.t3voipuk.lab/CertProv/CertProvisioningService.svc"
Polycom Trio
After booting up the Polycom Trio will keep sending multicast packets from port 320 to port 320 for it's Precision Time Protocol
Polycom Visual+ or VisualPro
The RealPresence Visual+ sends out Multicast Traffic in order to advertise itself within the network to RealPresence Trio's
It uses an IP 224.0.0.200 and the port 2000 for this.
Once the Trio itself add's the Visual+ to connect the Trio will connect to the Visual+ and pair:
The Trio Logs show this Discovery package as:
1121134633|mr |1|00|Discovery from 0004f2fd1851 10.252.149.54 port 8000 status 0 pair 0 hw 2:Trio Visual+
1121134634|mr |1|00|Discovery from 00e0db48c130 10.252.149.55 port 18888 status 2 pair 0 hw 8:RealPresence Group 500
The following log:
log.level.change.mr="1"
or via the Web Interface shows this:
In January 2018 Poly acquired ObiHai. Older ObiHai phones can only be ordered with the ObiHai software.
The newer Poly VVX 150, 250, 350, and 450 phones can be ordered with either Poly UC Software or ObiHai software. The Poly D230 can only run ObiHai software.
Older ObiHai Phones:
The below is an overview of what Network activities can be seen using a Poly/Obi Phone running and older ObiHai software stack. The example, in this case, is an ObiHai 2182 running the Obi 6.2.2 software after factory default. We use the following filter in Wireshark:
eth.addr[0:3]==9c:ad:ef
Booting up an ObiHai Software edition phone does not use LLDP or CDP and starts with the DORA DHCP Process:
The DHCP Discover:
Within this DHCP Discover message, the phone uses various Sub-Options
Once the DORA is complete the phone then starts a DNS query for root.pnn.obihai.com and connects to the server:
Newer ObiHai Poly Phones:
The below is an overview of what Network activities can be seen using a Poly Phone running ObiHai software stack. The example, in this case, is a Poly VVX D230 running the Obi 7.1.0 software after factory default. We use the following filter in Wireshark:
eth.addr[0:3]==9c:ad:ef
Unlike the "older" legacy ObiHai phones the new Poly D230 as an example will start with 3x LLDP packets and 3x CDP Packets:
It then starts with the DORA DHCP Process:
The DHCP Discover:
Within this DHCP Discover message, the phone uses various Sub-Options
The phone can then receive one or multiple DHCP Offers:
NOTE: The Offer does not mandatorily need to contain all requested options!
Once the DORA is complete the phone then starts a DNS query for prov.obitalk.com and connects securely to the server:
The phone then starts a DNS query for root.pnn.obihai.com and connects to the server:
The phone then starts the TFTP request received via Option 55 Sub Option 66 if received prior for the device file name: