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

[Daniel Pagan]

Thanks and good points made. I think it's the most logical explanation - ptime representing max supported payload per packet in msecs. I previously didn't correlate this to the ptime media attribute in SDP so that's a good point as well. Looking at maximum packetization periods for an IOS hardware CFB matches up with the MediaManager ptime value for a call involving this resource, so that pretty much confirms your theory :)

There's nothing specific I'm troubleshooting at the moment that's related to this question... I've seen this CM trace entry for a while now and really only paid attention to the capabilities values. A media related case came my way and the "ptime" parameter in (Cap,ptime) piqued my interested again. Figured I try to get some clarification.

Thanks again

Daniel

-----Original Message-----
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Wes Sisk (wsisk)
Sent: Wednesday, July 16, 2014 9:12 AM
To: cisco-voip voyp list
Subject: Re: [cisco-voip] CCM Trace Question || MediaManager & PTime

+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


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