NTP will be provisioned by CUCM, but they must be unicast sources and not directed broadcast (the default).
Turning provisioning off/cucm just forces the endpoint to go get a new config file immediately. When in doubt, turn up extended logging, toggle provisioning, then go look at the logs. They are very well done on these endpoints. -Ryan On Sep 17, 2018, at 3:40 PM, Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: OK I think I found what I was seeing – it seems (and this is likely the anticipated behavior), that if I change the device’s provisioning from CUCM to OFF and from OFF to CUCM, it looses all custom configurations. For example, something simple as setting NTP to manual and entering my NTP servers works until I change the provisioning, then those settings are lost. Seems like a drag, but I understand. But, still. Ugh. I wish that CUCM interface had all of these settings to be provisioned. Now to figure out why a user with user privileges is allowed to change the provisioning method ! Lelio --- Lelio Fulgenzi, B.A. | Senior Analyst Computing and Communications Services | University of Guelph Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1 519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook <image001.png> From: Ryan Ratliff (rratliff) <rratl...@cisco.com<mailto:rratl...@cisco.com>> Sent: Monday, September 17, 2018 12:31 PM To: Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> Subject: Re: [cisco-voip] webkit fun! Yes you should. Save on endpoint, refresh on CUCM to see the changes. -Ryan On Sep 17, 2018, at 12:11 PM, Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: Will do! I’m hoping I will see any changes reflected in the CUCM configuration pages, right? So if I make the change on the unit and then go back to the config page, the setting will be different? It’s just an easier test for me at this point. --- Lelio Fulgenzi, B.A. | Senior Analyst Computing and Communications Services | University of Guelph Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1 519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook <image001.png> From: Ryan Ratliff (rratliff) <rratl...@cisco.com<mailto:rratl...@cisco.com>> Sent: Monday, September 17, 2018 12:07 PM To: Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> Subject: Re: [cisco-voip] webkit fun! If you troubleshoot locally make sure to turn on extended debugging first, otherwise you won’t see the content of SIP messages. -Ryan On Sep 17, 2018, at 11:59 AM, Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: Wow. Thanks so much Ryan! --- Lelio Fulgenzi, B.A. | Senior Analyst Computing and Communications Services | University of Guelph Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1 519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook <image001.png> From: Ryan Ratliff (rratliff) <rratl...@cisco.com<mailto:rratl...@cisco.com>> Sent: Monday, September 17, 2018 11:55 AM To: Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> Subject: Re: [cisco-voip] webkit fun! Here’s an example. 2018-09-17T11:49:50.605-04:00 rratliff-rkplus appl[1750]: CuilApp[1]: Successfully changed configuration 'Configuration/Proximity/Mode' to 'On' by admin from <my ip address>. 2018-09-17T11:49:55.806-04:00 rratliff-rkplus appl[1750]: PROV[3]: [sendThrottledConfig] Notifying SIP stack about vendor config 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket I: SIP Msg: Outgoing => REFER, CSeq: 101 REFER, Remote: 172.18.120.72:5060, CallId: db63adeda53772b3ac1cf516c4ddbe60 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: REFER sip:172.18.120.72 SIP/2.0 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Via: SIP/2.0/TCP 10.80.114.79:44255;branch=z9hG4bKe9a85770060f257bc99036fc6abfdeb4;rport 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Call-ID: db63adeda53772b3ac1cf516c4ddbe60 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: CSeq: 101 REFER 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Content-Id: <e6929c13a865eb5b@127.0.0.1<mailto:e6929c13a865eb5b@127.0.0.1>> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Contact: <sip:d88b9342-a3d6-a6f3-5cad-bae84671165a@10.80.114.79:44255;transport=tcp>;sip.cisco.multistream 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Refer-To: <cid:e6929c13a865eb5b@127.0.0.1> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Referred-By: <sip:1051422@videolab.local> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: From: <sip:1051422@videolab.local>;tag=c70d1756d9d3e262 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: To: <sip:172.18.120.72> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Max-Forwards: 70 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Route: <sip:172.18.120.72;lr> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: User-Agent: TANDBERG/529 (ce9.3.3.655fc73f140) Cisco-CodecPlus 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Expires: 0 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Require: norefersub 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Content-Type: application/x-cisco-remotecc-request+xml 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Content-Length: 2269 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: <x-cisco-remotecc-request> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: <device-specific-config> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: <vendorConfig> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: <DefaultVolume>70</DefaultVolume><WakeupOnMotionDetection>On</WakeupOnMotionDetection><webAccess>2</webAccess><sshAccess>0</sshAccess><TelnetMode>Off</TelnetMode><OSDEncryptionIndicator>Auto</OSDEncryptionIndicator><LDAPServerAddress></LDAPServerAddress><LDAPServerPort>0</LDAPServerPort><LDAPAdminGroup></LDAPAdminGroup><LDAPAdminFilter></LDAPAdminFilter><CallLoggingMode>On</CallLoggingMode><DefaultCallProtocol>0</DefaultCallProtocol><MicUnmuteOnDisconnectMode>On</MicUnmuteOnDisconnectMode><multipointMode>0</multipointMode><MaxTotalDownstreamRate>6000</MaxTotalDownstreamRate><MaxTotalUpstreamRate>6000</MaxTotalUpstreamRate><AlternatePhonebookServerType>UDS</AlternatePhonebookServerType><LoadServer></LoadServer><qualityImprovementServer>upgrade.cisco.com<http://upgrade.cisco.com/></qualityImprovementServer><SystemName>rratliff-rkplus</SystemName><RoomName></RoomName><FacilityServiceGroup><FacilityServiceCallType>Video</FacilityServiceCallType><FacilityServiceName></FacilityServiceName><FacilityServiceNumber></FacilityServiceNumber><FacilityServiceType>Helpdesk</FacilityServiceType></FacilityServiceGroup><Proximity><ProximityCallControl>Disabled</ProximityCallControl><ProximityContentShareToClients>Disabled</ProximityContentShareToClients><ProximityContentShareFromClients>Disabled</ProximityContentShareFromClients><ProximityMode>On</ProximityMode></Proximity><StandbyGroup><StandbyMode>On</StandbyMode><StandbyDelay>10</StandbyDelay><StandbyAction>PrivacyPosition</StandbyAction></StandbyGroup><SerialPortGroup><SerialPortLoginRequired>On</SerialPortLoginRequired><SerialPortMode>On</SerialPortMode></SerialPortGroup><Osd><TodaysBookings>Off</TodaysBookings></Osd><FarEndCameraControlGroup><FarEndCameraControlMode>On</FarEndCameraControlMode><FarEndCameraControlSignalCapability>On</FarEndCameraControlSignalCapability></FarEndCameraControlGroup><LDAPUserManagement><LDAPMode>Off</LDAPMode><LDAPEncryption>LDAPS</LDAPEncryption><LDAPVerifyServerCertificate>Off</LDAPVerifyServerCertificate><LDAPBaseDN></LDAPBaseDN><LDAPAttribute></LDAPAttribute><LDAPMinimumTLSVersion>TLSv1.2</LDAPMinimumTLSVersion></LDAPUserManagement> </vendorConfig> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: </device-specific-config> 2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: </x-cisco-remotecc-request> TLDR, change to config made, SIP stack gets notified by provisioning, the entire vendorConfig (device specific settings) XML gets pushed back up to CUCM. -Ryan On Sep 17, 2018, at 11:49 AM, Ryan Ratliff (rratliff) via cisco-voip <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> wrote: As long as Provisioning is set to CUCM and On (and it’s registered) then local config changes should get sent back up via SIP where CUCM commits them to the database. -Ryan On Sep 17, 2018, at 11:38 AM, Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: Hmmm, pretty sure any change I made on the endpoint reverted to what it was on CUCM after a reset. Is there something special I need to do on the endpoint to tell CUCM to take this new setting? I think I was looking at the proximity settings as an example – I changed them on the end point, but they don’t seem to be in sync on CUCM. I’ll have to double check. --- Lelio Fulgenzi, B.A. | Senior Analyst Computing and Communications Services | University of Guelph Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1 519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook <image001.png> From: Ryan Ratliff (rratliff) <rratl...@cisco.com<mailto:rratl...@cisco.com>> Sent: Monday, September 17, 2018 11:30 AM To: Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> Cc: Brian Meade <bmead...@vt.edu<mailto:bmead...@vt.edu>>; cisco-voip voyp list <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> Subject: Re: [cisco-voip] webkit fun! Yea, it will overwrite it with the CUCM configuration. You can try turning off provisioning and point it manually to CUCM. I’m catching up from last week but don’t do this. Endpoints registered to CUCM must be provisioned by CUCM. Any config that is set on the Device page in CCMAdmin can actually be pushed back up to CUCM if it is changed on the endpoint itself, a very cool feature created for the TC/CE endpoints. This means the endpoint and CUCM should be in sync. -Ryan On Sep 14, 2018, at 3:39 PM, Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: I’m ok with that – the more I can do on CUCM the better in my opinion. But I’m not sure where to set the SIP URI for the device in CUCM. --- Lelio Fulgenzi, B.A. | Senior Analyst Computing and Communications Services | University of Guelph Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1 519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook <image001.png> From: Brian Meade <bmead...@vt.edu<mailto:bmead...@vt.edu>> Sent: Friday, September 14, 2018 3:29 PM To: Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> Subject: Re: [cisco-voip] webkit fun! Yea, it will overwrite it with the CUCM configuration. You can try turning off provisioning and point it manually to CUCM. On Fri, Sep 14, 2018 at 3:21 PM Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote: Alright, got this webkit registered, both on-prem and through expressway. My testing while on expressway wasn't going so well, so I'm going to concentrate on on-prem first and certify all functions then move to expressway registration after that. Biggest thing is that the SIP URI shows as d...@cucm-host.acme.com<mailto:d...@cucm-host.acme.com><mailto:d...@cucm-host.acme.com<mailto:d...@cucm-host.acme.com>> which is causing me nothing but grief. This SIP URI won't work because we need to use the service domain to get calls in but this is what shows during proximity. Yuck. I've tried changing it but it still doesn't work and it changes with every reset/re-registration. I've tried adding SIP URIs in the user setup and on the DN setup but to no avail. For some reason, I think this is even breaking just DN dialing, usin...@servicedomain.acme.com<mailto:d...@servicedomain.acme.com><mailto:d...@servicedomain.acme.com<mailto:d...@servicedomain.acme.com>> which was working to my SX20 without any SIP URI configuration, although the SX20 is using TC software, not CE. I'm going to break out the admin and user guides, but thought I'd ask. Also - what's the rule of thumb with setting things in CUCM Device Config Page vs Device GUI? It seems like I can change things on the device GUI, but if the setting exists in CUCM Device Config Page, that value overwrites on next reset. --- Lelio Fulgenzi, B.A. | Senior Analyst Computing and Communications Services | University of Guelph Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1 519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca><mailto:le...@uoguelph.ca<mailto:le...@uoguelph.ca>> www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs><http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook [University of Guelph Cornerstone with Improve Life tagline] _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
