28 Sep
2006
28 Sep
'06
9:02 p.m.
I wonder if anyone on this list is open to a thought exercise?
I'm trying to put together a cogent message about this,
but in the meantime:
I've got a situation where my openser box seems to route stuff to itself
and it loops around and around until I get the classic "Too Many Hops" error.
This seems to happen most often on BYE, although I've seen an ACK do it too.
Here is a small ngrep snippet, after
PHONE has called OPENSER-ONE who statelessly relays to OPENSER-TWO
who t_relays to PSTNGW, and then the pstn user hangs-up:
U 23:03:53.254382 PSTNGW:5060 -> OPENSER-TWO:5060
BYE sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone SIP/2.0
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Route: <sip:JoeUser@OPENSER-ONE:5060>
Max-Forwards: 70
#
U 23:03:53.255013 OPENSER-TWO:5060 -> OPENSER-ONE:5060
BYE sip:JoeUser@OPENSER-ONE:5060 SIP/2.0
Record-Route: <sip:JoeUser@OPENSER-TWO;lr=on;ftag=26674>
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP OPENSER-TWO;branch=otherbranch.0
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Max-Forwards: 69
Route: <sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone>
Right here OPENSER-ONE freaks out, and the delay causes
OPENSER-TWO to re-transmit:
#
U 23:03:53.611227 OPENSER-TWO:5060 -> OPENSER-ONE:5060
BYE sip:JoeUser@OPENSER-ONE:5060 SIP/2.0
Record-Route: <sip:JoeUser@OPENSER-TWO;lr=on;ftag=26674>
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP OPENSER-TWO;branch=otherbranch.0
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Max-Forwards: 69
Route: <sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone>
OK, so who on this list is good enough to be able to suggest plausible
theories about what my openser.cfg flaw is? If you don't want to
speculate openly on the list then please send me a direct email.
Thanks,
-mark
28 Sep
28 Sep
9:14 p.m.
Probably OPENSER-ONE does not recognize the BYE as targeted to itself
(due to misconfiguration of listen|alias parameters) and that's why it
keeps on sending to itself the message..
It's like OPENSER-ONE checks the Req-URI|Route domainname|IP and
says..hey that's not for me, let's forward it to the next route..which
happens to be itself....and this happens until Max-Forwards reaches
the lower limit...
Try to add
alias=OPENSER-ONE.example.com:5060
in your config file and see what happens..
Samuel.
2006/9/28, Mark Kent <mark(a)noc.mainstreet.net>et>:
I wonder if anyone on this list is open to a thought
exercise?
I'm trying to put together a cogent message about this,
but in the meantime:
I've got a situation where my openser box seems to route stuff to itself
and it loops around and around until I get the classic "Too Many Hops" error.
This seems to happen most often on BYE, although I've seen an ACK do it too.
Here is a small ngrep snippet, after
PHONE has called OPENSER-ONE who statelessly relays to OPENSER-TWO
who t_relays to PSTNGW, and then the pstn user hangs-up:
U 23:03:53.254382 PSTNGW:5060 -> OPENSER-TWO:5060
BYE sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone SIP/2.0
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Route: <sip:JoeUser@OPENSER-ONE:5060>
Max-Forwards: 70
#
U 23:03:53.255013 OPENSER-TWO:5060 -> OPENSER-ONE:5060
BYE sip:JoeUser@OPENSER-ONE:5060 SIP/2.0
Record-Route: <sip:JoeUser@OPENSER-TWO;lr=on;ftag=26674>
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP OPENSER-TWO;branch=otherbranch.0
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Max-Forwards: 69
Route: <sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone>
Right here OPENSER-ONE freaks out, and the delay causes
OPENSER-TWO to re-transmit:
#
U 23:03:53.611227 OPENSER-TWO:5060 -> OPENSER-ONE:5060
BYE sip:JoeUser@OPENSER-ONE:5060 SIP/2.0
Record-Route: <sip:JoeUser@OPENSER-TWO;lr=on;ftag=26674>
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP OPENSER-TWO;branch=otherbranch.0
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Max-Forwards: 69
Route: <sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone>
OK, so who on this list is good enough to be able to suggest plausible
theories about what my openser.cfg flaw is? If you don't want to
speculate openly on the list then please send me a direct email.
Thanks,
-mark
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
29 Sep
29 Sep
4:43 a.m.
> (due to misconfiguration of listen|alias
parameters) and that's why it
That can't be it as the box functions normally in less complicated
scenarios. Besides, I just added what you suggested and it doesn't
make a difference :-)
And, what's the interaction between the "domain" module and how
openser internally recognizes messages intended for itself?
And things work in simpler scenarios.
Let me tell you what makes this more complicated:
When OPENSER-ONE gets a call that is meant for the pstn it
sends back a redirect to the client, redirecting to OPENSER-TWO.
Some clients do start communicating with OPENSER-TWO, but some don't.
They send the new R-URI, mentioning OPENSER-TWO, to OPENSER-ONE.
I want to handle those messages as easily as possible, so right at the
top of route[0] on OPENSER-ONE I have this:
# kludge, sender should have been redirected earlier,
# but just in case...
if (uri=~"@OPENSER-TWO.example.com|@192.0.2.2") {
log(1, "stateless relay TO pstn gw\n");
forward();
exit;
}
if ((src_ip==192.0.2.2) && (!is_uri_host_local()))
log(1, "stateless relay FROM pstn gw\n");
forward();
exit;
}
The first "if" is for stuff addressed to OPENSER-TWO, but sent to OPENSER-ONE.
The second one is for messages coming back the other way.
As I sit and think about this, I'm guessing that I can't get away with
just shuffling the packets back and forth. But I could do with a
explanation as to how silly this is.
Thanks,
-mark
12:32 p.m.
You should (must) use DNS entries for openser1 and openser2 and just
use t_relay* calls to forward calls from one to another...
Samuel.
2006/9/29, Mark Kent <mark(a)noc.mainstreet.net>et>:
It depends in your config file...if the Request passed the loose_route
you have to process it in your config file accordingly...
> (due to
misconfiguration of listen|alias parameters) and that's why it
That can't be it as the box functions normally in less complicated
scenarios. Besides, I just added what you suggested and it doesn't
make a difference :-)
And, what's the interaction between the "domain" module and how
openser internally recognizes messages intended for itself?
And things work in simpler scenarios.
Then your "complex" config file is doing inapropriate things....
Let me tell you what makes this more complicated:
When OPENSER-ONE gets a call that is meant for the pstn it
sends back a redirect to the client, redirecting to OPENSER-TWO.
Some clients do start communicating with OPENSER-TWO, but some don't.
They send the new R-URI, mentioning OPENSER-TWO, to OPENSER-ONE.
I want to handle those messages as easily as possible, so right at the
top of route[0] on OPENSER-ONE I have this:
# kludge, sender should have been redirected earlier,
# but just in case...
if (uri=~"@OPENSER-TWO.example.com|@192.0.2.2") {
log(1, "stateless relay TO pstn gw\n");
forward();
exit;
}
if ((src_ip==192.0.2.2) && (!is_uri_host_local()))
log(1, "stateless relay FROM pstn gw\n");
forward();
exit;
}
The first "if" is for stuff addressed to OPENSER-TWO, but sent to OPENSER-ONE.
The second one is for messages coming back the other way.
As I sit and think about this, I'm guessing that I can't get away with
just shuffling the packets back and forth. But I could do with a
explanation as to how silly this is.
Thanks,
-mark
11:16 p.m.
Thanks very much for the detailed answers.
You have supplied and confirmed lots of information for me.
I don't completely get what you mean by:
> You should (must) use DNS entries for openser1 and
openser2
Note that, for me, it's not DNS that's a mystery, but the
exact sequence of words you used in this context.
The snippet of code used the name of openser2 as it appears in
messages from openser2. It's pattern matching, not DNS.
It also used the IP address of openser2 (src_ip), which also
doesn't (or shouldn't) rely on dns.
I run the DNS, I run openser[12]. I figure I should be able to
control things so that messages from openser2 look like I want them to
look, and so should be able to do such comparisons.
Or, did you mean something else?
BTW, your comments, plus the nudge from Klaus, have convinced me to
trash that code segment (the forward() kludge), so this is just a
curiosity now.
Thanks,
-mark
12:33 p.m.
Hi Mark!
Does both gateways do record_route? If yes, then there should be 2 route
headers in the BYE sent from the GW.
If server 2 does record_route, then the header
Route: <sip:JoeUser@OPENSER-TWO:5060> is missing.
If server 2 does not record_route. then the GW must not send to proxy 2.
Further, in the the BYE from GW to openser2, the proxy 1 is addressed 2
times (RURI and route header). proxy 1 should be referenced only 1 time,
on the other hand there is no reference to the SIP client.
I guess the problem is how you handle the INVITE. Thus a trace of the
initial INVITE would be more useful. I also suspect you to use
fix_nated_contact in proxy 2 - this must not happen!
regards
klaus
Mark Kent wrote:
I wonder if anyone on this list is open to a thought
exercise?
I'm trying to put together a cogent message about this,
but in the meantime:
I've got a situation where my openser box seems to route stuff to itself
and it loops around and around until I get the classic "Too Many Hops" error.
This seems to happen most often on BYE, although I've seen an ACK do it too.
Here is a small ngrep snippet, after
PHONE has called OPENSER-ONE who statelessly relays to OPENSER-TWO
who t_relays to PSTNGW, and then the pstn user hangs-up:
U 23:03:53.254382 PSTNGW:5060 -> OPENSER-TWO:5060
BYE sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone SIP/2.0
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Route: <sip:JoeUser@OPENSER-ONE:5060>
Max-Forwards: 70
#
U 23:03:53.255013 OPENSER-TWO:5060 -> OPENSER-ONE:5060
BYE sip:JoeUser@OPENSER-ONE:5060 SIP/2.0
Record-Route: <sip:JoeUser@OPENSER-TWO;lr=on;ftag=26674>
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP OPENSER-TWO;branch=otherbranch.0
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Max-Forwards: 69
Route: <sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone>
Right here OPENSER-ONE freaks out, and the delay causes
OPENSER-TWO to re-transmit:
#
U 23:03:53.611227 OPENSER-TWO:5060 -> OPENSER-ONE:5060
BYE sip:JoeUser@OPENSER-ONE:5060 SIP/2.0
Record-Route: <sip:JoeUser@OPENSER-TWO;lr=on;ftag=26674>
Call-ID: callid@PHONE
From: <sip:18005551212@OPENSER-TWO.example.com:5060>;tag=26674
To: "Joe User" <sip:JoeUser@OPENSER-ONE.example.com>;tag=thetag
Content-Length: 0
CSeq: 1 BYE
Via: SIP/2.0/UDP OPENSER-TWO;branch=otherbranch.0
Via: SIP/2.0/UDP PSTNGW:5060;branch=thebranch
Max-Forwards: 69
Route: <sip:JoeUser@OPENSER-ONE.example.com:5060;user=phone>
OK, so who on this list is good enough to be able to suggest plausible
theories about what my openser.cfg flaw is? If you don't want to
speculate openly on the list then please send me a direct email.
Thanks,
-mark
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:19 p.m.
Klaus,
Your dissecting of the initial BYE, plus the help from samuel,
tells me that I'm shooting myself in the foot with the forwarding
I put in.
Also, you may be right about the double fix_nated_contact, which, if
it's not happening now, would certainly have been happening once I
remove the kludge that I included in an earlier email.
Thanks,
-mark
6430
days inactive
6431
days old
6 comments
3 participants
participants (3)
-
Klaus Darilion -
Mark Kent -
samuel