I'm not sure that process persistence is what Brett was looking for but rather 
Dialog persistence.  I have found that local memcache support is very fast and 
takes care of this type of need quite well.  

Using a unique key, made up perhaps of the SIP call-id and type of value like 
"B2Bwhatever_callerid" and the value you desire it to contain will allow you to 
store, retrieve, and delete the value at will from any point in call 
processing.  Plus you can pass in an expire time so it will be deleted in the 
event something goes wrong with the call.  If you want to get real fancy you 
could even set up a memcached server and do those same functions from 
distributed Proxies.

http://www.opensips.org/Resources/DocsTutMemcache.

There are always a thousand ways to do any one thing in opensips, like storing 
the avp to the database 

                case "INVITE" :
                                avp_db_store("$ci", "$avp(s:epochtime)"); 
#epochtime set in "set variables route" - store it to db with call id as uuid.
                                ....

and grabbing it back

                case "BYE" :
                        avp_db_load("$ci", "a"); #get all records from db 
stored with this call id as uuid.
                        #this caused epochtime avp to become multi.
                        avp_db_delete("$ci", "a"); #get rid of db entries for 
this call
                        ....

(this example doesn't exactly match your need but you get the idea) but 
memcache is one way to do this job.


Richard

On Oct 13, 2010, at 3:13 AM, Anca Vamanu wrote:

> Hi Brett,
> 
> I think using script variables should work - 
> http://www.opensips.org/Resources/DocsCoreVar#varscript.
> 
> Regards,
> Anca
> 
> On 10/13/2010 01:31 AM, Brett Woollum wrote:
>> 
>> Hi Anca,
>> 
>> I figured out the solution that you were referring to. I added the 
>> local_route section and changed the header in there, and it works.
>> 
>> The only problem now is that the AVP variable I set in route doesn't seem to 
>> be persistent into the new request inside local_route. This is a problem 
>> because I need some way to send the variables to local_route so that I can 
>> put them into the new request. Is there a way to make an AVP variable 
>> persistent into the local_route as well? Or maybe there is a better way to 
>> make these variables accessible from inside local_route?
>> 
>> Here is my working code (with statically set caller id. I need to make this 
>> dynamic):
>> local_route {
>>     if (is_method("INVITE")) {
>>         remove_hf("From");
>>         append_hf("From: \"TEST3\" <sip:[email protected]>;tag=$ft\r\n");
>>         #exit;
>>     }
>>     if (is_method("BYE") ) {
>>         acc_log_request("internally generated BYE");
>>     }
>> }
>> 
>> Brett Woollum
>> [email protected]
>> 
>> 
>> ----- Original Message -----
>> From: "Anca Vamanu" <[email protected]>
>> To: [email protected]
>> Sent: Tuesday, October 12, 2010 2:37:55 AM GMT -08:00 US/Canada Pacific
>> Subject: Re: [OpenSIPS-Users] B2BUA "From" Header & Caller-ID Question
>> 
>> Hi Brett,
>> 
>> The b2bua generates a new request with the info from the received one. The 
>> problem is with the changes upon a request not being visible to the 
>> following functions called from the script. 
>> So you have to change the header on the generated one, in local route.
>> 
>> Regards,
>> Anca
>> 
>> 
>> On 10/12/2010 10:24 AM, Brett Woollum wrote:
>> In addition, the uac_replace_from(display,uri); function does not seem to 
>> work either. I tested this function by putting:
>> 
>> uac_replace_from("TEST", "sip:[email protected]");
>> 
>> immediately above the call to B2B_INIT_REQUEST and the outbound "From:" 
>> header remains unchanged (incorrect).
>> 
>> Brett Woollum
>> [email protected]
>> 
>> 
>> ----- Original Message -----
>> From: "Brett Woollum" <[email protected]>
>> To: "users-request" <[email protected]>
>> Sent: Monday, October 11, 2010 11:53:39 PM GMT -08:00 US/Canada Pacific
>> Subject: [OpenSIPS-Users] B2BUA "From" Header & Caller-ID Question
>> 
>> Hello,
>> 
>> I have a working implementation of the B2BUA modules for OpenSIPS. One 
>> problem I am having is that the B2BUA module doesn't seem to respect the 
>> "From:" header that I updated before B2B_INIT was called (at the end of the 
>> script). Before I call B2B_INIT, my script looks up the correct caller-id 
>> from a database and replaces the "From:" header with the new information. 
>> Here is that code:
>> 
>> xlog("This is an external call...");
>> avp_db_query("select id from subscriber where username=\"$fU\" AND 
>> domain=\"1.2.3.4\"", "$avp(s:subscriber_id)");
>> if(is_avp_set("$avp(s:subscriber_id)")){  
>>                             avp_db_query("select 
>> external_cid_name,external_cid_uri,external_cid_uri_domain from cid where 
>> subscriber_id=\"$avp(s:subscriber_id)\"", 
>> "$avp(s:external_cid_name);$avp(s:external_cid_uri);$avp(s:external_cid_uri_domain)");
>>                             remove_hf("From");
>>                             append_hf("From: \"$avp(s:external_cid_name)\" 
>> <sip:$avp(s:external_cid_uri)@$avp(s:external_cid_uri_domain)>;tag=$ft\r\n");
>> }
>> 
>> The resulting "From": header is perfect (it includes the new caller-id 
>> information) and works without problems when I don't use the B2BUA module. 
>> It seems as though the B2BUA module (which is called last in the script) 
>> does not respect the new header, and instead processes the call using 
>> whatever was in $fu when the script started. Unfortunately $fu is not 
>> writable, so I can't directly change it. 
>> 
>> What are some possible work-arounds to get the B2BUA module to create the 
>> new call but include the "From:" header that I've updated earlier in the 
>> script? 
>> 
>> Any ideas are greatly appreciated!
>> 
>> Brett Woollum
>> [email protected]
>> 
>> 
>> _______________________________________________ Users mailing list 
>> [email protected] 
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> _______________________________________________
>> Users mailing list
>> [email protected]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>   
>> 
>> 
>> -- 
>> Anca Vamanu
>> www.voice-system.ro
>>   
>> 
>> _______________________________________________ Users mailing list 
>> [email protected] 
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> _______________________________________________
>> Users mailing list
>> [email protected]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>   
> 
> 
> -- 
> Anca Vamanu
> www.voice-system.ro
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to