[OpenSIPS-Devel] [ opensips-Patches-3036052 ] [path] Fix "use_received" rr callback

[SourceForge.net]

Patches item #3036052, was opened at 2010-07-28 18:24
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3036052&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Christophe Sollet (csollet)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [path] Fix "use_received" rr callback

Initial Comment:
Path rr callback overwrite transport information from R-URI when it use the received param as this param doesn't contain any transport information but only NATed IP and port.
This patch add the transport param to the dst_uri if present in R-URI.



----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-08-03 18:22

Message:
Hi Christophe,

Got it....in this case, the LR callback from PATH module should be called
twice...or better, only for the second Route - the first one (from PATH) 
is used by the previous hop just to get to the outbound proxy...

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Christophe Sollet (csollet)
Date: 2010-08-03 11:11

Message:
Hi Bogdan,

It would works by default if the next hop is not NATted. As I understand
the thing, without the RR callback, the message would be forwarded to the
next route or to the R-URI if no next route but, in the both case, it can
be a private IP unreachable from the proxy. The path RR callback read the
received param to force a dst_uri.

So, aside if lookup can handle the received param, I fail to see how the
proxy will contact the NATed next hop...

Regards,
Christophe.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-08-03 01:50

Message:
To be honest I fail to see the purpose of the RR callback set by PATH
module - once the lookup loads the path array as Route headers, the
loose_route works by default....no need for anything extra from PATH module
itself ....Or maybe I'm missing something on the PATH mechanism......

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Christophe Sollet (csollet)
Date: 2010-08-02 20:44

Message:
Hi Bogdan,

So, if I got the point, as lookup set force_send_socket from the second
Route header and as path already store the transport in it, the path
callback have to get the transport set by lookup in order to not overwrite
it.

But, one question : The transport extracted on the second route is not
visible by the path callback. Should I add a "r2_routed_params" to the RR
callback to extract the information or do you see another way to get this
information without rr changes ?

Regards,
Christophe.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-08-02 18:11

Message:
Hi Christophe,

I'm still convinced that adding the transport to Path is the correct way -
if you have protocol change, you will have 2 PATH hdrs. Like (for
REGISTER):

UAC   (ct;tcp)  --->tcp---> opensips (path;udp , path;tcp)   --->udp---->
registrar

So, you will have in INVITE (in the other way):
RURI: ct;tcp
Route: path;udp
Route; path;tcp

so, it will go via UDP to opensips, switch to TCP before sending to end
point.

Regards,
Bogdan

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Christophe Sollet (csollet)
Date: 2010-08-02 16:14

Message:
Hi bogdan,

You're right, this can be working only on the last Route : really a bad
idea... :) 

But I'm unsure about adding the transport param on the path header to
merge it at callback level : The transport will be used by the previous hop
(In  a scenario with a registrar and a front proxy, the registrar will try
to contact the proxy with the proto used between the UA and the proxy).

Attached patch (path-transport.diff) add the transport param as a uri
param of the received value (the whole is surrounded by double quote).

Regards,
Christophe.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2010-08-01 23:08

Message:
Hi Christophe,

I'm not sure this is correct because:

1) a Route header must be self-sufficient, so if a TRANSPORT info is
needed, it must be included in it; that means the fix must be done when the
PATH hdr is added, not when ROUTE hdr is used.

2) mixing the info from a ROUTE hdr with the info from RURI is not
correct, as they are two independent routing hops. RURI defines the
terminus point, while the ROUTE is one of the hops. Between the current hop
and the terminus point, the protocol may change several time, so you should
not change the proto (somewhere at a hop) based on the properties of the
terminus point.

In my opinion, the trasnport info must be added to the PATH hdr and the
callback just merge the TRANSPORT and RECEIVED to build the DST URI.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3036052&group_id=232389