[Users] Proper FROM mangling

[Klaus Darilion]

Hi Bogdan!

Thus, all data is stored in the parameters of the RR header, right?

But his also means, that "anonymous" call are not really anonymous, as 
the client B could restore the original From: header from the 
RR-paramter, right?

regards
klaus

Bogdan-Andrei Iancu wrote:
> Hi everybody,
> 
> Based on the latest dialog supported (which was added in RR module), I 
> was able to implement in the "uac" module proper FROM replacement. The 
> missing issue was correct restoring/replacement of FROM in the 
> sequential requests. As restoring information was kept in FROM param, 
> this information didn't show up in all sequential requests (for example 
> in ones from original caller to callee).
> 
> Now, based on the new RR API, the module keeps the restoring info in the 
> Route header which will show up for sure in all sequential request; so 
> the module will be able to track and fix all sequential replies and 
> requests. This implies fixing FROM or TO hdr, depending of the request 
> direction.
> 
> 
> For people not interested in implementation details, I put first the 
> usage description:
> There are 3 restore mode for the module to work (for FROM mangling):
>    "none" -> NO RESTORE; the FROM URI will be changed and no further 
> effort or info will be done/store in order to restore its value neither 
> is sequential replies, nor requests;
>    "manual" -> information needed for restoring the value will stored in 
> RR parameter; all the replies and local generated requests (ACK and 
> CANCEL) will be automatically fixed, but no sequential request will be 
> restored; the admin has full liberty to do it from script by using the 
> restore_from() function.
>    "auto" -> FULL AUTO RESTORING -> information needed for restoring the 
> value will stored in RR parameter and all sequential request and replies 
> will be fixed *automatically*
> 
> NOTE: for restore modes different than "none", the module will try to 
> bind itself to RR and TM modules, so take care and load them.
> 
> 
> For people interested in implementation details.
> 
> Shortly, here is how it works:
> 
> Let's consider a call initiated from UA A to UA B (or from A to B)
> 
> Now, since sequential requests may flow from A to B or B to A we need to 
> be able both to restore original TO in requests from B to A and to 
> replace with new FROM in request from A to B; which means that during 
> the dialog we need to know both old and new FROM uris. As in each 
> situation on of the value is known (depending of the direction, either 
> the new, either the new URI appears), the simplest and most efficient 
> way to store both in minimum size is to store the XOR value of them; 
> having the XOR value and one of the uris, we can determine the other URI 
> (  (x^y)^y=x  :) )
> 
> 
> 
>    A                                 Proxy                            
>      B
> 
> 1) initial request:
> 
>            From:OLD_URI                              FROM:NEW_URI
>                                                   RR:(OLD_URI^NEW_URI)
>    --------------------------------->     
> ----------------------------------->
> 
> 2) final reply
> 
>           From:OLD_URI                                FROM:NEW_URI
>        RR:(OLD_URI^NEW_URI)                       RR:(OLD_URI^NEW_URI)
>    <---------------------------------     
> <-----------------------------------
> 
> 
> 3) re-invite (direction downstream)
> 
>            From:OLD_URI                              FROM:NEW_URI
>       Route:(OLD_URI^NEW_URI)                       
> --------------------------------->     ----------------------------------->
> 
> 4) final reply
> 
>           From:OLD_URI                                FROM:NEW_URI
>    <---------------------------------     
> <-----------------------------------
> 
> 5) BYE (direction upstream)
> 
>           TO:OLD_URI                                TO:NEW_URI
>                                                 Route:(OLD_URI^NEW_URI)
>    <---------------------------------     
> <-----------------------------------
> 
> 6) final reply
> 
>           TO:OLD_URI                                TO:NEW_URI
>    --------------------------------->     
> ----------------------------------->
> 
> 
> 
> 1) initial equest has the FROM URI changed from scrip via replace_from() 
> ; XOR between NEW_URI and OLD_URI is added to RR as parameter
> 
> 2) the reply (actualy all replies) is fixed via TM callbacks
> 
> 3) the re-invite is detected via RR callback as having the RR param; as 
> the direction is downstream,it will have the OLD_URI *FROM* changed with 
> the NEW_URI = (OLD_URI^NEW_URI)^OLD_URI
> 
> 2) the reply is fixed via TM callbacks
> 
> 3) the BYE is detected via RR callback as having the RR param; as the 
> direction is upstream,it will have the NEW_URI *TO* changed with the 
> OLD_URI = (OLD_URI^NEW_URI)^NEW_URI
> 
> and this is all the magic behind :)
> 
> 
> 
> regards,
> bogdan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
> 
>