27 Jun
2007
27 Jun
'07
8:34 p.m.
In response to a BYE and an ACK from some (not all) servers that send to
our proxy, our server's spitting back a 483 'Too many hops' reply.
It doesn't happen with all peers, and it certainly doesn't happen
locally... but it does happen with some, and I'm not entirely sure as
to why.
The 483 block at the beginning is normal:
if (msg:len > max_len ) {
sl_send_reply("513", "Message too big");
break;
};
Exchange looks like this:
U 198.65.166.131:5060 -> 63.64.65.66:5060
BYE sip:1101XXXXXXX@63.64.65.66:5060 SIP/2.0.
Record-Route: <sip:198.65.166.131;ftag=gpp0q468oh;lr>.
Via: SIP/2.0/UDP 198.65.166.131;branch=z9hG4bK9b05.b75fbe14.0.
Via: SIP/2.0/UDP
192.168.1.51:2054;received=63.XX.XX.XX;branch=z9hG4bK-wdtud2nffq88;rport=2054.
Route: <sip:63.64.65.66;ftag=gpp0q468oh;lr=on>.
From: "User One"
<sip:1747XXXXXXX@their.proxy.server:5060>;tag=gpp0q468oh.
To: <sip:1101XXXXXXX@their.proxy.server;user=phone>;tag=as7fbbcb66.
Call-ID: 3c267038e7ef-586eg1emcfsi@snom190.
CSeq: 2 BYE.
Max-Forwards: 16.
Contact: <sip:1747XXXXXXX@192.168.1.51:2054;line=oxd9zlst;nat=yes>.
User-Agent: snom190/3.60x.
Content-Length: 0.
RemoteIP: 63.XX.XX.XX.
P-hint: rr-enforced.
P-NATed-URI: YES (1).
P-RTP-Proxy: YES (1).
U 63.64.65.66:5060 -> 198.65.166.131:5060
SIP/2.0 483 Too Many Hops.
Via: SIP/2.0/UDP 198.65.166.131;branch=z9hG4bK9b05.b75fbe14.0.
Via: SIP/2.0/UDP
192.168.1.51:2054;received=63.XX.XX.XX;branch=z9hG4bK-wdtud2nffq88;rport=2054.
From: "User One"
<sip:1747XXXXXXX@their.proxy.server:5060>;tag=gpp0q468oh.
To: <sip:1101XXXXXXX@their.proxy.server;user=phone>;tag=as7fbbcb66.
Call-ID: 3c267038e7ef-586eg1emcfsi@snom190.
CSeq: 2 BYE.
Server: Sip EXpress router (0.9.6 (i386/linux)).
Content-Length: 0.
Warning: 392 63.64.65.66:5060 "Noisy feedback tells: pid=3488
req_src_ip=63.64.65.66 req_src_port=5060
in_uri=sip:1101XXXXXXX@63.64.65.66:5060
out_uri=sip:1101XXXXXXX@63.64.65.66:5060 via_cnt==18".
What would be causing this? Is it because the IP address is being used
in the URI to us as opposed to the domain (I tried adding the IP to the
domain table and to an alias line alternately, but it didn't fix things) ?
It's irksome in that it only happens with certain peers and not others,
so there's something in the way we're handling messages from them that's
not right or different, but since we handle all incoming the same way,
I'm at a loss as to why it works with some but not with others.
N.