[Users] Proper FROM mangling

[Bogdan-Andrei Iancu]

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