Re: [SR-Users] why use received as RURI for nathelper OPTIONS ping?

Hello, When outbound is fully supported the use of received parameters on URIs and the received column in the location table will (in theory at least) be able to be deprecated. This is because all of the information that would previously have been stored in these is now in the flow-tokens in Record-Route:/Route: and Path: headers. The biggest thing in the way of this right now is that the current outbound on Kamailio does not contain everything it requires for single-server proxy/registrar support. What is required is: * In configuration you must use add_path() even if you are a single-server. add_path() works on lumps so this needs to be applied before the registrar:save() function is called (I think msg_apply_changes() should do this). * The registrar module needs to be updated so that lookup(), when running as a single-server with outbound, it adds the Path: header from the location table as a Record-Route:. If there are multiple matching contacts (that is parallel forking is in use) then a different Record-Route: must be added for each parallel branch. registrar must also set $du for each branch based on the flow-token from the Path: header stored for that contact. The t_*_contacts() functions in the tm module probably require changes for this too. * This also means that, even though there is a single proxy/registrar here, there will be two Record-Routes:. The first will have been added to the dialog forming request when it arrived and will contain a flow-token pointing to the originator of the request. The second is the one added by the registrar:lookup() function which contains a flow-token pointing to the destination of the call. This means that the dialog will use a form of double-RR which the rr:loose_route() function needs to be modified to handle. There are some distinct advantages to the above over contact aliasing, mainly that it should help with interoperability issues (especially with SBCs which strip and do no restore parameters they do not recognise) and it should be easier for non-Kamailio users to understand as it is standards based. If/when the above changes have been made I would also like to see nat_uac_test() moved out of the nathelper module and into another (perhaps siputils). This makes it easier for people to have a clear choice of NAT traversal mechanisms, SIP outbound or contact aliasing. Regards, Peter On Mon, 2013-01-07 at 18:32 +0100, Andrew Pogrebennyk wrote: -- Peter Dunkley Technical Director Crocodile RCS Ltd