GDMS and TR-069


#1

Hello All,

Anyone else notice issues with the Periodic Inform Interval when using GDMS to configure phones?

For some reason, it seems the GRP2614’s I’m working with keep switching to 86400 seconds (1 day). Zeroconfig is certainly turned off. Never been used at this site. Primarily because the majority of the phones are remote (again, no zero config as the phones are not VPN’d to the network).

I think it was a firmware update that might have glitched the phones. Just wondering if anyone else has run into this.

I will be adding the pcodes to my GDMS config to try and keep this set to 60 seconds. Which, according to the config doc, is the default setting.

Periodic Inform Interval. Default is 60.

Number

P4507 = 60

Related question. Am I totally wrong about what the Periodic Inform Interval does? I’ve played around with this a little and it seems to do what I think. Here’s what I’ve done.

  • I found a phone with PII set to 86400.
  • I sent the command in GDMS to reboot the phone. It timed out after about 10 minutes.
  • I sent the phone to reboot by schedule rather than immediate. Schedule set for a 24 hour period. I noticed the phone reboot about 16 hours later.
  • I set the PII to 60 on the phone.
  • I sent to command in GDMS to reboot the phone. The phone rebooted in about a minute.

So, it seems obvious but, the word “Inform” sounds like the phone is telling some device, some info, on that schedule. If the feature was labeled something like, Periodic Poll Interval or Periodic Sync Interval, it would be more obvious, at least to me, what this is trying to accomplish.

Thanks in advance!


#2

Dear user,

Thank you for using GDMS platform! The server changes the Periodic Inform Interval to 86400 automatically. Our design method is: If the STUN packets are normal all the time, the GDMS platform can inform the phone as expected, so that the periodic reporting is not very necessary, the server will change it to 86400; However, if the STUN packets are abnormal, the GDMS platform will change it to 300, so that the phone need to respond to the GDMS platform within 300 seconds. This parameter will be auto changed by the server. May I ask the reason that why we need to change it? We can analyze this feature request based on the requirements.

Your understand about the Periodic Inform Interval is correct. If the user has to use this to execute the tasks, which means the STUN packets may include some errors. Users can check the UDP packets from stun1.gdms.cloud:3478, or check the firewall blocking rules, or capture the trace file and syslog for us to continue troubleshooting. We will help you to resolve this issue and offer you a satisfy solution. Thanks!

Thank you!


#3

This are TR-069 names. You can follow file if you want :slight_smile:


#4

hi @GSSupport74,

It seems to me quite obvious that 86400 seconds are an exaggerated time range, phones should de default a reasonable timing example max 300 seconds.

Also if you impose a reboot at 17.45 (example), I would like this took place at 5.45pm.
Not that this happened between 5.15pm and 6.00PM

Damiano


#5

Dear user,

Thank you for using GDMS platform! The Periodic Inform Interval is just an urgent measure under some special situation, and it will not affect users’ tasks execution. This interval parameter is decided by the server, and users will not use/change this parameter at most scenarios. I will pass this feedback to our GDMS development team for evaluation.

The GDMS platform allows users to set a specific duration to execute the task because if the user is in a active call, multiple tasks are in a queue, or the device is offline at this time stamp, the GDMS platform server will keep assigning the task to the device during this period until the device executes the task. When the device finishes the current task or call, and the device is back to idle, the task can be executed. Thanks for your testing! Let me know if you have any other concerns or questions about this. Thanks!

Thank you!


#6

Perhaps there was in issue in a couple of firmware editions where this information is not correct. As stated in my initial post (related question section). The phones were unresponsive. They would not update firmware. They would not reboot. They would not factory reset. They would not update a template. This was happening on all phones with firmware ending in .15 and .44 (I’m sure about the .15, I’m not positive about the .44). However, if I setup a scheduled task and left it running for 24 hours, all devices would eventually update over the next day.

.61 seems better. I can’t test right now as all offices with the 2614’s that have been a problem for me are currently open.

I would also point out that in ticket number 20201026125126 I was having trouble pushing changes to the phone. Support advised me to set the PII to 600 seconds. I ended up setting it to 60 as 600 would cause me to have to wait up to 10 minutes (theoretically) for changes to push through. This is the only way I was able to get the phones to update. It’s because of this I was iritated to find the phones once again unresponsive and with a PII of 86400.


#7

Dear user,

Thank you for your feedback! Could you kindly help to capture the trace file with Syslog from the device side so that we can analyze the issue that why the task was not assigned. If the user modifes the Periodic Inform Interval and this issue indeed can be avoided, because if the user modifes this option, the process of obtaining the task can be triggered. However, this is not the normal operation process, we need to resolve the issue why the task cannot be assigned. Therefore, we may need your captured logs to see why the task cannot be assigned, so this issue can be resolved. Thanks for your testing!

Thank you!


#8

Hello @GSSupport74

Remaining in the councils, it may be useful to make “mass changes”, for example I have set 25 custom templates, and are repeated in 6 organizations, total 15 custom templates, whenever I have to add 1 “P” / Example (57 = 8) I have to virtually enter 150 custom templates and make the change.
On the second screen there would be what I ask, on UCM today you can make the mass modification of the Extensions,
Can you bring this features as well to GDMS? (obviously, the settings between one model and another very different, obviously this mass modification would only concern the addition / modification of detection “P”

Same speech being able to carry out the mass export / import of all custom templates, today you can only every single custom templates -> In my case it would mean to make 150 downloads / uploads

Damiano


#9

Dear user,

Thank you for your feedback! I have talked about this feature with our GDMS platform development team today, and this is a known feature request and we are working on evaluating the features and how to implement this in the GDMS platform. It may take some time to implement in the GDMS platform and I will let you know once we have any conclusions about this. Thanks for your testing and suggestions!

Thank you!


#10

I’ve updated the firmware a couple days ago. So, I figured I’d confirm if the reboot was fixed. I selected 4 random devices. Two on the same network as the UCM, two remote. 3 of the 4, all running 1.0.5.61 failed to reboot. I get “Timeout” when checking the task…

image

I logged into one of the phones that timed out and turned on packet capture. Clicked Admin logout. Ran the reboot test again with the package capture running. This time, the device rebooted. I can’t say why. Maybe because I had just logged? That might have “woken up” the phone or something. I’ve attached the capture that was running before the reboot but, being as the reboot worked this time, I doubt there will be useful info. If I get to it, I’ll attempt to run this test again tomorrow but run the package capture through GDMS rather than logging in.

captures.tar (249.5 KB)


#11

Dear user,

Thank you for your feedback! The task timeout issue may be caused by some different reasons, for example, the device may be in an active call during that period, the network issue that the server did not receive any responses from the device, and etc. Could you kindly send the MAC addresses of your timeout GRP2614 to us so that I can ask our server administrator to check the background server to see if the tasks have been assigned to the device or not? All reboot tasks were assigned at 2021/10/19 08:33? I will also pass the captured logs and report the issue to our GDMS development team for evaluation. Thanks for your testing!

Thank you!