Call legs CUCM

[ramziabdelhak]

Hi guys,

In a call between internal user " managed by CUCM " and external user " PSTN ", what is the corrects diagrame representing the call legs :

1-

                                  internal -User  <--> CUCM <--> Gateway <--> external-user

    OR,

                                   internal -User  <--> Gateway <--> external-user

the same question when a user checks its voice mail on CUC ?

Thanks in advance

[b.winter]

I would say, depends on what you are looking at: either Signaling or Media Stream

For Signaling, it would be your first "diagramm"
For RTP, it would be the second.

For Voicemail
Signaling: User <--> CUCM <--> CUC
RTP: User <--> CUC

[ramziabdelhak]

Sorry for my late "thanking you ",

But if it is so, why do we need a sip trunk between CUCM and CUC ? With a H323 gateway, i understand that CUCM will act as a call control agent only, but when there is a sip trunk, the call will flow via that sip trunk. The same apply when integrating IM&Presence server with CUCM, call from Jabber client will flow via the sip Trunk established beetween IM&Presence and CUCM.

Please Correct me if i am wrong

[Maren Mahoney · Accepted solution]

The SIP Trunk between CUCM and CUC provides the mechanism for the two to communicate about calls. If a call is to flow to CUC, it must pass to CUCM first as that (as you pointed out) is the Call Control Agent. So CUCM must have some way of informing CUC that a call is incoming and about the parameters of the call. This is what the voicemail integration is all about. CUCM and CUC can exchange this type of information via an SCCP integration or a SIP integration. When using a SIP integration, the connection between the two systems is a SIP Trunk.

If you think about an SBC being a call processing node (it doesn't manage devices, but does manage call legs based on programming), it is generally connected to CUCM via a SIP Trunk. Similarly CUC is also a 'call processing node' in that it takes in information about a call and based on its programming (and dial plan!) takes an action. So just like an SBC connects to CUCM to exchange call information, CUC also needs a connection to CUCM to exchange call information.

Does this help clarify? If not, please feel free to post follow-up questions!

Maren

[ramziabdelhak]

Never dreamed of a better explanation, thanks,

From what i understood, control informations will flow via the SIP Trunk, but what about the audio/vidéo Stream ? will travel via the Trunk of an end to end sessions has to be established ?, Lets say  i have a sip trunk with a Telephony provider and i dial an external number, will the call flow from : IP-PHONE --> CUCM --> SIP TRUNK --> Internet or the Ip-Phone will try to contact the verry final destination ?

[b.winter]

Per default media is always between the endpoints.
Phone to phone, phone to gw, phone to CUC, Jabber to phone, ...

[Maren Mahoney]

I am glad my explanation was helpful! I taught this stuff for about 15 years so it's nice to know I haven't lost my touch.

To answer your question: For a call between phones (so Phone-CUCM-Phone) the signaling passes between the endpoint and CUCM but the RTP Stream (media) will flow directly between the two devices. Ditto with SBC-CUCM-Phone - the signaling flows to/from CUCM, but the RTP will flow between the SBC and the Phone. So calls that roll to CUC for voicemail are no different. The signaling will flow to/from CUCM but the RTP will go directly between a phone and CUC or between the SBC (for an outside caller) and CUC.

That is the 'default' behavior at any rate. It is absolutely possible for firewalls, ALGs, or other routing policies that to modify that flow. Also, if an MTP (Media Termination Point) or other media resource (like a Transcoder or Conference Bridge) is part of the call the media will flow through the media resource and not directly between the source and target of the RTP stream.

In the case of an outbound call to a service provider, generally speaking the signaling between your SBC and the SP will also be the path of the media between your SBC and the SP. That is because of the direct point-to-point nature of the circuit. But the two things are independent from a flow standpoint.

Maren

[ramziabdelhak]

Thanks again,

But i have seen some configuration where the Call manager is establishing a SIP Trunk with an Internet-Telephony Provider Directly "not via SBC ", does it mean that a local caller endpoint needs to contacts the Provider directly  ? i thought it was kind of proxified by the server establishing the SIP trunk " in my case the CUCM ".

Note: I would love participating at your training session !!!! 

[Maren Mahoney]

First, it is NOT recommended for CUCM to every communicate directly with any external system for security reasons (along with a bunch of technical reasons). CUCM should communicate via an SBC, an Expressway, a SIP Proxy, or *something* and not direct.

But to answer your question, let me explain it this way:

SIP is a signaling protocol, as in "let's set up a call...okay" sort of exchange. A second protocol used in SIP-based calls is Session Description Protocol (SDP). SDP is used to set up the media stream for the call negotiated by SIP itself. SDP sets up the codec negotiation and IP and port numbers used for the media (among other things). The SDP exchange is embedded in the SIP exchange, but they negotiate different parts of the call.

So should there ever be a case where CUCM were to communicate directly with a service provider (**shudder**), the service provider would tell CUCM where it wanted CUCM to tell the endpoint to 'send' the media stream using the SDP portion of the message exchange. The service provider would likely require that the RTP flow through CUCM (like the SP to SBC connection) and CUCM could use an MTP for this purpose.

Maren

[ramziabdelhak]

Hi,

To be honest, That last answer made me finaly ties toghether every topics/info i knew about VoiP, now it makes a lot of sense,

Just a last question if it is not to much asked !!!, an MTP, can we describe it as the one exchanging the RTP stream with an endpoint ?

Thanks in advance

[Maren Mahoney]

A media termination point is a special beast in media resources. All other media resources (conference bridge, transcoder, music on hold, etc.) are there for the purpose of doing something with the media stream only. A media termination point is used any time you need to modify the signaling part of the call (with or without also modifying the media stream).

An example would be incompatible DTMF between two call legs. That call could flow through a software MTP such as the one provided by the IP Voice Media Streaming App service in CUCM, which would cause both call legs to terminate on CUCM and CUCM would act as a relay point. Once that happens, CUCM can interpret the DTMF signaling for each call leg independently and translate between the two. The RTP steam itself (the voice part) would also flow through the MTP on CUCM, but CUCM would not make any modifications to the payload of the RTP packets.

Another example would be transcompanding G711ulaw with G711alaw. That is another thing that a software MTP on CUCM can provide. Again, both call legs would terminate on the MTP provided by CUCM. CUCM would interpret the SIP/SDP signaling differences between the two call legs, but would also reinterpret the RTP packets so that the correct codec is sent to the correct call leg. Note that this is NOT transcoding (like G711 to G729), which is not provided by CUCM software MTPs. G711ulaw and alaw are close enough that CUCM make the calculations in software.

CUBEs use MTPs in large quantities. If you think of an MTP as the ability to terminate two independent calls and interwork them, that describes what a CUBE does. From CUCM's perspective a call that goes out via a CUBE terminates on the inside-facing interface of the CUBE and CUCM has no visibility beyond that. Ditto for the service provider. As far as they are concerned, the call ends at the outside-facing interface of the CUBE. The MTPs on the CUBE interwork the two calls, modifying the SIP signaling and 'unwrapping/rewrapping' the RTP packets so that they have the right IPs/Ports/Etc. on each of the two independent calls.

So in the case where you have a SIP Trunk directly to a service provider from CUCM, the SP would want ONE IP address (and maybe a specific port) to signal with and send RTP to. You'd pick a CUCM server for this purpose and have all call legs terminate on an MTP provided by CUCM, which would relay the call bewteen the SP and the phone and interconnect the two call legs. You can see why this is a super-bad idea....

One last note is that, as a general rule, MTPs will break video when CUCM is involved. If you have video calls you will want the RTP passing directly between the two endpoints or through a video-enabled bridge. If you have even two Jabber endpoints calling each other where an MTP is invoked, it will be an audio-only call.

Let me know if you have more questions! 

Maren

[ramziabdelhak]

Very clear thank you,

So an MTP is not able to proxify a video call.

Thanks Again Maren You have been of a great help to me