JT Thanks for this detailed response. It's clear I have some more homework to do before going anywhere near Mantis, but I will follow up either way.
Regards, Richard On Tue, Oct 28, 2008 at 9:02 PM, John Todd <[EMAIL PROTECTED]> wrote: > > This seems like a transcoding issue, and the RTP code may not be > clever enough to understand that a repacketization is "transcoding" > and therefore lets the media flow directly and/or passes the RTP > packets through without examining or modifying them. This could be an > error in the way RTP transcoding is handled - put on your superhero > bugtracking cape and post to Mantis! > > I'd suggest that you document this clearly, and put it on the > bugs.digium.com system if you've tried all possible iterations of > allow= and deny= for getting this media to transcode. It would seem > that "alaw:20" is different than "alaw:40", and if you've found that > they are treated as equal then there seems to be a problem. While not > explicitly stated in the "doc/rtp-packetization.txt" file, it does > seem that several things are true: > > - it seems that if a remote sender is sending 40ms packets, and you > have not explicitly denied 40ms packets, that Asterisk should accept > those packets. This seems to work. > > - if you explicitly have "deny=all" and then "allow=alaw:20" in a > peer definition, it should be the case that Asterisk takes whatever > audio stream and transcode it for the remote peer in that format (and > in the SDP Asterisk should offer a ptime and maxptime based on the > default and highest ptime acceptable, in this case "20" for both.) > Is this broken? > > - if a remote host sends you a ptime that is not defined or > defaulted in the list of "allow=" codec choices for that peer (or > globally) then the call should be refused just like it would be with > any other codec mismatch. (Of course, if you don't have a "deny=all" > as the first statement in your peer codec list, Asterisk should let > anything through since that's the way those ACLs work. I mention this > only as a caution for reporting problems that might not be problems.) > Is this broken? > > > This problem is actually fairly important when we start talking about > "scale". All RTP-based systems start to experience bottlenecks > introduced by Packets-Per-Second limits on hardware interfaces. The > upper limit of performance starts to be more bound to throughput on > interfaces and kernel drivers, rather than in the higher-layer code. > PPS, not megabits per second, becomes the number to beat. If you can > get RTP packets to go from 20ms to 40ms, it doubles the size of the > packet and effectively halves the number of packets you're sending on > your interface, which _could_ lead to doubling of total numbers of > calls as the limits of interface buffering are reached in the near > future. Even if you're just doing this on one leg of a looped call, > this still could reduce your overall PPS by 25%, which is nothing to > sniff at. Of course, I'm assuming that the load introduced by re- > packetizing different packet delays is not significant - this could be > a false assumption. > > JT > > > --- > John Todd > [EMAIL PROTECTED] +1-256-428-6083 > Asterisk Open Source Community Director >
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
