27 Jun
2007
27 Jun
'07
1: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.
27 Jun
27 Jun
2:08 p.m.
SIP wrote:
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.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Obviously, that 483 block should have been:
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
And NOT the next block in the config. :)
N.
28 Jun
28 Jun
2:26 a.m.
Yes, you probably have an internal loop. You should see it on the
interface. The first iteration, the Route header will be found, it
points to local SER, it is removed and it is thus not loose routed, the
uri is probably not rewritten, so it is t_relayed to itself... Look at
the via_cnt in the warning...
g-)
SIP wrote:
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.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:53 a.m.
I'm not sure I understand, Greger. I see the via_cnt, but that's the
first (and only) BYE message that comes through. I would have thought
had I been looping around, I might see a few more on the interface.
Also, why does this ONLY happen with certain peers, but not with most
others and not with anything local? And why only on BYE and ACK messages
but not INVITE?
So... confused....
Just when I think I have a handle on SER, it turns around and does
something like this.
Greger V. Teigre wrote:
Yes, you probably have an internal loop. You should
see it on the
interface. The first iteration, the Route header will be found, it
points to local SER, it is removed and it is thus not loose routed,
the uri is probably not rewritten, so it is t_relayed to itself...
Look at the via_cnt in the warning...
g-)
SIP wrote:
> 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.
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
6:34 a.m.
Just run tcpdump/tethereal/tshark on special "any" interface and you'll
see the messages going to the box itself (over loopback interface).
Why ...? Check the request uri of the BYE.... you've probably rewritten
the Contact header of the INVITE or smthg like that.
Michal
On Čt, 2007-06-28 at 05:53 -0400, SIP wrote:
I'm not sure I understand, Greger. I see the
via_cnt, but that's the
first (and only) BYE message that comes through. I would have thought
had I been looping around, I might see a few more on the interface.
Also, why does this ONLY happen with certain peers, but not with most
others and not with anything local? And why only on BYE and ACK messages
but not INVITE?
So... confused....
Just when I think I have a handle on SER, it turns around and does
something like this.
Greger V. Teigre wrote:
Yes, you probably have an internal loop. You
should see it on the
interface. The first iteration, the Route header will be found, it
points to local SER, it is removed and it is thus not loose routed,
the uri is probably not rewritten, so it is t_relayed to itself...
Look at the via_cnt in the warning...
g-)
SIP wrote:
> 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.
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:57 a.m.
I've looked and looked and I can't find a loop in the config code (I do
rewrite the contact header of the INVITE with a fix_nated_contact() on a
failed check of a nat test, but I do that for ALL calls locally and
peered, and it only affects calls from some peers, not others (and
removing it does nothing)). It's clear a loop is occurring... I just
can't figure out where.
The first ACK to come through, for instance, looks like this:
U 198.65.166.131:5060 -> 63.64.65.66:5060
ACK sip:201@63.64.65.66:5060 SIP/2.0.
Record-Route: <sip:198.65.166.131;ftag=qvog5szdic;lr>.
Via: SIP/2.0/UDP 198.65.166.131;branch=0.
Via: SIP/2.0/UDP
192.168.1.51:2051;received=63.95.XX.XX;branch=z9hG4bK-zogadalsc3gs;rport=2051.
Route: <sip:63.64.65.66;ftag=qvog5szdic;lr=on>.
From: "User One"
<sip:1747XXXXXXX@proxy01.sipphone.com:5060>;tag=qvog5szdic.
To: <sip:1101201@proxy01.sipphone.com;user=phone>;tag=00000A3D32CAFBE9.
Call-ID: 3c26927a1fbd-uq2r1lq59bfi@snom190.
CSeq: 1 ACK.
Max-Forwards: 16.
Contact: <sip:1747XXXXXXX@192.168.1.51:2051;line=oxd9zlst;nat=yes>.
Content-Length: 0.
P-hint: rr-enforced.
P-NATed-URI: YES (1).
P-RTP-Proxy: YES (1).
It will hit the ACK block in the SER config:
if(method=="ACK")
{
route(1);
break;
}
Which will then hit the route[1] block:
route[1]
{
t_on_reply("1");
setflag(3);
if (!t_relay())
{
sl_reply_error();
};
}
But for some reason, it sends it to itself... and moments later, I end
up with something like:
U 63.64.65.66:5060 -> 63.64.65.66:5060
ACK sip:201@63.64.65.66:5060 SIP/2.0.
Record-Route: <sip:63.64.65.66;ftag=qvog5szdic;lr=on>.
Record-Route: <sip:63.64.65.66;ftag=qvog5szdic;lr=on>.
Record-Route: <sip:63.64.65.66;ftag=qvog5szdic;lr=on>.
Record-Route: <sip:63.64.65.66;ftag=qvog5szdic;lr=on>.
Record-Route: <sip:63.64.65.66;ftag=qvog5szdic;lr=on>.
Record-Route: <sip:63.64.65.66;ftag=qvog5szdic;lr=on>.
Record-Route: <sip:198.65.166.131;ftag=qvog5szdic;lr>.
Via: SIP/2.0/UDP 63.64.65.66;branch=0.
Via: SIP/2.0/UDP 63.64.65.66;branch=0.
Via: SIP/2.0/UDP 63.64.65.66;branch=0.
Via: SIP/2.0/UDP 63.64.65.66;branch=0.
Via: SIP/2.0/UDP 63.64.65.66;branch=0.
Via: SIP/2.0/UDP 63.64.65.66;branch=0.
Via: SIP/2.0/UDP 198.65.166.131;branch=0.
Via: SIP/2.0/UDP
192.168.1.51:2051;received=63.95.XX.XX;branch=z9hG4bK-zogadalsc3gs;rport=2051.
From: "User One"
<sip:1747XXXXXXX@proxy01.sipphone.com:5060>;tag=qvog5szdic.
To: <sip:1101201@proxy01.sipphone.com;user=phone>;tag=00000A3D32CAFBE9.
Call-ID: 3c26927a1fbd-uq2r1lq59bfi@snom190.
CSeq: 1 ACK.
Max-Forwards: 10.
Contact: <sip:1747XXXXXXX@192.168.1.51:2051;line=oxd9zlst;nat=yes>.
Content-Length: 0.
P-hint: rr-enforced.
P-NATed-URI: YES (1).
P-RTP-Proxy: YES (1).
You know... as I look at things, I think I know what the problem is. Not
sure how to solve it, though...
When someone dials a URI bound for SEMS, my SER looks at it and sends it
off to SEMS. When the call is coming in from a local user, SER forwards
the ACK on to the correct location without a hitch. However, when the
call comes in from a non-local user, for some reason, the ACK isn't
getting sent on to the correct location (be it SEMS or the PSTN gateway).
For instance, in the above example, 201 is an extension for the
announcement message on SEMS (running on port 5090 on the same machine).
If I call from a user directly registered with my proxy, I can see the
ACK forwarded on to SEMS. If it comes from a non-local user, it looks
like the above.
Now... (and forgive me if I'm blathering... writing about this helps me
think through it) I'm thinking that, since I specifically say something
like:
if(uri =~ "^sip:201@")
{
rewritehostport("blah");
}
in my INVITE block, that's not going to account for the ACKs or BYEs
(though... it seems to locally, which has me confused). In fact, if I
put the above block into the ACK check block, it seems to work even from
a non-locally-registered client. SO.... somehow, this all works
differently for locally-registered UAs sending a SIP URI directly to the
proxy than it does for a UA registered with a peer sending a SIP URI to
to the peer and then to our proxy. Something is different... I just
can't figure out exactly what it is.
I COULD (and perhaps should) create an extra routing block to handle all
those extra rewrites and simply call that from the ACK, CANCEL, BYE, or
INVITE blocks. It might solve the issue... but until I know exactly
what's causing the issue, I daren't do that as I'm liable to create even
more problems (and with a 2000 line ser.cfg, creating problems is going
to be easy to do).
So what do you think? Any ideas on what might cause different routing
behaviour for locally-registered and non-locally-registered UAs? Would
taking the approach of tossing all the rewrites into a separate routing
block and calling it from the ACK, CANCEL, BYE, and INVITE blocks be
just heading down the wrong path?
N.
Michal Matyska wrote:
Just run tcpdump/tethereal/tshark on special
"any" interface and you'll
see the messages going to the box itself (over loopback interface).
Why ...? Check the request uri of the BYE.... you've probably rewritten
the Contact header of the INVITE or smthg like that.
Michal
On Čt, 2007-06-28 at 05:53 -0400, SIP wrote:
> I'm not sure I understand, Greger. I see the via_cnt, but that's the
> first (and only) BYE message that comes through. I would have thought
> had I been looping around, I might see a few more on the interface.
> Also, why does this ONLY happen with certain peers, but not with most
> others and not with anything local? And why only on BYE and ACK messages
> but not INVITE?
>
> So... confused....
>
> Just when I think I have a handle on SER, it turns around and does
> something like this.
>
>
> Greger V. Teigre wrote:
>
>> Yes, you probably have an internal loop. You should see it on the
>> interface. The first iteration, the Route header will be found, it
>> points to local SER, it is removed and it is thus not loose routed,
>> the uri is probably not rewritten, so it is t_relayed to itself...
>> Look at the via_cnt in the warning...
>> g-)
>>
>> SIP wrote:
>>
>>> 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.
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>>
>>>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
12:04 p.m.
SIP wrote:
setflag(3); if (!t_relay()) {
sl_reply_error(); };
}
But for some reason, it sends it to itself... and moments later, I end up with something
like:
U 63.64.65.66:5060 -> 63.64.65.66:5060ACK sip:201@63.64.65.66:5060
SIP/2.0.Record-Route:
Your ACK is going to the wrong port. If you say SEMS is on 5090 then
the remote end is not sending the ACK to the correct port. You will
need to take a look at the whole SIP message exchange to see if its your
fault or the other providers fault.
So what do you think? Any ideas on what might cause
different routing behaviour for locally-registered and non-locally-registered UAs? Would
taking the approach of tossing all the rewrites into a separate routing block and calling
it from the ACK, CANCEL, BYE, and INVITE blocks be just heading down the wrong path?
Yes, and again a complete comparison of SIP messages in both test cases
will reveal why. Look at the contact header throughout all messages to
see what happens. The non-locally-registered UAs are sending the ACK to
the wrong port.
Andres
http://www.telesip.net
12:18 p.m.
Andres wrote:
SIP wrote:
Just a clarification. When I say it is sending the ACK to the wrong
port I am refering to this part of the message: ACK
sip:201@63.64.65.66:5060 (which is build from Contact Header details).
..not this part: U 63.64.65.66:5060 -> 63.64.65.66:5060
setflag(3); if (!t_relay()) {
sl_reply_error(); };
}
But for some reason, it sends it to itself... and moments later, I end up with something
like:
U 63.64.65.66:5060 -> 63.64.65.66:5060ACK sip:201@63.64.65.66:5060
SIP/2.0.Record-Route:
Your ACK is going to the wrong port. If you say SEMS is on 5090 then
the remote end is not sending the ACK to the correct port. You will
need to take a look at the whole SIP message exchange to see if its your
fault or the other providers fault.
So what do you think? Any ideas on what might
cause different routing behaviour for locally-registered and non-locally-registered UAs?
Would taking the approach of tossing all the rewrites into a separate routing block and
calling it from the ACK, CANCEL, BYE, and INVITE blocks be just heading down the wrong
path?
Yes, and again a complete comparison of SIP messages in both test cases
will reveal why. Look at the contact header throughout all messages to
see what happens. The non-locally-registered UAs are sending the ACK to
the wrong port.
Andres
http://www.telesip.net
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
2:42 p.m.
Right. That's the part that's difficult to discover. Where the problem
lies.
The INVITE gets there correctly... I see the path.
UA ---> INVITE 1101201 ---> other proxy ---> INVITE 201 ---> our
proxy:5060 ---> INVITE 201 ---> our proxy:5090 ---> 200 OK
The ACK, however, takes a slightly different path:
other proxy ---> ACK 201 ---> our proxy:5060 ---> ACK 201 ---> our
proxy:5060 ---> rinse ---> repeat
However, from locally registered clients, the path is:
UA ---> ACK 201 ---> our proxy:5060 ---> ACK 201 ---> our proxy:5090
---> life is good.
It's the whole discrepancy that throws me. I mean... the SIP messages
are, for all intents and purposes, going through the same config. I
can't figure out why one client would not experience the same issues as
any other client, locally registered or not.
The Contact header response from the INVITE is correct:
Contact: <sip:201@63.64.65.66:5090>.
But then, the INVITE goes through a series of rewrites of the host/port
based on the URI before t_relay. ACKs just go straight to t_relay. I
guess I'm not 100% sure who writes/rewrites the Contact header.
N.
Andres wrote:
Andres wrote:
SIP wrote:
Just a clarification. When I say it is sending the ACK to the wrong
port I am refering to this part of the message: ACK
sip:201@63.64.65.66:5060 (which is build from Contact Header details).
..not this part: U 63.64.65.66:5060 -> 63.64.65.66:5060
>
>
>> So what do you think? Any ideas on what might cause different
>> routing behaviour for locally-registered and non-locally-registered
>> UAs? Would taking the approach of tossing all the rewrites into a
>> separate routing block and calling it from the ACK, CANCEL, BYE, and
>> INVITE blocks be just heading down the wrong path?
>>
>>
>>
>>
> Yes, and again a complete comparison of SIP messages in both test
> cases will reveal why. Look at the contact header throughout all
> messages to see what happens. The non-locally-registered UAs are
> sending the ACK to the wrong port.
>
> Andres
> http://www.telesip.net
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
> setflag(3); if (!t_relay()) {
sl_reply_error(); };
}
But for some reason, it sends it to itself... and moments later, I
end up with something like:
U 63.64.65.66:5060 -> 63.64.65.66:5060ACK sip:201@63.64.65.66:5060
SIP/2.0.Record-Route:
Your ACK is going to the wrong port. If you say SEMS is on 5090 then
the remote end is not sending the ACK to the correct port. You will
need to take a look at the whole SIP message exchange to see if its
your fault or the other providers fault.
3:18 p.m.
SIP wrote:
Right. That's the part that's difficult to
discover. Where the problem
lies.
The INVITE gets there correctly... I see the path.
UA ---> INVITE 1101201 ---> other proxy ---> INVITE 201 ---> our
proxy:5060 ---> INVITE 201 ---> our proxy:5090 ---> 200 OK
The ACK, however, takes a slightly different path:
other proxy ---> ACK 201 ---> our proxy:5060 ---> ACK 201 ---> our
proxy:5060 ---> rinse ---> repeat
However, from locally registered clients, the path is:
UA ---> ACK 201 ---> our proxy:5060 ---> ACK 201 ---> our proxy:5090
---> life is good.
It's the whole discrepancy that throws me. I mean... the SIP messages
are, for all intents and purposes, going through the same config. I
can't figure out why one client would not experience the same issues
as any other client, locally registered or not.
The Contact header response from the INVITE is correct:
Contact: <sip:201@63.64.65.66:5090>.
Look at the Contact Header inside the 200 OK message when the call is
answered by SEMS and follow it through all the way to the remote end.
This is the key piece of information that tells the remote end where to
send the ACK. If it is indeed at port 5090 then the remote end must
generate an:
ACK sip:201@63.64.65.66:5090.
Andres,
http://www.telesip.net
6184
days inactive
6185
days old
9 comments
4 participants
participants (4)
-
Andres -
Greger V. Teigre -
Michal Matyska -
SIP