[Users] Proper FROM mangling

[Bogdan-Andrei Iancu]

Hi Klaus,

yes, that's correct - as long as no dialog info is kept on the server, 
but stored into the messages, both parties will be able to see this info 
- the question is if they are able to interpret it (since the 
representation is quite specific - XOR between two uris and B64 encoded).

So, with the current approach, if somebody really wants and know how 
will be able to extract original URI from the message.....:) (offline, 
of course)....To prevent this, the info may be encrypted with some 
random key by OpenSER, but not sure if it pays the effort.

My final goal is to have a new module to offer dialog support on server 
- all dialog related info will be stored on the server and the RR/Route 
will contain only a key (hash/index/etc) to find this info on the 
server. In this case, the info will be hidden to both parties.....but 
this is still a plan.......

regards,
bogdan


Klaus Darilion wrote:

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