Internal Conference call not working

[brettlee77]

We are trying for a conference call internally. As soon as we add 3rd user for a conference , call drops.

Issue is with jabber as well as ip phone as well. We have checked below :

1. Each device has been assigned with MRGL.

2. MRG has the conference media resource added.

3. Conference media resource is registered with the CUCM and we also tried to reset it.

4. Device pool and region setting as expected and is same for MRGL and users.

While checking call logs I can see Conference resource is being triggered and receiving below error code:

Destination Device Name: CFB_5
Destination Disconnect Cause Location: 0
Destination Disconnect Cause Code: (458752) Drop any party/drop last party
Destination IPv4 Address: 10.64.58.11
Destination IPv6 Address:
Destination Call Leg ID: xxx
Destination Node ID: 5
Destination Span: xxx

CFB_5 is the conference media resource . I am also attaching the call manager logs.

Calling Number - xxx

Called Number 1 - xxx

Called number 2 - xxx

[Elliot Dierksen]

Is the MRG containing the CFB assigned to the MRGL for the devices? Are all the phone in the same device pool/region? What are the inter-region and intra-region codecs assigned?

[brettlee77]

Yes, it is assigned to the devices. All the devices in same pool/region.

We have system default setting for codec , but can you tell me exact where I need to check these?

[Elliot Dierksen]

Upon further review, what kind of conference bridge are you trying to use? I suspect it is the IP Voice Streaming Media one from CUCM. That only supports G.711. See the list of codecs in the SDP from one of your jabber devices.

v=0
o=Cisco-SIPUA 21389 1 IN IP4 10.244.247.248
s=SIP Call
b=AS:4000
t=0 0
a=cisco-mari:v1
a=cisco-mari-rate
m=audio 18446 RTP/AVP 114 111 101
c=IN IP4 10.244.247.248
a=rtpmap:114 opus/48000/2
a=rtpmap:111 x-ulpfecuc/8000
a=extmap:14/sendrecv http://protocols.cisco.com/timestamp#100us
a=fmtp:111 max_esel=1420;m=8;max_n=32;FEC_ORDER=FEC_SRTP
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=inactive
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
m=application 0 UDP/BFCP *
c=IN IP4 0.0.0.0
m=application 58942 UDP/UDT/IX *
c=IN IP4 10.244.247.248
a=ixmap:11 xccp
a=setup:active
a=fingerprint:sha-256 96:B5:29:1B:D9:FF:B2:C5:DA:E1:DD:F7:4E:8C:3D:C5:C9:B4:17:A3:0A:A1:71:CC:6E:AE:E6:FC:9E:45:C9:84
a=inactive

 These are the only ones you need to support if you are going to use the CUCM software CFB.

a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000

[brettlee77]

Thanks for your analyse , we are using 

Cisco Conference Bridge Software

[brettlee77]

In the codec preference list , I can see we have all the codec listed. Do you think this can be the issue?

[Elliot Dierksen]

No, I suspect it might be something in the Jabber config. Can you create a 'meet me' conference number and see if you can connect to the conference bridge that way? I would start with hard phones only.

[brettlee77]

Thanks Elliot but I’m afraid that I can create a meet me number because we are in the change freeze currently. 
also all I even checked the Jabber config , Conference having issue with hardphone as well.

but I will see if anything can be done on your recommendation.

[brettlee77]

Hello Elliot ,

just one observation here, when we setup a call between 2 parties , on Jabber packet capture window (the window we get after pressing control. + Shift + S ) I can see opus Codec is being negotiated. As per document for software conference it has to be g711 , Do you think it might be because of this ? Shall we change the Codec preference ? 

[Elliot Dierksen]

I would like to see the call manager logs when you attempt a conference with hard phones. I would just be speculating without that detail.

[Maren Mahoney]

You made an edit to your original post today, hopefully this means you have additional information we can use to help you. Can you tell us what you edited?

I do agree with Eliot that the most likely issue with establishing a conference call is inability to negotiate a codec. I take it that you are using the Software Conference Bridge built into your subscriber, and that this is the conference bridge built into the system. I can think of ways to test this theory, but it would take changes to the configuration. 

Instead, if you can provide the CUCM trace file from the subscriber providing the conference bridge that includes the attempt to create a conference we can probably identify the problem.

Maren

[brettlee77]

Hello Maren,

appreciate your help. No I could not solve the issue. However when we forced hardware conference it worked .

im still figuring out what is causing the issue . I have attached the CUCM trace

[Maren Mahoney]

I don't see an attachment? -- Maren