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

[John Todd]

On Oct 27, 2008, at 10:34 AM, Richard Brady wrote:

> Hi folks
>
> I have a handset talking to Asterisk, which in turn puts the call  
> through to an ITSP.
>
> The handsets likes to send audio in 40ms frames (even though  
> Asterisk requests 20ms frames with a ptime header in the SDP).
>
> The ITSP doesn't request any particular frame length (with ptime) or  
> state a maximum length (with maxptime), so when Asterisk receives  
> the 40ms media frames from the handset, it simply relays it on to  
> the ITSP. Unfortunately the ITSP doesn't support this, and the  
> result is one-way audio.
>
> I would like to know whether there is a way to force Asterisk to  
> repacketize the media stream, converting from 40ms frames to 20ms  
> frames. I am aware of the allow=alaw:20 syntax but this doesn't seem  
> to work. It is not clear from the docs whether that setting is for  
> the SDP offer (in which case it would only affect incoming media) or  
> whether it's used to to actually force what is sent to a peer/user  
> as well (in which case it is not behaving as expected).
>
> I would also be interested to know what the correct action is for  
> the ITSP to take. How do they complain (using SIP and/or SDP) that  
> the media received is not what they were expecting?
>
> Any help would be greatly appreciated.
>
> Regards,
> Richard
>
> --
> Richard Brady
> T: +44 (0)7771 623 348
> E: rnbrady at gmail.com

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