[cisco-voip] CCM Trace Questions | MediaMgr

Daniel Pagan dpagan at fidelus.com
Tue Oct 15 13:30:56 EDT 2013


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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131015/f0682c90/attachment.html>


More information about the cisco-voip mailing list