Unfortunately, you run into the same problem that exists when trying to convert codecs. What you want can be done, but not currently with IPIPGW. Even within this people persist in trying to run 10 or 20 byte payloads to 'improve' quality. In many cases the increased packet load simply overwhelms the network at some point.
Yes it is true a smaller payload would give better quality in a perfect network with some loss. Unfortunately, the world does not work like the lab. By increasing the payload size, you reduce bandwidth and significantly reduce packet rate, the latter being what kills most router interconnects.
See my rant from 04 http://blog.webvoip.com/blogs/spade/index.php?m=20040709
ANYway, it would be nice to do this, but while codec is negotiated, payload is usually not and must be set by both ends to avoid asymetrical usage. Conceptually, I think IPIPGW could do something of this sort without the major CPU overhead associated with a codec transcode. It would require some extra work however, because it would require the router to buffer and combine packets one way, then split packets the other way. This would add an amount of latency at least as much as the change, in your case 100-20ms. Other issues might be packet sequence reordering. Sounds possible, but then imagine 500 calls simultaneous.
So, great idea that we all would love to see, but unlikely. Bandwidth is much cheaper now, and router CPUs are getting faster, so it may all become moot.
John Spade
webVoIP
