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

[Richard Brady]

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 <rnbrady at gmail.com> 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 <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/20081119/b7fb3549/attachment.htm