CUCM Built in Bridge not sending SDP in Invite

[josephwilz]

I've got a system that I'm trying to use BIB to a recorder from Eventide on and can get everything to work on an air gapped system but on our live setup CUCM never sends the SIP/SDP in the Invite. I've tried both with using a MTP for the Trunk or the Phone's line. Also tried using Early offer support set to "Best effort (no MTP inserted) in the SIP profile that I'm using for the trunk to the recorder however I still never get any SDP in the invite. Again I've tried all these same setup's in an air gapped setup and have no problem getting the SDP data to get sent. The live system I'm working on is not something I setup from scratch so I'm hoping someone has some insight on settings that are elsewhere that are preventing SDP from being sent. My recorder sends back Q.850 reason 65 to CUCM without the SDP data.

v/r

Joe

[b.winter]

What's the problem, if the SDP is not already in the INVITE?
Delayed offer is a standardized mechanism and if your recorder doesn't support it, it is not applying to RFC.

Have you tried to set the early offer support to mandatory? Has the SIP trunk media resources assigned via MRG?
Have you checked the logs on the recording server, why it is refusing the call?

[josephwilz]

Well I see no option in the recorder to accept a delayed offer or any configuration for the offer as far as that goes. It is an Eventide NexLog DX if you've any experience with that. I don't really care if its adhering to RFC it's what I've got to work with so I need to make it work. I didn't write its code so don't blame me.

Yes I've tried setting early offer support to both best effort and mandatory. As for the media resources I've tried using a specific MTP assigned to the pool that the trunk is in, as well as a MRG that has the MTP in it. Again all these scenarios work on my test system.

As for the logs in the recorder I get a q.850 reason 65.

Thanks.

[b.winter]

I don't blame you in person. But if system A isn't following standards, why should system B be responsible to fix the problems?
If the recording server does shit, why is CUCM expected and should be able to fix it? That's what I was trying to say.

If you are sure to have the same settings, then maybe you need to compare the logs of a working and non-working scenario.
Maybe you can see a difference.

[Scott Leport]

Hi,

q.850 reason 65 might be related to a codec mismatch / negotiation issue. Might be as a result of the lack of SDP in the INVITE or possibly something else.

Might be worth also checking Region settings in any Device Pool's along the path to make sure that you're using the same codec end-to-end from phone through to recorder.

Also, not Eventide specific, but maybe there are a few things you can use out of this doc to help:

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200788-Call-Recording-Basic-Configuration-and-T.html

Also, this thread. Doesn't look like the exact same setup as yours (this post looks like what some other vendors in this space would call a "passive" installation, e.g. without a SIP trunk), but again codec related so might hold some weight, might not:

https://community.cisco.com/t5/ip-telephony-and-phones/cucm-to-voice-recorder-device-eventide-brand-model-nexlog-740/td-p/3309545

[josephwilz]

Sorry this has taken me a while to get back to. I have been thru both of the articles you mentioned more than a few times hoping to find something I've possibly missed, but to no avail. The second talking about the OPUS codec shows that the SDP data is getting sent again just with the wrong data. Using the RTMT on my air gapped system and on the live system again I see the SDP attached to the invite on the air gapped side. On the live side it never gets sent out. I guess that's why I'm thinking even though all these settings in the Cisco's guides and what not are all set correctly there has to be someplace in CUCM that can still override all those and just never send the SDP data out. I wish I could get it to even offer the wrong codec I feel like that would at least be progress but I cannot for the life of me get it to ever send anything.

Joe