[Asterisk-Dev] Input and testing.

[Brian West]

The SDP has nothing to do with this.  The SDP doesn't even report the rtp
frame length.  RTP is just RTP no matter the size. Asterisk deals with
inbound 100ms frames or any other variation I threw at it. I think the only
exception to this is SPEEX which needs out of band means to tell the frame
sizes that will be sent if you pack more than one in a packet.  ILBC has two
restrictions on putting more than one frame per RTP packet which is you
can't mix 20ms and 30ms frames in the same packets and you can't exceed the
MTU per packet.

As far as exposing this to the channel driver I'm not even going to attempt
it without someone with some say giving me an approved approach.  I'm not
going to spend time trying to solve the same problem three different ways.
I was thinking of adding a param to ast_rtp_write.

If you can provide me an approach that would make it in CVS I will follow
that path to completion.

Thanks,
Brian


On 9/5/05 9:09 PM, "Kevin P. Fleming" <kpfleming at digium.com> wrote:

> Well, there is actually a bigger issue... if you don't expose this to
> the channel drivers, then they can't request that the peer act in the
> same way. The result of that would be Asterisk sending 60ms per frame
> (for example), but the peer continuing to send 20ms per frame. Also,
> it's possible (but not highly likely) that some RTP peers will not be
> able to accept frames with more audio than they are expecting, if the
> SDP did not tell them we planned on doing that.