CUP CUCM SIP Trunk

[askq2forum]

Hi, during the CUCM SIP TRUNK security profile the default port setting is 5060(SIP). When Configuring the SIP TRUNK for each CUP server the default destination port is 5070(Simple) - should theses be left that way or should both be either 5060 or 5070 (or perhaps it does not matter). When we change them to be the same we find Presence updates seem to be quicker, anyone seen similar or should we just leave be...cheers Jag.

[Tommer Catlin]

I tried flipping those around as well, I think it really does not matter as long as one is 5060 and one 5070. From CUCM to CUPS, they have to match of course or the SIP trunk does not work.

I thought I was having SIP issues, so I switched everything around (flipped 5060 adn 5070 around) and did not notice anything different, but then again, I was not looking directly at presence updates, etc.

[askq2forum]

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

[Tommer Catlin]

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?

[askq2forum]

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

[abcronin]

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

[Tommer Catlin]

how about the client version of CUPC

[abcronin]

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

[Tommer Catlin]

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

[abcronin]

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!!

[Tommer Catlin]

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

[abcronin]

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