-----Original Message----- From: users-bounces@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@lists.openser.org Subject: Re: [OpenSER-Users] Loose route problem or misunderstanding
El Martes, 10 de Junio de 2008, Watkins, Bradley escribió:
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).
The remote target is on the same machine, but on a different port. OpenSER is listening on 5060, Asterisk is listening on 5062.
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.