Iqbal wrote:

I never got round to tying this, just got bogged down with other configs, if you have any luck give me a shout, I might take a look towards the end of the week

I played around a little with it and got it to work with SER 0.9.x. Here is the config snippet (assuming you use 1000@your.domain for callbacks):

modparam("avpops", "use_domain", 1) modparam("avpops", "avp_url", "mysql://ser:heslo@localhost/ser") modparam("avpops", "avp_table", "dummy") # it complains if not set modparam("avpops", "avp_aliases","callback=i:995")

route {

# the usual stuff like basic checks, NAT fixes and proxy # authentication goes here...

# check for callback if(uri =~ "^sip:1000@") { # load callback-avp from callback table if(avp_db_load("$from", "$callback/callback")) { avp_pushto("$ruri", "$callback"); avp_db_delete("$from", "$callback/callback"); avp_delete("$callback"); } else { # announcement that no callback available or a 4xx reply # goes here... } }

# lookup aliases and location here...

# if it's a call to a local user, prepare for storing callback t_on_failure("2");

# then do some additional stuff and t_relay() here... }

failure_route[2] { # set callback if callee is busy or N/A if(t_check_status("480|486") && method == "INVITE") {

# store caller into callback table avp_write("$from", "$callback"); avp_db_store("$ruri", "$callback/callback"); avp_delete("$callback"); } }

And here's the callback table for MySQL:

CREATE TABLE `callback` ( `uuid` varchar(64) NOT NULL default '', `username` varchar(100) NOT NULL default '', `domain` varchar(128) NOT NULL default '', `attribute` varchar(32) NOT NULL default '', `value` varchar(128) NOT NULL default '', `type` int(11) NOT NULL default '0', `modified` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, PRIMARY KEY (`username`,`domain`,`attribute`,`value`) );

Hth, Andy

Iqbal wrote:

nice, how do you pick the last number only, or would it be better when you stored a missed call, that you deleted other entries in the table.

A valid objection... in this case it's just luck, because avps are pushed in reverse order. And SER logs an error if the same caller calls the callee twice because user/domain/attribute/value is the primary key.

So you're right, it would be nicer to call avp_db_delete before avp_db_store in failure_route.

Andy

cool will try it out, thanks Andreas

iqbal PS have you worked on reading out the missed number, I was thinking asterisk with Festival or something

Andreas Granig wrote:

I wrote:

...

So you're right, it would be nicer to call avp_db_delete before avp_db_store in failure_route.

So finally the corrected failure-route looks like this (needs an additional DB query though):

failure_route[2] { if(t_check_status("480|486") && method == "INVITE") { avp_write("$from", "$callback"); revert_uri(); avp_db_delete("$ruri", "$callback/callback"); avp_db_store("$ruri", "$callback/callback"); avp_delete("$callback"); } }

Andy

.

Hi Andreas,

Thanks a lot for that answer and sorry for the late reply - I'll give it a try now and keep ye posted with how I get on.

Many thanks again.

Aisling.

-----Original Message----- From: Andreas Granig [mailto:andreas.granig@inode.info] Sent: 11 October 2005 16:41 To: Iqbal Cc: serusers@lists.iptel.org; Aisling Subject: Re: [Serusers] Missed Call Return

I wrote:

So you're right, it would be nicer to call avp_db_delete before avp_db_store in failure_route.

So finally the corrected failure-route looks like this (needs an additional DB query though):

failure_route[2] { if(t_check_status("480|486") && method == "INVITE") { avp_write("$from", "$callback"); revert_uri(); avp_db_delete("$ruri", "$callback/callback"); avp_db_store("$ruri", "$callback/callback"); avp_delete("$callback"); } }

Andy

-------------------Legal Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.

-------------------Legal Disclaimer---------------------------------------

The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.