JT Once again thanks for the help on this. I have found the issue, which was, as they say, "carbon based".
I was getting mixed up because the default setting allow=alaw, is displayed as follows when I do "sip show user xxxx": Codec Order : (ulaw:20,alaw:20,g729:20) which I thought was equivalent to having allow=alaw:20, but it is not. Setting the ACLs to alaw:20 explicitly as you described has fixed this issue. W.r.t. you comment: > and in the SDP Asterisk should offer a ptime and maxptime I must add that I could not get Asterisk to send a maxptime in the SDP, nor can I find any instance of "maxptime" in the Asterisk source code (version 1.4.18 so it may have since been added). Thanks again! Richard On Tue, Nov 11, 2008 at 11:29 AM, Richard Brady <[EMAIL PROTECTED]> wrote: > 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
