Re: [Users] Proper FROM mangling

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(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users