[cisco-voip] webkit fun!

Mon Sep 17 12:06:32 EDT 2018

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 <lelio at uoguelph.ca<mailto:lelio at 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 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

<image001.png>

From: Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>>
Sent: Monday, September 17, 2018 11:55 AM
To: Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>>
Cc: cisco-voip voyp list <cisco-voip at puck.nether.net<mailto:cisco-voip at 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 at 127.0.0.1<mailto:e6929c13a865eb5b at 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 at 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 at 127.0.0.1>

2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: Referred-By: <sip:1051422 at videolab.local>

2018-09-17T11:49:55.807-04:00 rratliff-rkplus appl[1750]: SipPacket[2]: From: <sip:1051422 at 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 at puck.nether.net<mailto:cisco-voip at 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 <lelio at uoguelph.ca<mailto:lelio at 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 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

<image001.png>

From: Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>>
Sent: Monday, September 17, 2018 11:30 AM
To: Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>>
Cc: Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>>; cisco-voip voyp list <cisco-voip at puck.nether.net<mailto:cisco-voip at 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 <lelio at uoguelph.ca<mailto:lelio at 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 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

<image001.png>

From: Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>>
Sent: Friday, September 14, 2018 3:29 PM
To: Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>>
Cc: cisco-voip voyp list <cisco-voip at puck.nether.net<mailto:cisco-voip at 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 <lelio at uoguelph.ca<mailto:lelio at 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 DN at cucm-host.acme.com<mailto:DN at cucm-host.acme.com><mailto:DN at cucm-host.acme.com<mailto:DN at 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, usingDN at servicedomain.acme.com<mailto:DN at servicedomain.acme.com><mailto:DN at servicedomain.acme.com<mailto:DN at 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 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca><mailto:lelio at uoguelph.ca<mailto:lelio at 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 at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180917/206ab527/attachment.html>