[asterisk-users] Forcing repacketization on SIP to SIP call

[Richard Brady]

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 <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.
>
> JT
>
>
> ---
> John Todd
> jtodd at digium.com        +1-256-428-6083
> Asterisk Open Source Community Director
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081111/ecc38f37/attachment.htm