Re: 8851 Phones not coming out of SRST

permalldnit · ‎12-08-2017

Hello,

I have a branch office with 58 x 8851 Cisco Phones (SIP) connected. Voice Gateway is a Cisco 2911 Router. Phones are plugged into a Cisco 3850 switchcore.

Branch and Main office are connected via a VPN between 2 x Fortinet Firewalls.

If the VPN goes down the phones go into SRST.

If I type show call-manager-fallback licenses I can see all 58 licenses used. Phones work fine in SRST.

When the link returns the phones display show that they are reregistering and registered. All looks good ,however:-

1) On Call Manager v10.5.1 I can see all the phones and they all say "unregistered"

2) Show Call-manager-fallback license shows 58 phones still with an SRST license

To get them out of SRST i have to either bounce the port on the switch or reboot the phones. I have seen there is another command where you can go into call-manager-fallback and type reset all or reset H.H.H (mac address) these commands don't work.

Does anyone have any idea what is potentially wrong?

I am thinking there is something either missing from the switch port or the voice gateway.

Thanks,

Glenn

Mohammed al Baqari · ‎12-09-2017

Hi Glen,

When your connectivity is restored you need to make sure that the phones are able to reach the call manager cluster. From above I can tell that phones aren't able to reach call manager cluster (although your VPN is up). Hence they fallback again to SRST.

Georgios Fotiadis · ‎12-09-2017

When you say that phones are registered back and "all looks good", you mean that they seem to be registered to CUCM?

It is possible that they are still seen as unregistered at CUCM if RIS has stuck. Though, as @Mohammed al Baqari suggested, I think that they are still registered at SRST. Can you collect and attach "debug ccsip messages" logs after the link comes up? Also, if you may attach you config.

Also, the reset command under call-manager-fallback applies only to SCCP phones, so this is not your case. Unfortunately, to my knowledge, there is no such command for SIP SRST. You could delete your "voice register global" configuration to speed things up, but that is not the best option.

SIP SRST phones may take a long time to register back at CUCM. How long do you wait before resetting phones manually?

Georgios
Please rate if you find this helpful.

Chris Deren · ‎12-09-2017

What firmware version are the phones running?

If not 12.0 upgrade them as there are many known bugs for 88XX phones with SRST on 11.5, 11.7 firmware loads.

permalldnit · ‎12-11-2017

Mohammed, Georgios, Chris,

Thanks for all the feedback, I will try and answer all your questions in one go.

With regards to how long we are waiting for the phones to come out of SRST. We have waited hours in fact more than 24 hours.

The firmware currently running on the phones is sip88xx.11-7-1ES-11 we have literally just upgraded to this firmware as this was what Cisco TAC told us to do. Unfortunately this problem has been running on for a long time and now we don't have TAC support anymore so thats why I am seeking help here.

I have just put 8 phones into SRST by quickly bringing the circuit down and bringing
it back up again.

The phones on the desks look like they are are registered back to the Call Manager
as they no longer say "CCM Fallback", however, the phone on the Call Manager says
"Unregistered". See attached screen dump.

If I run show call-manager-fallback licenses I still see 8 licenses being used

License Supported:
cme-srst: Registered, In Use. Handle: 0x7000005
Maximum User License: 58
CSL license count: 58
CSL Requested User License: 58
Used User License: 8
Available User License: 50
Max Users Provisioned (ephone + pool): 58
Allowance - Extra user license: 0
temp_license_expired_event: 0
license_installed_event: 0
license_count_change_event: 0
eula_not_accepted: 0
license_check_approved: 6564
license_check_denied: 18

The Call Manager can ping these phones.

admin:utils network ping 10.102.134.196
PING 10.102.134.196 (10.102.134.196) 56(84) bytes of data.
64 bytes from 10.102.134.196: icmp_seq=1 ttl=60 time=1.73 ms
64 bytes from 10.102.134.196: icmp_seq=2 ttl=60 time=1.57 ms
64 bytes from 10.102.134.196: icmp_seq=3 ttl=60 time=1.62 ms
64 bytes from 10.102.134.196: icmp_seq=4 ttl=60 time=1.56 ms

--- 10.102.134.196 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3019ms
rtt min/avg/max/mdev = 1.565/1.626/1.736/0.078 ms

admin:utils network ping 10.102.134.136
PING 10.102.134.136 (10.102.134.136) 56(84) bytes of data.
64 bytes from 10.102.134.136: icmp_seq=1 ttl=60 time=1.62 ms
64 bytes from 10.102.134.136: icmp_seq=2 ttl=60 time=1.52 ms
64 bytes from 10.102.134.136: icmp_seq=3 ttl=60 time=1.50 ms
64 bytes from 10.102.134.136: icmp_seq=4 ttl=60 time=1.66 ms

--- 10.102.134.136 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3015ms
rtt min/avg/max/mdev = 1.509/1.581/1.667/0.073 ms

admin:utils network ping 10.102.134.140
PING 10.102.134.140 (10.102.134.140) 56(84) bytes of data.
64 bytes from 10.102.134.140: icmp_seq=1 ttl=60 time=1.68 ms
64 bytes from 10.102.134.140: icmp_seq=2 ttl=60 time=1.67 ms
64 bytes from 10.102.134.140: icmp_seq=3 ttl=60 time=1.58 ms
64 bytes from 10.102.134.140: icmp_seq=4 ttl=60 time=1.52 ms

--- 10.102.134.140 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3015ms
rtt min/avg/max/mdev = 1.522/1.617/1.688/0.079 ms

admin:utils network ping 10.102.134.135
PING 10.102.134.135 (10.102.134.135) 56(84) bytes of data.
64 bytes from 10.102.134.135: icmp_seq=1 ttl=60 time=1.68 ms
64 bytes from 10.102.134.135: icmp_seq=2 ttl=60 time=1.77 ms
64 bytes from 10.102.134.135: icmp_seq=3 ttl=60 time=1.66 ms
64 bytes from 10.102.134.135: icmp_seq=4 ttl=60 time=1.62 ms

--- 10.102.134.135 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 1.629/1.689/1.775/0.053 ms

admin:utils network ping 10.102.134.134
PING 10.102.134.134 (10.102.134.134) 56(84) bytes of data.
64 bytes from 10.102.134.134: icmp_seq=1 ttl=60 time=1.70 ms
64 bytes from 10.102.134.134: icmp_seq=2 ttl=60 time=1.60 ms
64 bytes from 10.102.134.134: icmp_seq=3 ttl=60 time=1.67 ms
64 bytes from 10.102.134.134: icmp_seq=4 ttl=60 time=1.55 ms

--- 10.102.134.134 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3012ms
rtt min/avg/max/mdev = 1.554/1.636/1.706/0.065 ms

Running the debug ccsip messages command schows the following

VGIPT37501#debug ccsip messages
SIP Call messages tracing is enabled
VGIPT37501#
*Dec 11 10:07:39.569: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
REGISTER sip:10.102.135.254 SIP/2.0
Via: SIP/2.0/UDP 10.102.134.203:5060;branch=z9hG4bK4b7af897
From: <sip:8115600@10.102.135.254>;tag=00562bb4779c00070839898b-356823cd
To: <sip:8115600@10.102.135.254>
Call-ID: 00562bb4-779c0004-40d66a5d-56c1c75a@10.102.134.203
Max-Forwards: 70
Session-ID: 25d7cd6c00105000a00000562bb4779c;remote=00000000000000000000000000000000
Date: Mon, 11 Dec 2017 10:30:02 GMT
CSeq: 2907 REGISTER
User-Agent: Cisco-CP8851/11.7.1
Contact: <sip:843b6c9c-427c-1fa2-21f7-1e5545b3b29f@10.102.134.203:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00562bb4779c>";+u.sip!devicename.ccm.cisco.com="SEP00562BB4779C";+u.sip!model.ccm.cisco.com="684"
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Content-Length: 0
Expires: 0

*Dec 11 10:07:39.569: //2731399/F43C9C169779/SIP/Msg/ccsipDisplayMsg:
Sent:

VGIPT37501#SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.102.134.203:5060;branch=z9hG4bK4b7af897
From: <sip:8115600@10.102.135.254>;tag=00562bb4779c00070839898b-356823cd
To: <sip:8115600@10.102.135.254>;tag=1A079204-219B
Date: Mon, 11 Dec 2017 10:07:39 GMT
Call-ID: 00562bb4-779c0004-40d66a5d-56c1c75a@10.102.134.203
Server: Cisco-SIPGateway/IOS-15.2.4.M6
CSeq: 2907 REGISTER
Content-Length: 0

VGIPT37501#
*Dec 11 10:07:41.297: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
REGISTER sip:10.102.135.254 SIP/2.0
Via: SIP/2.0/UDP 10.102.134.139:5060;branch=z9hG4bK06421e67
From: <sip:+12122245536@10.102.135.254>;tag=00562bb4b17a00071ecc0359-49ca2064
To: <sip:+12122245536@10.102.135.254>
Call-ID: 00562bb4-b17a0004-52675e9a-6849233c@10.102.134.139
Max-Forwards: 70
Session-ID: 702d1e2800105000a00000562bb4b17a;remote=00000000000000000000000000000000
Date: Mon, 11 Dec 2017 10:30:03 GMT
CSeq: 2907 REGISTER
User-Agent: Cisco-CP8851/11.7.1
Contact: <sip:5bbd9181-c6a3-dcc7-2e30-c89b0d65d2a3@10.102.134.139:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00562bb4b17a>";+u.sip!devicename.ccm.cisco.com="SEP00562BB4B17A";+u.sip!model.ccm.cisco.com="684"
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Content-Length: 0
Expires: 0

*Dec 11 10:07:41.297: //2731400/F5444883977A/SIP/Msg/ccsipDisplayMsg:
Sent:

VGIPT37501#SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.102.134.139:5060;branch=z9hG4bK06421e67
From: <sip:+12122245536@10.102.135.254>;tag=00562bb4b17a00071ecc0359-49ca2064
To: <sip:+12122245536@10.102.135.254>;tag=1A0798C4-1F48
Date: Mon, 11 Dec 2017 10:07:41 GMT
Call-ID: 00562bb4-b17a0004-52675e9a-6849233c@10.102.134.139
Server: Cisco-SIPGateway/IOS-15.2.4.M6
CSeq: 2907 REGISTER
Content-Length: 0

*Dec 11 10:07:42.045: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
REGISTER sip:10.102.135.254 SIP/2.0
Via: SIP/2.0/UDP 10.102.134.182:5060;branch=z9hG4bK2feadd7d
From: <sip:+12124072823@10.102.135.254>;tag=00562bb4a51000072ae6f303-7a198bb9
To: <sip:+12124072823@10.102.135.254>
Call-ID: 00562bb4-a5100004-4d9c196d-5c1681d5@10.102.134.182
Max-Forwards: 70
Session-ID: edcaacc700105000a00000562bb4a510;remote=00000000000000000000000000000000
Date: Mon, 11 Dec 2017 10:30:02 GMT
CSeq: 2197 REGISTER
User-Agent: Cisco-CP8851/11.7.1
Contact: <sip:4844b2ce-41c1-1e90-6b2f-b244cb375d8f@10.102.134.182:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00562bb4a510>";+u.sip!devicename.ccm.cisco.com="SEP00562BB4A510";+u.sip!model.ccm.cisco.com="684"
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Content-Length: 0
Expires: 0

*Dec 11 10:07:42.049: //2731401/F5B66BD0977B/SIP/Msg/ccsipDisplayMsg:
Sent:

VGIPT37501#SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.102.134.182:5060;branch=z9hG4bK2feadd7d
From: <sip:+12124072823@10.102.135.254>;tag=00562bb4a51000072ae6f303-7a198bb9
To: <sip:+12124072823@10.102.135.254>;tag=1A079BB0-2604
Date: Mon, 11 Dec 2017 10:07:42 GMT
Call-ID: 00562bb4-a5100004-4d9c196d-5c1681d5@10.102.134.182
Server: Cisco-SIPGateway/IOS-15.2.4.M6
CSeq: 2197 REGISTER
Content-Length: 0

VGIPT37501#
*Dec 11 10:07:46.513: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
REGISTER sip:10.102.135.254 SIP/2.0
Via: SIP/2.0/UDP 10.102.134.183:5060;branch=z9hG4bK45673f3d
From: <sip:+12124186622@10.102.135.254>;tag=00562bb4a5dc000770185a80-09865581
To: <sip:+12124186622@10.102.135.254>
Call-ID: 00562bb4-a5dc0004-5486796c-60e43347@10.102.134.183
Max-Forwards: 70
Session-ID: 5606818500105000a00000562bb4a5dc;remote=00000000000000000000000000000000
Date: Mon, 11 Dec 2017 10:30:09 GMT
CSeq: 2904 REGISTER
User-Agent: Cisco-CP8851/11.7.1
Contact: <sip:cb9625f3-263d-ec3d-aad0-42c8e583338b@10.102.134.183:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00562bb4a5dc>";+u.sip!devicename.ccm.cisco.com="SEP00562BB4A5DC";+u.sip!model.ccm.cisco.com="684"
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Content-Length: 0
Expires: 0

*Dec 11 10:07:46.513: //2731402/F8602E35977C/SIP/Msg/ccsipDisplayMsg:
Sent:

VGIPT37501#SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.102.134.183:5060;branch=z9hG4bK45673f3d
From: <sip:+12124186622@10.102.135.254>;tag=00562bb4a5dc000770185a80-09865581
To: <sip:+12124186622@10.102.135.254>;tag=1A07AD24-1BB
Date: Mon, 11 Dec 2017 10:07:46 GMT
Call-ID: 00562bb4-a5dc0004-5486796c-60e43347@10.102.134.183
Server: Cisco-SIPGateway/IOS-15.2.4.M6
CSeq: 2904 REGISTER
Content-Length: 0

*Dec 11 10:07:47.433: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
REGISTER sip:10.102.135.254 SIP/2.0
Via: SIP/2.0/UDP 10.102.134.192:5060;branch=z9hG4bK03f39fd6
From: <sip:+12124186654@10.102.135.254>;tag=00562bb4a04000076ae5e209-4d2ac6ea
To: <sip:+12124186654@10.102.135.254>
Call-ID: 00562bb4-a0400004-0010488b-43922018@10.102.134.192
Max-Forwards: 70
Session-ID: 83cea2a400105000a00000562bb4a040;remote=00000000000000000000000000000000
Date: Mon, 11 Dec 2017 10:30:08 GMT
CSeq: 2255 REGISTER
User-Agent: Cisco-CP8851/11.7.1
Contact: <sip:cf7470a0-f89d-9477-b400-18aa9f4fa2c5@10.102.134.192:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00562bb4a040>";+u.sip!devicename.ccm.cisco.com="SEP00562BB4A040";+u.sip!model.ccm.cisco.com="684"
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Content-Length: 0
Expires: 0

*Dec 11 10:07:47.437: //2731403/F8EC8FCC977D/SIP/Msg/ccsipDisplayMsg:
Sent:

VGIPT37501#SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.102.134.192:5060;branch=z9hG4bK03f39fd6
From: <sip:+12124186654@10.102.135.254>;tag=00562bb4a04000076ae5e209-4d2ac6ea
To: <sip:+12124186654@10.102.135.254>;tag=1A07B0BC-1A06
Date: Mon, 11 Dec 2017 10:07:47 GMT
Call-ID: 00562bb4-a0400004-0010488b-43922018@10.102.134.192
Server: Cisco-SIPGateway/IOS-15.2.4.M6
CSeq: 2255 REGISTER
Content-Length: 0

Thanks in advance.

permalldnit · ‎12-11-2017

I did reply to this earlier but nothing seems to have been saved. I am not going to be able to add the debugs now till tomorrow as the branch office now has people in and working, however, I can add as much as possible.

In answer to all of the questions:

1) We have waited hours for the phones to come out of SRST more than 24 hours

2) Firmware is currently sip88xx.11-7-1ES-11

3) When the link returns the phones do not say "CCM CallFallBack"they appear to be reregistered with the Call Manager, however, they are not and Call Manager shows them as "Unregistered"

4) Call Manager can ping those "Unregistered" see below

admin:utils network ping 10.102.134.196
PING 10.102.134.196 (10.102.134.196) 56(84) bytes of data.
64 bytes from 10.102.134.196: icmp_seq=1 ttl=60 time=1.37 ms
64 bytes from 10.102.134.196: icmp_seq=2 ttl=60 time=1.35 ms
64 bytes from 10.102.134.196: icmp_seq=3 ttl=60 time=1.38 ms
64 bytes from 10.102.134.196: icmp_seq=4 ttl=60 time=1.43 ms

--- 10.102.134.196 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3013ms
rtt min/avg/max/mdev = 1.357/1.388/1.433/0.028 ms

admin:utils network ping 10.102.134.136
PING 10.102.134.136 (10.102.134.136) 56(84) bytes of data.
64 bytes from 10.102.134.136: icmp_seq=1 ttl=60 time=1.54 ms
64 bytes from 10.102.134.136: icmp_seq=2 ttl=60 time=1.56 ms
64 bytes from 10.102.134.136: icmp_seq=3 ttl=60 time=1.34 ms
64 bytes from 10.102.134.136: icmp_seq=4 ttl=60 time=1.39 ms

--- 10.102.134.136 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3015ms
rtt min/avg/max/mdev = 1.344/1.460/1.563/0.094 ms

admin:utils network ping 10.102.134.140
PING 10.102.134.140 (10.102.134.140) 56(84) bytes of data.
64 bytes from 10.102.134.140: icmp_seq=1 ttl=60 time=1.64 ms
64 bytes from 10.102.134.140: icmp_seq=2 ttl=60 time=1.50 ms
64 bytes from 10.102.134.140: icmp_seq=3 ttl=60 time=1.44 ms
64 bytes from 10.102.134.140: icmp_seq=4 ttl=60 time=1.30 ms

--- 10.102.134.140 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3015ms
rtt min/avg/max/mdev = 1.301/1.472/1.640/0.122 ms

admin:
admin:utils network ping 10.102.134.135
PING 10.102.134.135 (10.102.134.135) 56(84) bytes of data.
64 bytes from 10.102.134.135: icmp_seq=1 ttl=60 time=1.80 ms
64 bytes from 10.102.134.135: icmp_seq=2 ttl=60 time=1.58 ms
64 bytes from 10.102.134.135: icmp_seq=3 ttl=60 time=1.24 ms
64 bytes from 10.102.134.135: icmp_seq=4 ttl=60 time=1.56 ms

--- 10.102.134.135 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 1.245/1.550/1.800/0.198 ms

admin:utils network ping 10.102.134.134
PING 10.102.134.134 (10.102.134.134) 56(84) bytes of data.
64 bytes from 10.102.134.134: icmp_seq=1 ttl=60 time=1.57 ms
64 bytes from 10.102.134.134: icmp_seq=2 ttl=60 time=1.57 ms
64 bytes from 10.102.134.134: icmp_seq=3 ttl=60 time=1.69 ms
64 bytes from 10.102.134.134: icmp_seq=4 ttl=60 time=1.66 ms

--- 10.102.134.134 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3017ms
rtt min/avg/max/mdev = 1.575/1.628/1.698/0.067 ms

5) If I run show call-manager-fallback licesnes I can still see the licenses being used (see attached file)

Thanks in advance for your help,

Glenn

permalldnit · ‎12-11-2017

Attached is what the Call Manager shows

permalldnit · ‎12-11-2017

Just to be clear the 2 attached screen dumps are from different days. Today I only put 8 phones into SRST. The other day I put the whole office into SRST and 58 phones held onto their licenses.

Tomorrow I will put some of the phones into SRST again and attached the debug logs.

permalldnit · ‎12-11-2017

Below is hopefully all the voice gateway config we are using for SRST to work

voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
h323
sip
registrar server expires max 600 min 60

voice register global
system message "375 fallback mode"
max-dn 300
max-pool 58

voice register pool 10
id network 10.102.134.0 mask 255.255.254.0
dtmf-relay rtp-nte sip-notify
codec g711ulaw

sip-ua
registrar ipv4:10.102.135.254 expires 3600

call-manager-fallback
max-conferences 8 gain -6
transfer-system full-consult
keepalive 120

Georgios Fotiadis · ‎12-11-2017

Enable web access for all phones and when recovering from SRST click on the IP address of one of the unregistered phones. Look for the Active CallManager server. If your CUCM is the active server then restart "RIS Data Collector" from Serviceability->Network Services.

If SRST gateway is the Active server, then you simply haven't recovered to CUCM.

You can also verify from the SRST gateway, which phones are still registered on SRST: show voice register pool all

Georgios
Please rate if you find this helpful.

permalldnit · ‎12-11-2017

How do I enable web access? If I click on the IP address of the phone at the moment it doesn't like it so I am assuming this will not work in SRST.

I will run through the rest tomorrow morning when I test SRST again.

Georgios Fotiadis · ‎12-11-2017

When the phone is registered on CUCM, go under Device Configuration. Look for Web Access.

Georgios
Please rate if you find this helpful.

permalldnit · ‎12-11-2017

Ok thanks, I have done this on one of the phones and I am now able to get to the Device Info via the IP. I will get this all done prior to the test tomorrow morning.

permalldnit · ‎12-11-2017

So now the SRST debug is showing in the ticket. In case it was missed here it is again below:-