Preview Tool

Cisco Bug: CSCun42015 - SME sends 481 to Leaf after receiving PRACK

Last Modified

Nov 14, 2015

Products (1)

  • Cisco Unified Communications Manager (CallManager)

Known Affected Releases


Description (partial)

SIP: Intermittent call failure - SME sends 481 to Leaf after receiving PRACK
The SME cluster is running 9.1(2) and the Leaf cluster is running 8.6(2).

Before we get a CcAlert from the call control we get a SIPBeginMedia
55887612.000 |16:27:52.578 |SdlSig |SIPBeginMedia |inCall_proceeding |SIPCdpc(3,100,75,1356613) |SIPInterface(3,100,69,1107803) |8,100,13,707812.6045^^* |[R:N-H:0,N:4,L:0,V:0,Z:0,D:0] myId=185256736 PeerDTMFConfig=1 PeerDTMFMethod=1 PeerDTMFRfc2833PT=0 PeerDTMFWantDTMF=1 PeerDTMFProvideOOB=F VideoPref=F Tandem=F renego=F nAudio=0 ~nVideo=0 ~nApp=0 ~nT38Fax=0 ^nBFCPApp=0 ^nIXApp=0 DTMFMethod=0 DTMFConfig=1 RFC2833PT=0 wantDTMF=1 provideOOB=F keepAudiomLineForT38=F FCOffer=0 transID=0 mANATAddrPref=3Ip_Invalid negIpAddrType=2V4V6 MTPAllocated=0

Later when we get a CcAlert the media status in it is Connected (2)
55887641.000 |16:27:52.579 |SdlSig |CcAlertReq |inCall_proceeding |SIPCdpc(3,100,75,1356613) |SIPD(3,100,74,539) |8,100,13,707812.6045^^* |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=60565072 CI.branch=0 FDataType=0opId=0ssType=0 SsKey=0invokeId=0resultExp=Fbpda=F fac.fid=28 fac.l=29 fac.fid=28 fac.l=1 pi.piid=30 pi.l=2 pi2.piid=0 pi2.l=0 pi3.piid=0 pi3.l=0IpAddrMode=0 ipAddrType=0 ipv4= ctiActive=F ctiFarEndDev=2 ctiCMId=8 media=2 lPart= lPatt= lModNum=tn=0npi=0ti=1nd=87031717pi=1si3 lName=locale: 1 Name: HCL TEST PHONE UnicodeName: pi: 1 cName=locale: 1 Name: SCHMIDT ANDREAS UnicodeName: pi: 1 cn:ti=1nd=87064519pi=1si1 cVMbox= localPatternUsage=2 connectedPatternUsage=5 lCnPart=fcc8281c-5098-7b5d-27e5-fe68eef85ae1

SIPCpdc checks if the call is a Qsig call and instead of delaying the 180 ringing till we get a response from the Media layer, it just send out one right away.
55887641.026 |16:27:52.580 |AppInfo |SIPCdpc(1356613) - inCall_proceeding_CcAlertReq: waiting for media, will send a second 18X

Here the RSeq sequence number is RSeq: 601605448
Later when we get a SDPAnswer from the Media layer (100 mili seconds later)
55887684.000 |16:27:52.698 |SdlSig |SDPAnswer |inCall_proceeding |SIPCdpc(3,100,75,1356613) |SIPInterface(3,100,69,1107803) |8,100,162,1.17663710^^ |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] nAudio=1 stackIdx=1 audioCapCount=1 Caps[4(20)] port=18632 IP= ipAddrType=0 ipv4= SDPMode=0 mediaAttr=0x0 SP=F RTP=T SRTP=F idle=F QoS=FenabledMask=0rtcbFbCount=0LatentCaps=null ~nVideo=0 ~nApp=0 ~nT38Fax=0 ^nBFCPApp=0 ^nIXApp=0 DTMFMethod=1 DTMFConfig=1 RFC2833PT=0 wantDTMF=1 provideOOB=F keepAudiomLineForT38=F FCOffer=0 transID=0 mANATAddrPref=3Ip_Invalid negIpAddrType=2V4V6 MTPAllocated=0

SIPCdpc sends the 2nd 180Ringing with SDP and the RSeq: 601605449
The Rseq is bumped up by 1 (ccb->tx_sip_rseq++) each time CUCM sends out a Provisional message with Require: 100rel

Now when the leaf cluster responds back to the 1st 180 that we sent out
SME check for the following
return (sipRack->response_num == ccb->tx_sip_rseq &&
sipRack->cseq_num == ccb->rx_sip_cseq_invite &&
sipRack->method == sipMethodInvite);

Since SME sent two back to back 180 message ccb->tx_sip_rseq contains (601605449) whereas the PRACK we got from leaf has (601605448)
And hence send out a 481 response to the PRACK.

Yes this is a race condition on SME, that caused the 481.

We get CcAlert and SDP answer back to back in 100 mili second interval that causes CUCM to send two 180 ringing before we get a PRACK for the 1st one.
55887612.000 |16:27:52.578 |SdlSig |SIPBeginMedia
55887641.000 |16:27:52.579 |SdlSig |CcAlertReq
55887684.000 |16:27:52.698 |SdlSig |SDPAnswer
55887713.002 |16:27:52.760 |AppInfo | <<<<< PRACK

We should have waited for the PRACK before we send the 2nd 180 in this call flow.
 Looks like we wait for the PRACK response only if we are sending an OFFER in the 18X message.
But in this call flow since the OFFER is received in the Invite SME sends an ANSWER in the 180 Ringing, hence we do not wait before sending the 2nd 180 Ringing.
Additionally Qsig was enabled in this call flow.
Bug details contain sensitive information and therefore require a account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.