JT<br><br>Once again thanks for the help on this. I have found the issue, which was, as they say, "carbon based".<br><br>I was getting mixed up because the default setting allow=alaw, is displayed as follows when I do "sip show user xxxx":<br>
<br>Codec Order : (ulaw:20,alaw:20,g729:20)<br><br>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.<br><br>W.r.t. you comment:<br>
<br>> and in the SDP Asterisk should offer a ptime and maxptime<br><br>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).<br>
<br>Thanks again!<br><br>Richard<br><br><br><div class="gmail_quote">On Tue, Nov 11, 2008 at 11:29 AM, Richard Brady <span dir="ltr"><<a href="mailto:rnbrady@gmail.com">rnbrady@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
JT<br><br>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.<br><br>Regards,<br><font color="#888888">Richard</font><div><div>
</div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Tue, Oct 28, 2008 at 9:02 PM, John Todd <span dir="ltr"><<a href="mailto:jtodd@digium.com" target="_blank">jtodd@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div><br>
</div></div>This seems like a transcoding issue, and the RTP code may not be<br>
clever enough to understand that a repacketization is "transcoding"<br>
and therefore lets the media flow directly and/or passes the RTP<br>
packets through without examining or modifying them. This could be an<br>
error in the way RTP transcoding is handled - put on your superhero<br>
bugtracking cape and post to Mantis!<br>
<br>
I'd suggest that you document this clearly, and put it on the<br>
<a href="http://bugs.digium.com" target="_blank">bugs.digium.com</a> system if you've tried all possible iterations of<br>
allow= and deny= for getting this media to transcode. It would seem<br>
that "alaw:20" is different than "alaw:40", and if you've found that<br>
they are treated as equal then there seems to be a problem. While not<br>
explicitly stated in the "doc/rtp-packetization.txt" file, it does<br>
seem that several things are true:<br>
<br>
- it seems that if a remote sender is sending 40ms packets, and you<br>
have not explicitly denied 40ms packets, that Asterisk should accept<br>
those packets. This seems to work.<br>
<br>
- if you explicitly have "deny=all" and then "allow=alaw:20" in a<br>
peer definition, it should be the case that Asterisk takes whatever<br>
audio stream and transcode it for the remote peer in that format (and<br>
in the SDP Asterisk should offer a ptime and maxptime based on the<br>
default and highest ptime acceptable, in this case "20" for both.)<br>
Is this broken?<br>
<br>
- if a remote host sends you a ptime that is not defined or<br>
defaulted in the list of "allow=" codec choices for that peer (or<br>
globally) then the call should be refused just like it would be with<br>
any other codec mismatch. (Of course, if you don't have a "deny=all"<br>
as the first statement in your peer codec list, Asterisk should let<br>
anything through since that's the way those ACLs work. I mention this<br>
only as a caution for reporting problems that might not be problems.)<br>
Is this broken?<br>
<br>
<br>
This problem is actually fairly important when we start talking about<br>
"scale". All RTP-based systems start to experience bottlenecks<br>
introduced by Packets-Per-Second limits on hardware interfaces. The<br>
upper limit of performance starts to be more bound to throughput on<br>
interfaces and kernel drivers, rather than in the higher-layer code.<br>
PPS, not megabits per second, becomes the number to beat. If you can<br>
get RTP packets to go from 20ms to 40ms, it doubles the size of the<br>
packet and effectively halves the number of packets you're sending on<br>
your interface, which _could_ lead to doubling of total numbers of<br>
calls as the limits of interface buffering are reached in the near<br>
future. Even if you're just doing this on one leg of a looped call,<br>
this still could reduce your overall PPS by 25%, which is nothing to<br>
sniff at. Of course, I'm assuming that the load introduced by re-<br>
packetizing different packet delays is not significant - this could be<br>
a false assumption.<br>
<br>
JT<br>
<br>
<br>
---<br>
John Todd<br>
<a href="mailto:jtodd@digium.com" target="_blank">jtodd@digium.com</a> +1-256-428-6083<br>
Asterisk Open Source Community Director<br>
</blockquote><div><br> </div></div><br>
</div></div></blockquote></div><br>