Trying to use DHCP Option 66 to Provison P-330 phones. I’m pretty sure that the phone is getting the DHCP Option 66 string, becasue it’s behavior changed after enabling that in the dhcp server and after resetting to factory defaults. On “Booting Phone” completion, the phone displays :Fetch failed (Bad XML at 10:1-No Document Element found)
My DHCP Option 66 string is in the format “sip:proxy:FQDN:5060” but I’ve also tried without the port specified like “sip:proxy:fqdn”
I’m using a PBXAct 17 Cloud based system as a bench test to try this, but I’m also curious if the same procdure and string will work on PBXAct15 box on the LAN using the LAN IP rather than the FQDN just for reliability and simplicity.
My provisioning ports are 84 and 1443 and https is not forced. The certificate is up to date.
Is there a module I need to install for DPMA, or update? I’m at a loss
“Fetch Failed (Bad XML at 10:1 - No Document Element found)” is the phone’s XML syntax check on the file it just downloaded. The phone only raises it after a transfer that succeeded. For an HTTP fetch that means the server answered 2xx. For DPMA it means the PBX sent a complete config response. An unreachable host, a DNS failure, or a 404 never produces this screen. So DHCP worked, the phone reached a server, and the server handed something back.
“No Document Element found” at line 10, column 1 means the parser read the whole body and never saw a single XML tag. The server returned about nine lines of plain text or JSON. That is probably a status or error message from the provisioning side (unknown MAC, phone not mapped to an extension, template missing, auth problem) being delivered in place of a config file. The phone does not read the message. It just sees “not XML” and stops.
sip:proxy:FQDN:5060 is not the DPMA form. The phone recognizes DPMA only by the exact prefix sip:proxy@(note that “@” is a required part of the URL). Anything else is treated as a plain hostname to fetch config files from. That failure shows a different screen (a generic “error contacting server” message), not the Bad XML one.
**apartis, thanks for the input. I really should have caught that “**sip:proxy@pfqdn:5060” error in the oprion 66 dhcp string_I knew this “@” was required there. You know how it is when you’re banging your head, trying over and over, and you say uncle for the day. Fresh eyes always help. I’d tried all sorts of strings before settling on that last one, it was the one where I burned out. I know the phone is mapped to an extension in endpoint manager, and to a template with that model enabled. You wrote “Always include the scheme for HTTP” no sure what you are suggesting here? My presumption was that the Option 66 DPMA directive would be sufficient for the phone to find a way to provision. HTTP, and HTTPS provisioning are enabled. In the instructions I found, using the DPMA string “sip:proxy@pfqdn:5060” omitted the need or requirement for the “Authentication element” of provisioning, or I missed it. I’m referring to something like “sip:proxy:User:password@pfqdn:5060”, or whatever the appropriate syntax is or would be if authentication is required for provisioning
And by the way, I had referred to that reference link you provided in your last message before ever making the post, and part of that is still unclear to me-specifically, if Username:password are required when using DPMA provisioning and what the format of that string would look like.
Also, I mistakenly wrote in my original post that I used “sip:proxy:FQDN:5060” but when I looked at the string in the DHCP server, it in fact had the correct sip:proxy@FQDN:5060 in the string- so that wasn’t the problem.
…both received the same error as in the original post (Bad XML at 10:1-No Document Element found) I checked the ports, and they are correct.
I’m using an old Windows 2008 Server R2 Standard for the DHCP Server, and my gateway is a fairly up to date Sonicwall that I don’t have any reason to believe would be blocking responses from the cloud pbx.