11 Jun
2008
11 Jun
'08
1:21 a.m.
-----Original Message-----
From: users-bounces(a)lists.openser.org
[mailto:users-bounces@lists.openser.org] On Behalf Of Iñaki
Baz Castillo
Sent: Tuesday, June 10, 2008 5:14 PM
To: users(a)lists.openser.org
Subject: Re: [OpenSER-Users] Loose route problem or misunderstanding
El Martes, 10 de Junio de 2008, Watkins, Bradley escribió:
The remote target is on the same machine, but on a different port. OpenSER is
listening on 5060, Asterisk is listening on 5062.
I'm quite sure that it is, actually. Mind
you, it could be that I'm
expecting loose_route to do something that by RFC compliance it
shouldn't, hence the admission that I may be misunderstanding.
Here's the relevant SIP messages for a failing scenario:
This is an in-dialog request, so WHY the host of the RURI is
the OpenSer IP
(10.0.12.51) instead of the UA "Contact" IP?
Of course this is incorrect. The RURI host in any in-dialog
request must be
the remote-target (this is: the host in the received
"Contact" from the other
end point).
Nortel CS1000? I've bad experiences with a Nortel
CS2000 but
it *does* well
loose-routing not as in your case.
This is a CS1k, but the question is a vagary of my setup. Unfortunately, this is one
problem I can't blame on the Nortel. ;)
Not to worry, there are plenty of others that I know for sure I can. :)
loose_route() examines the top "Route"
header (10.0.12.51)
and matches it
agains OpenSer knows IP's and hostnames (and domains).
If it matches (and it does it) it takes off the "Route"
header and send the
request to the URI indicated in the RURI (if there is not
more "Route"
headers), but note that the request RURI is:
INVITE sip:71841@10.0.12.51:5062 SIP/2.0
Yes, but if it were doing that it would work fine. Again, the endpoint here is on the
same system, but a different port.
So it's 10.0.12.51: OpenSer IP !!!!!
so OpenSer routes the request to itself !!!
When the request arrives again to OpenSer (looped) it has
"To" tag but
not "Route" header so OpenSer replies with a correct "404:
Not here". It's
100% correct.
But it shouldn't be sending it to itself at all. If it is, then it's ignoring the
port in the RURI and that's certainly incorrect.
The problem is the host of the RURI in the in-dialog
request.
Could you show
how the INITIAL INVITE arrives to the Nortel (in case a UAC calls the
Nortel), or the 200 OK arriving to Nortel (if Nortel
initiates the call).
I can, but it will have to wait until tomorrow I'm afraid. I'm away from those
systems for the evening.