04-05-2009 06:08 AM - edited 03-18-2019 10:49 PM
CUPC,CUPS ver 7.0(2)
I keep seeing "SIP/2.0 408 Request Timeout" from CUPS.
Have tried/checked
server health = green
system dashboard = green
proxy domain = somedomain.com
CUPC can resolve FQDN of CUPS
Digest Credentials = user password
ACL = all
firewall (windows client) shut down
SIP proxy Authentication Module Status = off
Have not configured
Extension mobility
Dialing rules
IPPM shows "Due to unavailability of presence services at this time, presence status may not be working correctly. Please notify your system administrator."
SIP message from sniffer trace is attached.
CUPS = 192.168.0.10
CUPC = 192.168.0.8
Please help. Thanks in advance.
04-05-2009 08:14 AM
Hi,
Can you run the troubleshooter on CUPS to check that all your cnfgration is fine. If this is okay, then you should restart your sip proxy service on CUPS
04-05-2009 08:20 AM
Hey,
ANother thing you want to check is to use server health to check the status of your presence engine....On CUPC, use server health to check what presence is saying....
04-05-2009 10:04 AM
Try the following:
1) On CUPS servicecability page, set SIP Proxy and Presence Engine trace level to 'debug'
2) Restart Presence Engine and SIP proxy service and wait for 5 minutes.
3) Start packet capture on CUPS with the command below:
utils network capture file cups count 100000 size all host all 192.168.1.101
Where "192.168.1.101" is the IP address of CUPC.
4) Try to log into CUPC and recreate the problem.
5) On CUPS command line, press Ctrl-C to stop the capture
6) Use RTMT to download the following logs:
Cisco UP SIP Proxy
Cisco UP Presence Engine
Packet Capture Logs
Thanks!
Michael
04-06-2009 05:32 PM
04-06-2009 06:37 PM
any luck on the following logs?
Cisco UP SIP Proxy
Packet Capture Logs
Michael
04-06-2009 09:55 PM
Nothing special from the SIP proxy and packet capture from my perspective.
I just notice this error from the SIP proxy. It sounds like ACL not trust the CUCM and CUPC. But I have already configured both in ACL
04/06/2009 21:48:14.738 ESP|[Mon Apr 06 21:48:14 2009] [error] [client (null)] find_allowdeny: remote_ip == 192.168.0.8
[Mon Apr 06 21:48:14 2009] [error] [client (null)] client denied by server configuration: (null)
PID(16219) sip_sm.c(4454) ACL - upstream not trusted - need to authenticate
For the SIP proxy, it shows earliest "480 Request Timeout" at
04/06/2009 21:48:14.789 ESP|ID(16188) sip_sm.c(1165) Sent 297 bytes TCP packet to 192.168.0.8:34292
SIP/2.0 408 Request Timeout
This is not in the network capture. The earliest appearance for "408 Request Timeout" in network capture is at packet 436. The network capture has 15 seconds of gap in between 21:48:14 - 21:48:30
It seems to me the SIP proxy notices the problem and tries to route the request to another but fails
|<:STANDALONECLUSTER><:UP7-1><:ALL><:FFFF>
04/06/2009 21:48:38.587 ESP|Mon Apr 06 21:48:38 2009] PID(16203) sip_sm.c(234) sip_process_sendfail_msg a1f6c800-9da10839-c-800a8c0@192.168.0.8:101 connid 0 sock_fd 0 (3ba9cb:49da0836:49da0836)
|<:STANDALONECLUSTER><:UP7-1><:ALL><:FFFF>
04/06/2009 21:48:38.587 ESP|Mon Apr 06 21:48:38 2009] PID(16203) sip_sm.c(275) handling SIP TCP request send fail
|<:STANDALONECLUSTER><:UP7-1><:ALL><:FFFF>
04/06/2009 21:48:38.587 ESP|ID(16203) sip_sm.c(3238) cannot failover, no routes available
|<:STANDALONECLUSTER><:UP7-1><:ALL><:FFFF>
04/06/2009 21:48:38.587 ESP|Mon Apr 06 21:48:38 2009] PID(16203) sip_sm.c(289) No alternate nexthop available.
|<:STANDALONECLUSTER><:UP7-1><:ALL><:FFFF>
04/06/2009 21:48:38.588 ESP|ID(16203) sip_sm.c(1165) Sent 295 bytes TCP packet to 192.168.0.8:34292
SIP/2.0 408 Request Timeout
I have problem with the NTP and so the time is only accurate to seconds.
04-07-2009 03:15 AM
Michael, can you please check if I am hitting this bug CSCsv00031. I can't view its content. :)
And would this bug turns out to cause the problem I face?
From the log, epe00000029.txt
04/06/2009 21:18:40.231 EPE|PEOamInvalidInitialConfigFile - PE configuration file not found or malformed UNKNOWN_PARAMNAME:OamConfigFileUri:/usr/local/pe/cfg/pe_cfg.xml UNKNOWN_PARAMNAME:OamErrorMessage:ConfigModule: network element not in config data App ID:Cisco UP Presence Engine Cluster ID:StandAloneCluster Node ID:UP7-1|<:STANDALONECLUSTER><:UP7-1><:ALARM><:ALL><:FFFF>
04-07-2009 06:55 AM
Based on the logs, PE (Presence Engine) failed to start due to mis-configured configuration file.
Has the IP address or hostname of this CUPS box ever been changed?
Anyway, you need to open a TAC case for this. TAC engineer need to get to the root shell to fix the configuration file.
Regards,
Michael
04-07-2009 07:51 AM
Hostname has been changed. But I should say I followed the document.
I just upgraded to 7.0(3) and CUPC can go avaialble now :)
And I don't find any pe_cfg.xml in the PE debug. It seems ok now.
Thanks for leading me to the debug, Michael.
04-07-2009 08:01 AM
Glad to hear the problem was resolved.
There was a bug on 7.0.2. When you change the hostname, it didn't update the pe_cfg.xml.
Obviously, upgrade to 7.0.3 updated it.
Michael
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