Summary:	ASTERISK-08169: Wrong ptime cause no audio
Reporter:	Lennon Lim (lennon)	Labels:
Date Opened:	2006-11-21 12:14:22.000-0600	Date Closed:	2011-06-07 14:02:45
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sip.conf ( 1) sip-ptime.log ( 2) sip-ptime1.log
Description:	asterisk invite with worng ptime, it cause both site no audio. both site using g723 passthrough. attached config and log.
Comments:	By: Joshua C. Colp (jcolp) 2006-11-21 12:24:43.000-0600 The actual ptime value (30) is preserved so it's right. I assume you are talking about the extra information specific to g723 that is not preserved in sip-ptime.log? what's wrong with sip-ptime1.log? By: Lennon Lim (lennon) 2006-11-21 12:30:11.000-0600 ip phone-> asterisk -> cisco5300 sip-ptime.log is ip phone setup to asterisk, sip-ptim1.log is asterisk setup to cisco5300. the problem is asterisk send invite to cisco, ptime change to 20. By: Joshua C. Colp (jcolp) 2006-11-21 12:34:12.000-0600 That's because you have appear to have ulaw and alaw enabled, and 20ms is the most common between all three formats as you can only have 1 ptime. By: Lennon Lim (lennon) 2006-11-21 13:05:08.000-0600 ic, but i think this is a bug in asterisk. if asterisk got wrong ptime, it should change to defult value, but it seems no change and cause no audio. i debug rtp and only see rtp send to cisco and nothing send to ip phone. By: Joshua C. Colp (jcolp) 2006-11-21 13:07:18.000-0600 If you turn off ulaw and alaw does it work? By: Lennon Lim (lennon) 2006-11-21 13:08:55.000-0600 yes, it work. By: dea (dea) 2006-11-21 15:13:38.000-0600 This one is going to be a tad tricky.  The Cisco UA is sending the ptime= value on the a=fmtp:4 line.  Currently Asterisk looks for ptime= as a seperate element in the SDP. I haven't seen any documentation in the RFCs to say that the method Cisco uses is allowed.  It does make sense, as it would be the only way to setup per-codec framing, but I'm not sure it is valid. I would recommend turning on auto-framing to make Asterisk honor the Cisco UA, but that depends on ptime= being in a seperate element. You might be succesful with 'allow = g729:30,g723.1:30,ulaw:30,alaw:30' By: Lennon Lim (lennon) 2006-11-21 15:26:40.000-0600 this way work, thanks. By: Olle Johansson (oej) 2006-11-22 08:01:36.000-0600 DEA: As I have stated before, each payload definition has their own definition of how to set the packetization time. The way we do it now, assuming that we can use the a:ptime for all codecs, is wrong. We need to read each RFC with a payload definition. By: dea (dea) 2006-11-22 11:52:18.000-0600 OEJ- We can take this to the -dev list.  I've been trying to read up on the relevant RFCs so I can contribute intelligently, but I am finding this particular set of details is lacking in many documents. I did find that most codec specs/RFCs would document the acceptable framing sizes, but all codec reference documents seemed to leave it up to the signalling channel on how to communicate those values. RFC 4054 seems to indicate that we can include a per-codec framing option (ptime) in the a=fmtp: element.  RFC 3485 points to one and only one a:ptime element as a seperate element in the SDP. Most of the SIP traces I have seen either here or in my own testing show behaviour following 3485.  The log sip-ptime.log attached here shows a UA that appears to be following 4054. In any case, I am back to the RFCs and will post any new findings to the -dev list. By: Olle Johansson (oej) 2006-11-24 02:17:24.000-0600 DEA: Agreed, it's a big mess. To get back to this particular bug: m=audio 8002 RTP/AVP 4 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=fmtp:4 ptime=30;annexa=no;bitrate=6.3 We do not parse the fmtp header for this properly. There's a new branch called videocaps that will be able to do this, even though it focuses on video - but it's the same issue. There are two situations we need to handle - direct RTP setup (external audio p2p) and normal setup (through asterisk). By: Olle Johansson (oej) 2006-11-24 02:22:21.000-0600 Here's where we will find the reference for each payload format: http://www.iana.org/assignments/rtp-parameters Seems like there's no RFC for the G.732 registration. Bad. By: Olle Johansson (oej) 2006-11-24 02:30:01.000-0600 RFC 2327 (SDP): "   a=ptime:<packet time>       This gives the length of time in milliseconds represented by the       media in a packet. This is probably only meaningful for audio       data.  It should not be necessary to know ptime to decode RTP or       vat audio, and it is intended as a recommendation for the       encoding/packetisation of audio.  It is a media attribute, and is       not dependent on charset." Media attribute - one per SDP. By: Olle Johansson (oej) 2006-11-24 02:36:52.000-0600 Since we fixed the problem for the reporter and don't support the fmtp: headers yet, I'm closing this bug. Seems like the media level ptime is a standard header, which is good. But in some cases we need to add it in fmtp headers on codec level to be fully understood and handled by the other side, especially if we want different ptime for different codecs. There's already a branch trying to handle full capability negotiation by parsing the fmtp headers and handling all kinds of attributes, so let's continue there and on asterisk-dev.