[asterisk-dev] RTP/SDP for using unknown codecs

[Beñat Urteaga]

On 02/27/2012 Kevin P. Fleming wrote:

>     Asterisk 10 already supports signed linear at 32kHz sample rate.



>     If you really want to support this in Asterisk 1.8, it can be done;

>     adding support for a 'passthrough' codec is not terribly difficult. Do a

>     search through the Asterisk source tree for 'G719' (which is supported

>     in passthrough and record/playback modes in Asterisk 1.8) and you'll see

>     all the places that need to be touched.



Ok, I installed Asterisk 10 and as I needed to use conferences confBridge was definitely my tool. I configured the

Confbridge.conf file: for the default bridge type I set "internal_sample_rate=32000" so that the sample-rate at the

Conference would be 32kHz. However, when I started a conference call, there was no information about this in the

INVITE message. Wouldn't asterisk have to offer a dynamic payload type?

I just can see this:



      Media Description, name and address (m): audio 13800 RTP/AVP 3 0 8 101

            Media Type: audio

            Media Port:13822

            Media Protocol: RTP/AVP

            Media Format: GSM 06.10

            Media Format: ITU-T G.711 PCMU

            Media Format: ITU-T G.711 PCMA

            Media Format: DynamicRTP-Type-101

      Media Attribute (a): rtpmap:3 GSM/8000

      Media Attribute (a): rtpmap:0 PCMU/8000

      Media Attribute (a): rtpmap:8 PCMA/8000

      Media Attribute (a): rtpmap:101 telephone-event/8000

      Media Attribute (a): fmtp:101 0-16

      Media Attribute (a): ptime:20

      Media Attribute (a): sendrecv



It doesn't say anything about 32 kHz, so:

Is there something missing? Must I add anything else at the configuration files?

Or the internal_sample_rate has nothing to do with the audio codec?

Then, how is the payload type/codec negotiation done?



Thanks a lot!



Benat.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120301/9e188f28/attachment.htm>