08-08-2011 01:08 PM - edited 03-16-2019 06:21 AM
Heya guys... We've got some Cisco 9971s that I've been trying to configure to work with our SIP Server... I've got them making/receiving calls fine, which is great, but I'm seeing a weird problem that LOOKS like it is on the phone side. Specifically, NTP settings made in the .cnf.xml file do not seem to be registering. The result is that the phone always thinks it is 16:00 on 12/31/81 whenever it boots.
The relevant section of my SEP(mac).cnf.xml is:
<dateTimeSetting>
<dateTemplate>M/D/Y</dateTemplate>
<timeZone>Pacific Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>192.168.168.10</name>
<ntpMode>Unicast</ntpMode>
</ntp>
</ntps>
</dateTimeSetting>
When I watch all the traffic to/from this port with Wireshark I don't see any attempts to talk to the IP of the NTP server at all.
Anyone have any ideas?
Thanks!
11-08-2013 02:35 PM
@ Joseph Martini
You said it worked with a newer load, can you tell us which version you used?
Maybe we just need a differnt configuration in the SEP file.
With 9.0.4 this works for me:
Could you post your config?
11-08-2013 02:41 PM
Sure thing, the setting that I ended up using is:
----
But, I tried a lot of other things before realizing that I needed to stick with 9.0.4 in order to get it to work. I don't really remember the specifics, however, as this was over two years ago.
11-08-2013 02:50 PM
The interesting question is: what do we have in common what other users don't have:
Most interesting would be to see a config of a user who has a running setup!
11-09-2013 03:02 AM
I used 9.3(4).
{9ec4850a-7748-11d3-bdf0-00108302ead1}"> CMLocal M/D/Y Greenwich Standard Time Etc/GMT 172.18.108.15 Anycast
11-10-2013 06:38 AM
I just copied the part you posted and changed the IP to my server. No changes in the behaviour. Are you shure that your 99xx Phone is using the NTP-Server and not the time provided by the register response?
11-08-2013 02:48 PM
Ahhh, here is another suspicious line:
4171 ERR 01:01:21.740800 NTP: -Missing or invalid argument on line 1
11-08-2013 03:03 PM
@Luke
Sorry the questions wasn't for you, it was an question/answer for Joseph.
It's a bit hard to see in this forum, so I edited my post.
@Till
try
I think this resolved the error with the missing argument, but not the whole ntp problem.
11-08-2013 03:09 PM
No I don't think that argument is allowed:
3805 WRN 00:01:18.331728 CVM-xml.LogWarning: [thread=configmgr MQThread][class=cip.xml.ad][line=13] XML Parser Warning: Unknown attribute 'priority' in element '/device/devicePool/dateTimeSetting/ntps/ntp/name'
I think the error message is independent of the argument, but have not confirmed that yet
11-11-2013 11:16 AM
Follow up from my last post. My test wasn't completed enough. I setup an NTP reference with a date of Jan 1, 2035 and pointed my phone to it. The phone while on firmware 9.0(4) showed the correct Jan 1, 2035 time on the phone and not the time from my server which is today's date and time. Upgrading the phone to 9.4(1) which is the newest available, and changing nothing else in my environment, I saw the CUCM's time not the NTP reference time on the phone. This confirms that this is indeed broken. I've brought this up to the phone developers and filed a defect for it, CSCul33490 (should be visible in the bug toolkit in about 24 hours).
Thanks for finding this and pointing it out! I wouldn't have noticed since the time on CUCM is almost never wrong since NTP is required to expose this.
11-11-2013 11:52 AM
Thanks,
at least now we know for sure, that it is a bug and I can stop testing different NTP settings
Hopefully they will resolve this with the next version.
10-07-2014 06:03 AM
The ticket was closed without a resolution. I don't know why.
11-13-2013 04:21 AM
Is the bug id correct? It's still not visible.
Best regards
Till
11-13-2013 04:50 AM
Thanks for the follow up Till. I just checked on the bug again and it should be visible shortly.
01-14-2016 05:50 AM
in case its useful for someone. Its not a bug - ntp is intentionally turned off >91(1).
https://tools.cisco.com/bugsearch/bug/CSCul33490
05-03-2019 12:35 PM
Your post was very useful.
Thank you very much.
I stumbled upon the same problem while trying to set the time on a 9971 connected to Fritz!Box.
...and after looking here I found a solution on a German page. Simply search for "sip-date.pl cisco-8961-9951-9971" and let Google translate the page.
I had to alter the code for the sip-date.pl a bit. This is the diff I had to apply to make it run under Ubuntu 18.04:
--- sip-date.pl.org 2019-05-03 21:13:58.168648698 +0200 +++ sip-date.pl 2019-05-03 21:19:03.048169800 +0200 @@ -38,9 +38,8 @@ sub cb() { - my ($dummy,$payload) = @_; + my ($payload) = @_; print "Perl callback called!\n"; - print "dummy is $dummy\n" if $dummy; if ($payload) { print "len: " . $payload->get_length() . "\n"; @@ -114,10 +113,6 @@ $q = new nfqueue::queue(); -print "open\n"; -$q->open(); -print "bind\n"; -$q->bind(AF_INET); $SIG{INT} = "cleanup"; @@ -132,7 +127,7 @@ print "creating queue\n"; -$q->create_queue(0); +$q->fast_open(0, AF_INET); print "trying to run\n";
The time display now looks like this:
Good luck.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide