Tim,

thanks for your response, please elaborate on ' CUCM to CUPS, they have to match of course or the SIP trunk does not work' my SIP trunks do work but I think the updates are slow so presence info is not being presented straightaway. So I have the sip trunk security profile at 5060 and the sip trunk as 5070....thanks, Jag

So you are saying that when the client applicaiton is open, Presence of the CUPC is slow in responding? Example: CUPC client is "green" status. But when they pick up the phone it does not change to "on the phone" status (I think it's orange/yellow color).

Basically, leave as default the port numbers for SIP. If you are getting slow responses, it's probably not this. (although it does use this trunk to get presence information)

Check on your Incoming/Outgonig ACL configurations. Do you have any restrictions or is it set "all" in both?

acl set to all....thanks again,jag.

I am have a problem with presence status taking 10 - 15 seconds to update when it is changed on the CUPC client manually and also for the busy status, I have checked all the usual places and confirmed that SIP Publish is being used.

Running the latest versions on CUCM and CUPS, 6.1(2) and 6.0(3).

Any ideas for troubleshooting this?

Cheers

Andy

how about the client version of CUPC

Hi there

Sorry I didn't supply all info as I was in the middle of testing.

CUPC version is 1.2(2), have upgraded to 1.2(3) but with no change, I still have a 10 sec lag on any status change, I have added the log as an attachment which shows what is happening:

2008-07-16 12:02:15,640 [0x174] INFO LCPersonManager - (MWMSG_PMI_SETTINGPRESENCE) PersonManagerImpl::SetPublishState. status = away, message =

2008-07-16 12:02:15,640 [0x174] INFO LCMiddleware - (MWMSG_EIM_SETPERSISTENTSTATE) Set Persistent State requested

2008-07-16 12:02:15,875 [0x6c4] INFO LCMiddleware - (MWMSG_EIM_SETPERSISTENTSTATE) Set Persistent State succeeded

2008-07-16 12:02:16,140 [0x458] INFO LCMiddleware - (MWMSG_EIM_SETUSERPROPERTY) Set user property "Presence.inPersistentState" to "false"

!!!9 seconds later!!!

2008-07-16 12:02:24,703 [0x598] DEBUG LCIsuaLog - (WABIMSG_SDKMSG) CSuaCallControlManager.Singleton.Asynchronous::CSuaSIPEventClientSubscription::onUpdateActive[779] - NOTIFY client subscription id=64 [URI:acronin-contacts@demo.com] (presence)

2008-07-16 12:02:24,703 [0x598] DEBUG LCIsuaLog - (WABIMSG_SDKMSG) CSuaCallControlManager.Singleton.Asynchronous::CSuaSIPEventClientSubscription::ProcessIncomingNotification[1067] - client subscription id=64 [URI:acronin-contacts@demo.com] (presence)

2008-07-16 12:02:24,703 [0x598] DEBUG LCIsuaLog - (WABIMSG_SDKMSG) CSuaCallControlManager.Singleton.Asynchronous::CSuaSIPEventClientSubscription::ProcessIncomingNotification[1108] - Calling OnSIPNotify client subscription id=64 [URI:acronin-contacts@demo.com] (presence)

2008-07-16 12:02:24,703 [0x51c] DEBUG LCWabiPresenceSink - OnSIPNotify: subscriptionID=64, dialogId=69, state=1, contentType=multipart/related;type="application/rlmi+xml";boundary="9c7b64dc-303d-4d27-8";start=""

2008-07-16 12:02:24,703 [0x51c] DEBUG LCWabiPresenceSink - OnSIPNotify: sending 200 OK response to NOTIFY

2008-07-16 12:02:24,703 [0x51c] DEBUG LCCallbacks - UCPresence::OnPresenceNotification, state=1, dataLen=2372

2008-07-16 12:02:24,703 [0x51c] DEBUG LCPresent - User:sip:acronin@demo.com Rpid status:, UC status:5 AWAY, DeviceStatus 53

2008-07-16 12:02:24,734 [0x598] DEBUG LCIsuaLog - (WABIMSG_SDKMSG) CSuaCallControlManager.Singleton.Asynchronous::CSuaCallControlManager::RequestSendSIPNotifyResponse[4172] - shutting-down=0, client subscription id=64, dialog id=69, success=true, sip event manager=NOT-NULL

2008-07-16 12:02:24,734 [0x598] DEBUG LCIsuaLog - (WABIMSG_SDKMSG) CSuaCallControlManager.Singleton.Asynchronous::CSuaSIPEventManager::RequestSendSIPNotifyResponse[1533] - client subscription id=64, dialog id=69, success=true, SIP failed response code=200

Couple things to check.

On your CUPS, is the NTP source the same as your CUCM source? (making sure the time stamps are similar or close)

For the SIP Proxy, do you have "All" set in for the packets? Typically, I set this to "All" just to avoid any problems. This way, Presence will accept any incoming SIP packet no matter what. You can limit this later if you like.

Check out my other post here to see if anything works for you:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Unified%20Communications%20and%20Video&topic=Unified%20Communications%20Applications&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40^1%40%40.2cc049b9/0#selected_message

Thanks for the post, I have checked the ACLs and they are both set to 'all', NTP is ok and have looked at DNS as I saw some posts with people having issues with resolution.

I might change the naming to IP Addresses and see if that does anything.

I did some more testing and get the same issue with IM chats...they take around 40 secs to display.

Next stop is a TAC case I guess!!

yeah, strange. Im not sure. are you using a secondary Presence server? If you are, shutoff the second one and try again.

Hi all

I have this resolved now, it was a DNS issue.

The DNS server being used didn't have a reverse lookup zone configured, once I configured one all was good, updates and IMs were much faster.

Cheers

Andy