|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|
|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
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.