All,
I am facing a very strange issue with MoH on CUCM 9.1.2..
Here is the scenario:
PSTN------->CUBE (g711alaw)------SIP---->CUCM------->Cisco Jabber---->Call Forward to a Hunt Pilot
If I enable Hunt Pilot 'Call Queuing' and specify a Music on Hold Server Source, as soon as someone queues, they get disconnected due to a codec mismatch between g711alaw and g.729.
From the SIP traces at CUBE, CUCM is disconnecting the call with cause code 47... and a 503 Service Unavailable..
If I enable Announcements through the Music on Hold Audio Source Configuration, they work fine with no issue... so the issue is specific to MoH.
Service Parameters under IPVMS show g711ulaw/g711alaw and g.729 in place on all nodes
=======================================================================
The CCM traces show the following:
72798575.011 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::preCheckCapabilities, caps mismatch! Xcoder Reqd. kbps(8), filtered A[capCount=0 (Cap,ptime)=], B[capCount=6 (Cap,ptime)= (9,60) (11,60) (12,60) (15,60) (16,60) (19,60)] allowMTP=0 numXcoderRequired=1 xcodingSide=1
72798575.012 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::prepareInitialConnectionList, Party1CapCount=1 Party2CapCount=21 XcoderRequired=1 xcodingSide=1 allowMTP=0
72798575.013 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::AllocateXcoderandMTPWithZeroSavedConnection
72798575.014 |09:00:16.418 |AppInfo |DET-MediaManager-(765981) - isIpv6CapableMTPNeeded(0) ipAddrMode(0 2) mtpside(0)
72798575.015 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::useIntermediaDeviceForDTMF, useforDTMF (1)
72798575.016 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::AllocateXcoderOnSide1WithZeroSavedConnection dtmf ipv6 mtp(3 0)
72798575.017 |09:00:16.418 |AppInfo |SIG-MediaManager-(765981)::handleAuConnectRequest, connCount=2
72798575.018 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::checkAudioPassThru, param(bPostMTPAllocation=0,chkTrp=1), capCount(1,21), mtpPT=1, aPT=2
72798575.019 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::allocateProxies, j=0 XferMode(16 0) CI(35794125 0) mrid(0 0) resrcCI(0 0)
72798575.020 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::allocateProxies, connCount=2, party1 mrid=0 party2 mrid=0, j=0, party1MediaRequire=2 party2mediaRequire=0 Device reqd: None
72798575.021 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::getCapsAndRegionForBothSides, entryInList=0, connCount=2
72798575.022 |09:00:16.418 |AppInfo |DET-MediaManager-(765981)::sendMTPXcoderAllocationRequest, (CapCount,Region),SideA:(1,SIP_TRUNK_REG), SideB:(21,Default), supressMatchCap=0,MTPNeededForDTMF=3
=======================================================================
Another key part of the trace where things seem to lean towards the Default Region: (Parking Lot? Hunt Pilot Queuing?)
72798538.000 |09:00:16.416 |SdlSig-I |CcRegisterPartyB|wait|Cc(2,100,213,1)|ParkingLotCdpc(9,100,112,31)|2,100,238,1.130903^10.70.80.32^*|[R:N-H:0,N:1,L:0,V:0,Z:0,D:0] CI=35794130 CI.branch=150995101 CSS= AdjunctCSS= cssIns=0 aarCSS= aarDev=F FQDN=pi=0si1 CallRef=0 OLC=1 Name=locale: 1 Name: VoiceConnect UnicodeName: pi: 0 encodeType=10 qsig-encodeType=10 ConnType=2 XferMode=18 ConnTime=3 nwLoc=0IpAddrMode=2 ipAddrType=2 ipv4=1.1.1.1 ipv6=.... region=Default capCount=21 devType=1 mixerCId=0 mediaReq=0 portToPort.loc=0 MOH.MRGLPkid= MOH.userHoldID=0 MOH.netHoldID=0 MOH.supp=T devName=ParkingLotDDevice ctiActive=F ctiFarEndDev=0 ctiCCMId=0 devCepn= lineCepn= activeCaps=0 VideoCall=F MMUpdateCapMask=0x3e MMCap=0x1 devCap=0 CryptoCapCount=0 secure=1 loginId= UnicodeName: retriedVideo=FFromTag=ToTag=CallId= UAPortFlag=F wantDTMFRecep=1 provOOB=0 supp DTMF=3 DTMF Cfg=1 DTMF PT=0 DTMF reqMed=1 isPrefAltScript=F cdpnPatternUsage=0 audioPtyId=0 doNotAppendLineCSS=F lrg= BCUpdate=0 ccBearCap.itc=0 ccBearCap.l=0 ccBearCap.itr=0 protected=1 flushCapIns=0 geolocInfo=null locPkid= locName= deductBW=F fateShareId= videoTrafficClass=0 bridgeParticipantID callingUsr= remoteClusterID= isEMCCDevice=F dtmCall=F dtmPrimaryCI=0 dtmMediaIFPid=(0,0,0,0) dtmMcNodeId=0 emc=T QSIGIMERoute=F eo=0 eoUpdt=1 honorCodec=F honorUpdt=1 finalCalledPartition= cTypeUpdt=0LatentCaps=null icidVal= icidGenAddr= oioi= tioi= ptParams=
The Regions from the CUBE SIP Trunk and the CUCM show as follows:
RegionA=SIP_TRUNK_REG CapA=1 RegionB=Default
I have no idea why the Default Region is involved also! Ideally we don't want to use an XCODER...
The SIP Trunk and MoH servers are in the same Device Pool...
Any ideas?
Thanks
D
