--On 21 June 2004 14:00 +0100 Linus Surguy linus@magrathea-telecom.co.uk wrote:
If it were just for personal use that would be fine, but we have to support a wide range of clients where we don't have control over their hardware. I think we're going to have to 'correct' the Content-Length field - is there any way we can add additional data to the body and force SER to recalculate it that way?
To my eye the body looked right, but the Content-Length: field looked wrong. So you just need to rewrite Content-Length. As I said, look up the exec() function and make it run some perl to process the message - can't see why this shouldn't work.
However, whilst you might fix this one, you will not in general fix broken NATs. For instance, Cisco IOS (at least 12.2(11)T10) NAT helper helpfully truncates the SIP_INFO message, thus swallowing the DTMF digit actually dialed. Unless you can code clairvoyant perl, then you aren't going to be able restore that.
Whilst you can sometimes reverse breakages down to particular UAs, it's much harder with NAT and other middleboxen as they often leave no signature on the packet so it's hard to fix them.
Business models where you have no control over the hardware (UA as well as NAT) are tricky. For instance, you will find a considerable number of older ADSL "routers with built in firewall" which do not forward UDP packets other than DNS at all. If you find a simple way to support these with arbitrary ATAs, please let me know!
Alex