Cisco Bug: CSCuj58620 - CUCM sending wrong DTMFProfile in SDPAnswerInd
Jul 24, 2017
- Cisco Unified Communications Manager (CallManager)
Known Affected Releases
Symptom: Callflow: ===== PSTN Caller > Telco(Sonus) >CUBE >SIP Trunk >SME (220.127.116.1110-1) >SIP Trunk >Leaf Cluster (18.104.22.16886-1) >E1 QSIG > IPC Turret PBX ++ Initial EO Invite received from CUBE had Unsolicited Notify + 2833. SipCdpc850438 advertised DTMF SupportedMethod as 2833 only to CC. ++ Due to MTP allocation in leaf cluster, the DTMF caps received in the SDPAnswer by this SIPCdpc has both 2833+kpml. ++Due to older IOS load used in the deployment, the above SDP received from leaf cluster is SendOnly. This SO answer is sent to CUBE in 180. SME also sent RecvOnly SDP in PRACK to leaf cluster. ++Then ports are opened on MTP in leaf cluster and leaf cluster sent Update with MTP's ip and port info in SendRecv mode. SIPCdpc(850438) received following SDPOffer due to this. ++ Then SIPCdpc(850438) generated SDPAnswerInd. At this point SIPCdpc add OOB to DTMFMethod by itself even if CUBE never advertised kpml? This caused unnecessary DTMFProfile change in leaf cluster. Conditions: ++ when the media changes during the call because of MTP.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases