[cisco-voip] CCM Trace Question || MediaManager & PTime

Wes Sisk (wsisk) wsisk at cisco.com
Wed Jul 16 09:11:44 EDT 2014


+1. Wouldn’t be the first time I’ve thought wrong but I think of these values as the max msec supported for each codec. I always thought there was an interesting underlying assumption that devices could do less than the advertised max msec. i.e. this device support codec 12 with maximum of 60 msec per packet.


-Wes

On Jul 15, 2014, at 5:41 PM, Peter Slow <peter.slow at gmail.com> wrote:

I've always seen medimanager use msec in that second field.
in sip there are ptime and maxptime parameters, ptime is supposed to
be msec per packet in the context of SIP SDP, which is really where
that term comes from. i dont think i've ever seen anything handle
maxptime correctly. ptime tends to get treated as max ptime, meaning
that "if you told me you support 20 msec per packet, then sending you
10 msec pr packet should be okay.
This is almost a requirement, since various scenarios in a call can
cause a lower-volume packet to be sent. For instance, we've got a
ptime of 30 msec negotiated, and i hang up on you at 1 minute and 10
msec - I dont think a coder will insert 20 msec of silence, i beleive
you'd just expect to receive a from with one 10 msec sample in it.

Mediamanager is most likely (should) be showing you the ptime received
in media negotiation - not necessarily the CUCM defaults from CCM
service parameters. the "Enforce Millisecond Packet Size" and "Always
Use Preferred G.729 Packet Size For SIP Trunk Answers" service
parameters may have to do with whatever behavior you're seeing.

Is there something specific you're troubleshooting?

-Pete

On Tue, Jul 15, 2014 at 1:37 PM, Ryan Ratliff (rratliff)
<rratliff at cisco.com> wrote:
> I believe ptime is the number of frames per packet.
> 
> -Ryan
> 
> On Jul 15, 2014, at 10:28 AM, Daniel Pagan <dpagan at fidelus.com> wrote:
> 
> Folks:
> 
> 
> 
> Quick question on the preCheckCapabilities step for MediaManager. After a
> new MediaManager is created, I’ve often referred to the preCheckCapabilities
> line for determining codec and DTMF relay capabilities based on codec type
> numbers (Cap,ptime) and figured that ptime was simply the payload size in
> ms. While looking at a recent issue, I noticed that ptime didn’t exactly
> match up with packet time values specified in CCM service parameter
> settings. The environment was using default settings across the board for
> packet size in milliseconds, but advertised capabilities shown in
> preCheckCapabilities for an IP phone to IP phone call showed:
> 
> 
> 
> (Cap,ptime)= (25,40) (4,40) (2,40) (15,60) (16,60) (11,60) (12,60)
> 
> 
> 
> Here I’m seeing g.711 with a ptime value of 40 and g.729 with 60. In this
> environment, g.711 and g.729 is configured for 20 ms packet size. So for
> clarification, assuming my understanding is incorrect, can someone tell me
> what the ptime value represents? We also thought maybe maximum payload size
> in ms but service these values go beyond the allowable values in CUCM.
> 
> 
> 
> Thanks ahead of time!
> 
> 
> 
> - Daniel
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 

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




More information about the cisco-voip mailing list