19 Jun
2004
19 Jun
'04
8:07 p.m.
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(a)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
21 Jun
21 Jun
12:57 p.m.
--On 19 June 2004 18:07 +0100 Linus Surguy <linus(a)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
1:06 p.m.
> 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).
3:02 p.m.
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(a)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..
3:33 p.m.
--On 21 June 2004 13:02 +0100 Linus Surguy <linus(a)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
4 p.m.
> 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
5:29 p.m.
--On 21 June 2004 14:00 +0100 Linus Surguy <linus(a)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
22 Jun
22 Jun
1:49 p.m.
On Jun 21, 2004 at 14:00, Linus Surguy <linus(a)magrathea-telecom.co.uk> wrote:
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
> 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
7464
days inactive
7467
days old
8 comments
3 participants
participants (3)
-
Alex Bligh -
Andrei Pelinescu-Onciul -
Linus Surguy