Ross Finlayson
2003-Feb-22 05:02 UTC
[Asterisk-Users] A major limitation of Asterisk's RTP implementation
While looking through Asterisk's RTP code to try to figure out why it would not let me use the Speex codec via SIP, I discovered that it has a major limitation: It does not support codecs that use dynamic RTP payload types. Dynamic payload types are those for which there is no fixed, predefined mapping between RTP payload format code and codec name. Examples of such codecs are Speex, LPC10, AAC, and AC3; Asterisk cannot stream any of these using RTP. Such codecs are specified (in the SDP description) using a payload format code that's >= 96, and a "a=rtpmap:" line that maps each such payload format code to a codec name. For example: m=audio 7078 RTP/AVP 110 111 0 3 115 8 101 a=rtpmap:110 speex-4/8000/1 a=rtpmap:111 speex_lbr-4/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:3 gsm/8000/1 a=rtpmap:115 lpc10-1.5/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 The problem is that Asterisk's implementation does not handle "a=rtpmap:" lines at all, and so - in this example - can only handle PCMU, GSM, or PCMA, because for these codecs, the payload format code is known in advance. (The Asterisk code also has a hack for payload format codes 100, 101, and 121 - which it assumes will always be various forms of "telephone-event" (i.e., DTMF codes). This is very bad, because there's no guarantee that that's how these codes will always get used.) I am planning to go ahead and fix this, as I have a lot of experience working with SDP and RTP. But if anyone else is already working on this, please let me know, so we don't step on each other's toes. Ross. ps. Another problem with Asterisk's RTP implementation is that RTCP is not included at all. This makes it impossible to monitor - using standard RTCP analysis tools - the quality of RTP streams that Asterisk sends. The lack of RTCP is not as serious as the "a=rtpmap:" issue, but it does make Asterisk non-standards-compliant.