I hope this is not an FAQ, I've tried searching the available info. Using Ser 0.8.12, Cisco AS5300 with IOS 12.3.6 & a ATA-186.
ATA-186 (behind NAT) -> SER -> AS5300
On the INVITE, we get:
10w6d: httpish_msg_process_network_msg: Content Length 261, Bytes Remaining 256 10w6d: HandleUdpSocketReads: SIP Message incomplete, trashed
ser.cfg is just using t_relay_to_udp and not doing anything fancy.
Any ideas!?
Linus
(Full debug from debug ccsip all)
10w6d: Received: INVITE sip:448000664901@gk.magrathea.net;user=phone SIP/2.0 Max-Forwards: 10 Record-Route: sip:448000664901@213.166.5.135;ftag=651568306;lr=on Via: SIP/2.0/UDP 213.166.5.135;branch=z9hG4bKbf06.7adc86c4.0 Via: SIP/2.0/UDP 213.162.109.118:5060 From: sip:linus@gk.magrathea.net;tag=651568306 To: sip:448000664901@gk.magrathea.net;user=phone Call-ID: 82733180@213.162.109.118 CSeq: 1 INVITE Contact: sip:linus@213.162.109.118:5060;transport=udp User-Agent: Cisco ATA 186 v2.16.1 ata18x (030709a) Expires: 300 Content-Length: 261 Content-Type: application/sdp
v=0 o=linus 115389 115389 IN IP4 213.162.109.118 s=ATA186 Call c=IN IP4 213.162.109.118 t=0 0 m=audio 16384 RTP/AVP 4 8 0 101 a=rtpmap:4 G723/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
10w6d: httpish_msg_process_network_msg: Content Length 261, Bytes Remaining 256 10w6d: HandleUdpSocketReads: SIP Message incomplete, trashed
--On 19 June 2004 18:07 +0100 Linus Surguy linus@magrathea-telecom.co.uk wrote:
I hope this is not an FAQ, I've tried searching the available info. Using Ser 0.8.12, Cisco AS5300 with IOS 12.3.6 & a ATA-186.
ATA-186 (behind NAT) -> SER -> AS5300
On the INVITE, we get:
10w6d: httpish_msg_process_network_msg: Content Length 261, Bytes Remaining 256 10w6d: HandleUdpSocketReads: SIP Message incomplete, trashed
If you are using Cisco NAT, I'd suggest sticking a sniffer either side of it and checking it's not trashing things. The default Cisco NAT helper, at least on some IOS versions, is less than helpful and trashes packets (specifically truncated SIP_INFO packets so that their content length is zero). This causes incomplete packets. Turning off nat-helper fixes this (it is on by default).
Alex
I hope this is not an FAQ, I've tried searching the available info.
Using
Ser 0.8.12, Cisco AS5300 with IOS 12.3.6 & a ATA-186.
ATA-186 (behind NAT) -> SER -> AS5300
On the INVITE, we get:
10w6d: httpish_msg_process_network_msg: Content Length 261, Bytes Remaining 256 10w6d: HandleUdpSocketReads: SIP Message incomplete, trashed
If you are using Cisco NAT, I'd suggest sticking a sniffer either side of it and checking it's not trashing things. The default Cisco NAT helper, at least on some IOS versions, is less than helpful and trashes packets (specifically truncated SIP_INFO packets so that their content length is zero). This causes incomplete packets. Turning off nat-helper fixes this (it is on by default).
I havnt turned on anything specific, I've placed the 'public IP' in the Cisco ATA-186 config, but havnt turned on any other NAT features, either in SER or the AS5300 (I know that RTP might currently break) - and I just wanted to get the initial invite to work. Specifically, what do you think I should turn off?
Linus
--On 21 June 2004 11:06 +0100 Linus Surguy linus@magrathea-telecom.co.uk wrote:
Specifically, what do you think I should turn off?
On the NAT: no ip nat service sip udp port 5060 I think is the line that fixed it
Alex
Thanks all (especially Alex), I know now why, and it does seem that the 'NAT' device - in this case a Draytek Vigor ADSL router is rewriteing the SIP packet incorrectly. However, if I wanted to be tolerant of this, is there a way to instruct SER to re-evaluate the 'content-length' and rewrite it correctly?
(ngrep dumps below)
Internal to NAT:
U 10.0.0.212:5060 -> 213.166.5.135:5060 INVITE sip:448000664901@gk.magrathea.net;user=phone SIP/2.0..Via: SIP/ 2.0/UDP 10.0.0.212:5060..From: sip:linus@gk.magrathea.net;tag=30449371 62..To: sip:448000664901@gk.magrathea.net;user=phone..Call-ID: 10341 00418@10.0.0.212..CSeq: 1 INVITE..Contact: <sip:linus@213.162.109.118: 5060;transport=udp>..User-Agent: Cisco ATA 186 v2.16.1 ata18x (030709 a)..Expires: 300..Content-Length: 249..Content-Type: application/sdp.. ..v=0..o=linus 14148 14148 IN IP4 10.0.0.212..s=ATA186 Call..c=IN IP4 213.162.109.118..t=0 0..m=audio 16384 RTP/AVP 4 8 0 101..a=rtpmap:4 G7 23/8000/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:0 PCMU/8000/1..a=rtpmap:10 1 telephone-event/8000..a=fmtp:101 0-15..
But what actually arrives is:
U 213.162.109.118:5060 -> 213.166.5.135:5060 INVITE sip:448000664901@gk.magrathea.net;user=phone SIP/2.0..Via: SIP/2.0/UDP 213.162.109.118:5060..From: sip:linus@gk.magrathea.net;tag=3044937162..To: <si p:448000664901@gk.magrathea.net;user=phone>..Call-ID: 1034100418@213.162.109.1 18..CSeq: 1 INVITE..Contact: sip:linus@213.162.109.118:5060;transport=udp..U ser-Agent: Cisco ATA 186 v2.16.1 ata18x (030709a)..Expires: 300..Content-Leng th: 259..Content-Type: application/sdp....v=0..o=linus 14148 14148 IN IP4 213. 162.109.118..s=ATA186 Call..c=IN IP4 213.162.109.118..t=0 0..m=audio 16384 RTP /AVP 4 8 0 101..a=rtpmap:4 G723/8000/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:0 PCM U/8000/1..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..
--On 21 June 2004 13:02 +0100 Linus Surguy linus@magrathea-telecom.co.uk wrote:
Thanks all (especially Alex), I know now why, and it does seem that the 'NAT' device - in this case a Draytek Vigor ADSL router is rewriteing the SIP packet incorrectly. However, if I wanted to be tolerant of this, is there a way to instruct SER to re-evaluate the 'content-length' and rewrite it correctly?
You might be better fixing the Draytech - who knows what information the NAT box is losing. The problem you have here is it's done 3 rewrites (Via, Call-ID, & RTP o=) each adding five characters but only added 10 to Content-Length; I expect you can imagine the piece of C doing this and that one of those rewrites isn't incrementing Content-Length. Quite why it feels the need to rewrite Call-ID I dunno, & if the ATA-186 lets you set a call-ID string after the "@" then you have a 1 in 3 chance of fixing this that way! I've had relatively good success upgrading software on such boxes and finding the new s/w magically fixes things. Alternatively, you may find a new ADSL router costs less than the coding effort involved in fixing this (I suppose you could put it through exec and a piece of perl to rewrite the content length field if it is wrong, but then you have no protection when it actually is wrong).
Alex
Thanks all (especially Alex), I know now why, and it does seem that the 'NAT' device - in this case a Draytek Vigor ADSL router is rewriteing
the
SIP packet incorrectly. However, if I wanted to be tolerant of this, is there a way to instruct SER to re-evaluate the 'content-length' and rewrite it correctly?
You might be better fixing the Draytech - who knows what information the NAT box is losing. The problem you have here is it's done 3 rewrites (Via, Call-ID, & RTP o=) each adding five characters but only added 10 to Content-Length; I expect you can imagine the piece of C doing this and
that
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?
Linus
--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
On Jun 21, 2004 at 14:00, Linus Surguy linus@magrathea-telecom.co.uk wrote:
Thanks all (especially Alex), I know now why, and it does seem that the 'NAT' device - in this case a Draytek Vigor ADSL router is rewriteing
the
SIP packet incorrectly. However, if I wanted to be tolerant of this, is there a way to instruct SER to re-evaluate the 'content-length' and rewrite it correctly?
You might be better fixing the Draytech - who knows what information the NAT box is losing. The problem you have here is it's done 3 rewrites (Via, Call-ID, & RTP o=) each adding five characters but only added 10 to Content-Length; I expect you can imagine the piece of C doing this and
that
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?
If you really want to try to fix this from ser there is a way. In fact there are 2 ways, one involves editing the sources and the other a config hack.
1. editing the sources (ser 0.8.12 from cvs or ser unstable) - edit msg_translator.c. In the adjust_clent function you should find the following line: if ((anchor==0) && body_delta){ (line 1231 in ser 0.8.12-tcp_nonb & 1235 in ser unstable). Change it into: if (anchor==0){ (just remove the body_delta test).
Now ser will recompute the content length for all the packets. This will also add a small performance hit (because now ser will have to parse more headers: it will have to find and parse at least content-length).
2. config hack: ser will automatically recompute content-length if the body of the message changed (ser added or removed something from it). Try the following: is_present_hf("foobar"); /* it doesn't matter what, this just has the side-effect of forcing ser to parse all the headers */ subst('/^(s=.*)$/\1\r\ni=Ser-fixed session/'); /* adds something to the sdp to force ser to recompute clen*/ You will need to load the textops module for is_present_hf & subst.
Andrei
-
Alex Bligh -
Andrei Pelinescu-Onciul -
Linus Surguy