[OpenSER-Users] Loose route problem or misunderstanding

Iñaki Baz Castillo ibc at aliax.net
Tue Jun 10 23:14:10 CEST 2008


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).

Nortel CS1000? I've bad experiences with a Nortel CS2000 but it *does* well 
loose-routing not as in your case.

> U 10.3.104.104:5060 -> 10.0.12.51:5060
> INVITE sip:71841 at 10.0.12.51:5062 SIP/2.0.
> From: <sip:77740 at 10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
> To: "Brad Watkins"<sip:71841 at 10.0.12.51:5062>;tag=as75bb16a1.
> Call-ID: 75bd11cb40e6f85239b3bf6c525bb206 at 10.0.12.51.
> CSeq: 2 INVITE.
> Via: SIP/2.0/UDP
> 10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
> Supported: 100rel,sipvc,replaces,timer.
> User-Agent: Nortel CS1000 SIP GW release_4.5 version_sse-4.50.88.
> P-Asserted-Identity:
> <sip:5077740;phone-context=udp at compuware.com;user=phone>.
> Privacy: none.
> Contact:
> <sip:5077740;phone-context=udp at compuware.com:5060;maddr=10.3.104.104;tra
> nsport=udp;user=phone>.
> Route: <sip:10.0.12.51;lr;ftag=as75bb16a1>.
> Allow:
> INVITE,ACK,BYE,REGISTER,REFER,NOTIFY,CANCEL,PRACK,OPTIONS,INFO,SUBSCRIBE
> ,UPDATE.
> Content-Type: application/SDP.
> Content-Length: 148.
> .
> v=0.
> o=- 121469 3 IN IP4 10.3.104.104.
> s=-.
> t=0 0.
> m=audio 5202 RTP/AVP 0 8 18.
> c=IN IP4 10.3.102.105.
> a=fmtp:18 annexb=no.
> a=ptime:20.
> a=sendrecv.
>
> #
> U 10.0.12.51:5060 -> 10.3.104.104:5060
> SIP/2.0 100 Giving a try.
> From: <sip:77740 at 10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
> To: "Brad Watkins"<sip:71841 at 10.0.12.51:5062>;tag=as75bb16a1.
> Call-ID: 75bd11cb40e6f85239b3bf6c525bb206 at 10.0.12.51.
> CSeq: 2 INVITE.
> Via: SIP/2.0/UDP
> 10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
> Server: OpenSER (1.2.3-notls (i386/linux)).
> Content-Length: 0.
> .
>
> #
> U 10.0.12.51:5060 -> 10.3.104.104:5060
> SIP/2.0 404 Not here.
> From: <sip:77740 at 10.0.12.51>;tag=6868030a-13c4-4848318e-d46a11b5-7671.
> To: "Brad Watkins"<sip:71841 at 10.0.12.51:5062>;tag=as75bb16a1.
> Call-ID: 75bd11cb40e6f85239b3bf6c525bb206 at 10.0.12.51.
> CSeq: 2 INVITE.
> Via: SIP/2.0/UDP
> 10.3.104.104:5060;branch=z9hG4bK-484831a0-d46a55df-21eb.
> Server: OpenSER (1.2.3-notls (i386/linux)).
> Content-Length: 0.
>
>
>
> This is with a basic loose-routing construct from the sample config:
>
> 	if (has_totag()) {
> 		# sequential request within a dialog should
> 		# take the path determined by record-routing
> 		if (loose_route()) {
> 			loose_route();

Take off the second "loose_route()", it has been done into the "if" stament.

> 			route(1);
> 		} else {
> 			sl_send_reply("404","Not here");
> 		}
> 		exit;

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 at 10.0.12.51:5062 SIP/2.0

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.

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ñaki Baz Castillo




More information about the sr-users mailing list