CUCM 11.5(S3) Vs 11.5(SU3a)

[Gordon Ross]

What's the difference between SU3 & SU3a? I can't see anything obvious in the release notes. (In fact, the release notes only seem to talk about SU3)

[Jitender Bhandari · Accepted solution]

Hi Gordon,

Traditionally people would feel SU are safer than ES, i think one of the major reason for that is SU goes through more rigorous testing while ES is more focused to fixing some specific broken code. Both SU3 & SU3a are spun of Base ES: 11.5.1.13032-3. We had to come up with 11.5(SU3a) because of the below Critical BUG introduced by 11.5(S3).

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf96778/?reffering_site=dumpcr

In bonus you also get two other BUG fixes in SU3a which are CSCvb43321 and CSCvf88802. No other reason for 11.5(S3)

Now see both relese notes

https://www.cisco.com/web/software/282074295/139049/cucm-readme-1151su3-Rev3.pdf

https://www.cisco.com/web/software/282074295/139933/cucm-readme-1151su3a-Respin.pdf

(Rate if it helps)

JB

[Gordon Ross]

Is BugID CSCvf88802 the one that was fixed by the ciscocm.APNS_PushFailure_v1.0.k3.cop.sgn file?

Thanks,

[Jitender Bhandari]

Hi Gordon,

I dont think so see below .

https://www.cisco.com/web/software/286319173/139477/CUCM_11.5.1-CSCvf57440-COP-Readme-Rev2.pdf

What this COP file provides:
This COP file makes the required changes to address the following issue:

CSCvf57440 - No push is sent to devices during rapid link OOS and link ISV between nodes

BugID CSCvf88802 is basically caused when jabber device registers with an active call at its shared line, an unexpected Db Change Notification which causes Jabber device to reset in mid of the registration process, eventually leading to CCM core. it would generate a backtrace line below.

backtrace - CUCM
===================================
#0 operator= (this=0xe440a950, s=...) at ../Include/TDCLLineControl.hpp:599
#1 LineControl::restart0_LmSyncCallReq (this=0xe440a950, s=...) at ProcessLineControl.cpp:3557
#2 0x09f5e1cf in SdlProcessBase::inputSignal (this=0xe440a950, rSignal=0xe3846900, traceType=SdlSystemLog::SignalRouterThread, highPriority=0, normalPriority=0, lowPriority=0, veryLowPriority=0, lazyPriority=0, dbUpdatePriority=0) at SdlProcessBase.cpp:406
#3 0x09f62966 in SdlRouter::callProcess (this=0xc3d5c90, _sdlSignal=0xe3846900, _deleteSignal=@0xed23f2ff, _traceType=SdlSystemLog::SignalRouterThread, _hp=0, _np=0, _lp=0, _vlp=0, _lzp=0, _dbp=0) at SdlRouter.cpp:257
#4 0x09f62c10 in SdlRouter::scheduler (this=0xc3d5c90) at SdlRouter.cpp:164
#5 0x09f6310f in SdlRouter::schedulerInit (sdlRouter=0xc3d5c90) at SdlRouter.cpp:107
#6 0xf68d2bc9 in start_thread () from /lib/libpthread.so.0
#7 0xf69d404e in clone () from /lib/libc.so.6
==================================

11.5(SU3a) addresses this BUG also.

(Rate if it helps)

JB