cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
277
Views
4
Helpful
2
Replies

Enable midcall signaling in CUCM n have CUCM IP in 200 SDP OK in c

jawadaliqamar
Level 1
Level 1

I have a SIP trunk from a third-party PBX to CUCM which has one way audio.

When SIP/SDP invite is sent to CUCM IP, we see a rogue RTP stream coming from IP phone directly to third-party PBX in Wireshark capture. This is even before we received 200 SDP OK from CUCM.

Then in 200 SDP OK CUCM passes the IP of this IP phone as connection information (c=) to third-party PBX. It seems this is causing one-way audio as third-party PBX may not be able to handle this connection information change.

What I want is for CUCM to not send any new connection information (e.g IP phone information in c=) to a third-party PBX.
Instead, when a SIP invite is sent from third party PBX to CUCM, CUCM should negotiate SIP/RTP with the third-party PBX itself and handle the communication with IP phone by itself separately.

Here is a snippet from the capture.

Third-Party PBX IP = 10.10.11.16

CUCM IP= 10.10.12.7

IP phone IP= 10.10.12.8

jawadaliqamar_0-1716215265339.png

Cheers,

Jawad

2 Replies 2

CM do not handle the media part of the call, that’s between the endpoints taking part of the call. What you need to have the call not flow directly between the endpoints is a MTP, Media Termination Point. CM can act as a MTP, but only up to a certain amount of simultaneous calls. If you need more you can use a router with DSP module to act as an MTP. All this said you might be better off if you where to use a SBC, for example a router with Cube functionality enabled, to act as the border controller between your CM and the 3:rd party PBX.



Response Signature


Scott Leport
Level 7
Level 7

As Roger rightfully points out, what you're seeing is how it works.

Also fundamentally, make sure you have IP routing / connectivity between the subnet your third party PBX is on and the subnet your CUCM & IP phones are on. If this isn't in place, enabling MTP (which I wouldn't recommend) isn't going to make any difference to the issue. The majority of one way audio issues are related to routing, NAT or firewall rules not allowing RTP port ranges.