[cisco-voip] CCM Trace Questions | MediaMgr

[Brian Meade (brmeade)]

Daniel,

It goes (node id, application id, process type, process instance).

Cdcc is Call-Dependent Call Control so this is a unique instance for a certain call.  Cc is call control and usually responsible for creating the Cdcc and tracking the call state from what I've seen for the most part.  I've never seen either directly talk to media processes that I can recall.

Brian

From: Daniel Pagan [mailto:dpagan at fidelus.com]
Sent: Monday, October 21, 2013 12:04 PM
To: Ryan Ratliff (rratliff); Brian Meade (brmeade)
Cc: cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] CCM Trace Questions | MediaMgr

One last question on this thread... Can you tell me the significance of the 3rd and 4th numeric values following a process name on SDLSig lines? The fourth value seems like the unique process ID number but I haven't been able to correlate the 3rd value with anything significant yet.

Also... If you cant disclose this information then I understand, but I'm also curious about the Cdcc and Cc processes. I often see the Cc and Cdcc processes involved in CTI line events. Are these two responsible for interfacing with media processes?

Thanks again

Daniel

From: Ryan Ratliff (rratliff) [mailto:rratliff at cisco.com]
Sent: Tuesday, October 15, 2013 3:45 PM
To: Brian Meade (brmeade)
Cc: Daniel Pagan; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] CCM Trace Questions | MediaMgr

Specific to MGCP you'll see delays there because even though the gateway generates an SDP in the Ack to the CRCX we don't use that info until media is established for the call.

To dumb this excellent discussion down a bit MediaManager is created when media negotiation has to happen between two call legs and this doesn't always happen at the same time one leg sends its media information.

The MXTimeout getting cancelled will be whenever we need to stop waiting for the media connection to be established. In general this happens when we have enough information from both call legs to proceed with establishing media or cancel the call because there are no matching capabilities.  It can also happen if one side disconnects the call during media negotiation (try H.323 over a satellite with slow-start and you'll see this a lot).

-Ryan

On Oct 15, 2013, at 2:11 PM, Brian Meade (brmeade) <brmeade at cisco.com<mailto:brmeade at cisco.com>> wrote:

To further expand on this from what I found, a new MediaManager process is created any time there is an AuConnectRequest unless the call was early offer in which this would have already been created.  AuConnectRequest is triggered by ConnPartyReq received by MatrixControl which seems to handle the logic of when to send the AuConnectRequest.  There's many, many reasons why one is made and one isn't and I can't just share every potential scenario but my previous comment should cover most of it.

From: Brian Meade (brmeade)
Sent: Tuesday, October 15, 2013 1:35 PM
To: 'Daniel Pagan'; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: CCM Trace Questions | MediaMgr

Daniel,

My understanding trying to not directly copy&paste CUCM source code is that a MediaManager process is created whenever an Media Offer is received that needs a corresponding Media Answer.  In the case of Prack being disabled, an answer wouldn't be necessary so we don't need to create a new MediaManager process for this.

Still going through the code to see when the MXTimeout  timer is turned off.  The problem is it's in a subroutine that gets called in a lot of different scenarios.  I'm trying to find a corresponding trace line that would print in a few of the scenarios.

Brian

From: Daniel Pagan [mailto:dpagan at fidelus.com]
Sent: Tuesday, October 15, 2013 1:31 PM
To: Brian Meade (brmeade); cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: CCM Trace Questions | MediaMgr

Brian:

Thanks for the answer.

Another question on MediaManager... Is a new MediaManager process created when very specific events are witnessed by CUCM? I guess another way to ask this would be, is it safe to say the creation of a new MediaManager process is initiated by specific events during the call, received by the outbound call-leg, and vary from protocol to protocol? I'm aware it's during the media connection attempt for two CIs, but I'm hoping to get some more detailed information.

Here's an example of what I'm referring to... Audio cut through (MediaMgr creation) occurs for outbound call-leg events such as:

CUCM <-- 183 w/ SDP
==PRACK is enabled==
==MediaMgr gets created, audio cut through is attempted==
CUCM --> PRACK w/ SDP

However, I don't see CUCM attempting audio cut through in the following scenario:

CUCM <-- 183 w/ SDP
==PRACK is disabled==
==MediaMgr is not created==
..
...
CUCM <-- 200 w/ SDP eventually received
==MediaMgr gets created, audio cut through is attempted==
CUCM --> ACK w/ SDP

Because MediaManager is created between the Rx 183 and Tx PRACK, and I see no creation after Rx 183 when PRACK is disabled, this makes me think that, at a programming level, the creation of MediaManager is tied to very specific events witnessed by CUCM combined with configurations on the called device. Something like this (forgive me... I'm no programmer... just trying to lay out my thoughts)

On the outbound leg, create new MediaMgr process and attempt media exchange:
IF (Received ISDN Msg = Progress){
Create new MediaManager Process
}
ELSE IF (Received SCCP Answer = True){
Create new MediaManager Process
}
ELSE IF (Received SIP Msg = 183 offer AND PRACK = enabled){
Create new MediaManager Process
}
ELSE Do nothing..

My apologies for the long winded email. Is this order of operations correct? I'm pretty much thinking while typing and trying to understand how this process is initiated by CUCM in a more detailed way than just "whenever it's time to establish audio".

Serious thanks you again if you made it to the end of the email :)

Daniel

From: Brian Meade (brmeade) [mailto:brmeade at cisco.com]
Sent: Tuesday, October 15, 2013 11:58 AM
To: Daniel Pagan; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: CCM Trace Questions | MediaMgr

Daniel,

For your second question, those capabilities are the equivalent SCCP capabilities.  Unfortunately, the SCCP codec mapping is technically Cisco confidential so I can't share that table.

Working on getting an answer on your first question.

Thanks,
Brian Meade

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Tuesday, October 15, 2013 11:16 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] CCM Trace Questions | MediaMgr

Hey Folks...

I have a few trace questions I'm hoping someone can help me with.

Is there a specific CCM trace entry that corresponds to the moment where the Media Exchange Timeout timer is stopped? From what I understand, the timer begins when a new MediaManager process is created for the AuConnect request, but there doesn't seem to be any obvious moment when the timer is stopped during a successful media connection. Would it be at the "AuConnectInfo, audio, CI (xxxxxx, xxxxxx)"? The purpose of having this would be to quickly identify the moment a successful media connection was established during situations where reviewing signaling transactions for media capabilities isn't exactly required.

With regards to MediaManager and its region capabilities pre-check, is there a matrix or any document that provides the capability numbering to codec mapping? I'm not referring to SDP dynamic payload mapping, but specifically the "preCheckCapabilities" line in a CCM trace.

Thanks a lot ahead of time.

- Daniel
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131021/4e58dd5f/attachment.html>