[asterisk-users] Forcing repacketization on SIP to SIP call
rnbrady at gmail.com
Wed Nov 19 04:48:46 CST 2008
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
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).
On Tue, Nov 11, 2008 at 11:29 AM, Richard Brady <rnbrady at gmail.com> wrote:
> 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.
> On Tue, Oct 28, 2008 at 9:02 PM, John Todd <jtodd at digium.com> 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.
>> John Todd
>> jtodd at digium.com +1-256-428-6083
>> Asterisk Open Source Community Director
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-users