22 Aug
2005
22 Aug
'05
11:34 a.m.
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