Summary:ASTERISK-08169: Wrong ptime cause no audio
Reporter:Lennon Lim (lennon)Labels:
Date Opened:2006-11-21 12:14:22.000-0600Date Closed:2011-06-07 14:02:45
Versions:Frequency of
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

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:

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.