Re: [Serusers] ONSIP Script + Java Rockx ser 0.9.0 script

Hi Iqbal, Thanks for the detailed reply....I have an outline plan for how my asterisk/ser setup will work (using the onsip callforward script with rtp proxy)....If the logic is messed up please let me know because I'm trying to minimize the chance of making stupid changes to the config which will affect other things....Then hopefully if this makes sense it might help other people.... #########################Leaving voicemail################################ 1) In the usr_preferences table in the ser database have an entry for user 2092. Insert into usr_preferences (username, attribute, value) values ("2092", "voicemail", "y"); 2) In Route[3] (used for call invite handling) if(avp_db_load("$ruri/username","s:voicemail")){ if(avp_check("s:voicemail", "eq/y/I")){ setflag(5); }; }; This will check if the user wants to use voicemail according to the preference that is set for them in the usr_preferences table. I they don't want to use voicemail set value to "n" 3) In failure route[1] if(isflagset(5) && t_check_status("408")){ avp_delete("s:voicemail"); resetflag(5); append_branch(); route(x); break; }; 4) route[x] { acc_db_request("missed called", "missed_calls"); revert_uri(); rewritehostport("x.x.x.x:5064"); append_branch(); t_relay_to_udp(x.x.x.x", "5064"); break(); } ###################################Playing Voicemail####################### 1) as above 2) as above 3) If the user dials their own username they will be diverted to asterisk if (method=="INVITE"){ if(avp_check("i:34", "eq/$ruri/i")){ if(isflagset(5)){ route(x); break; } else{ sl_send_reply("486", "Busy"); break; }; }; }; 4) route[x] as before Aisling. -----Original Message----- From: Iqbal [mailto:iqbal@gigo.co.uk] Sent: 23 September 2005 10:24 To: Mark Aiken Cc: Aisling; serusers(a)lists.iptel.org Subject: Re: [Serusers] ONSIP Script + Java Rockx ser 0.9.0 script Hi @Mark: I agree, but some people only really need ser, or should I say if your route to much to asterisk its pointless having ser, I keep my Ip__IP traffic in ser, in fact my billing there also, asterisk as you mentioned for features, and when my upstream gateway wont support REFER to do transfers, and cool things like call pickup. @Aisling: if (method=="INVITE"){ if(is_user_in("Request-URI", "voicemail")){ setflag(31); }; }; what this will do is to see if the username you have in RURI is in your grp table and has an entry of voicemail next to it, if so it will set a flag 31 if (method=="INVITE") { what this does is basically to see if your are calling yourself, i.e if the from and the RURI is the same, first it stores the from setting, and the compares that to your ruri.Now if they are the same, it will see if flag 31 is set, i.e if you have voicemail attached to the RURI in grp table. If both are true then goto route8, at which point it seems as if your are relaying to another server. You seem to be getting busy, which means that flag 31 is not being set, check your ngrep dump see what your RURI has, and see what entries your grp table has. The problem with matching like this (or at least the problem(s) I had) was that there are alot of different call scenarios which all need to be taken into account. EG my usernames are not e164 numbers, they are part of that number, which means my ruri, and from can be different to the e164 format. Now when a caller calls from 040600, to 0845040602, it should see if 0845xxx is busy, send to voicemail, but in grp ther is no 0845xxx, hence I need to make sure that the check/match is done after the alias lookup. I had to move lookup(aliases) near the to to make sure all my lookups had been done at the start, and then I can start matching. Your best friend will be ngrep, if you start doing the diff call scenarios, and seeing what needs to be matched, you can set 1 run settings, once it all works work out a tidier logic. If you throw asterisk into the loop, you add another headache (depending on what you do), cause asterisk was really designed for ip devices to register with it, but if you register in ser, you could lose some of that info (although latest beta, has some nice SIP header parsing, to pull info from). The other problem you may hit with voicemail, depends on how you set your username, initially my subscriber table had names for username...eg Iqbal, and the alias would be 040600, or whatever, problem with this was that voicemail in asterisk is better with number, especially when you have to dial the mailbox number from your phone :-), so I switched the subscriber table to hold the number, cause I think unless you will be using software dialers, no one will type in names. "voicemail=1:500;calltype=i:700;fwd_no_answer_type=1:701;fwd_busy_type All this does is to define aliases, you can use it, or not iqbal Mark Aiken wrote: config routed to the can "voicemail=1:500;calltype=i:700;fwd_no_answer_type=1:701;fwd_busy_type script of get number....I Pauls these seconds "mysql://root:password@localhost/ser") "mysql://root:password@localhost/ser") > >modparam("avpops", "avp_table", "usr_preferences") > >modparam("avpops", "avp_aliases", > >"voicemail=1:500;calltype=i:700;fwd_no_answer_type=1:701;fwd_busy_type > > > > >route { > > > > # > ----------------------------------------------------------------- > > # Sanity Check Section > > # > ----------------------------------------------------------------- > > if (!mf_process_maxfwd_header("10")) { > > sl_send_reply("483", "Too Many Hops"); > > break; > > }; > > > > if (msg:len > max_len) { > > sl_send_reply("513", "Message Overflow"); > > break; > > }; > > > > > > > #------------------------------------------------------------------ #------------------------------------------------------------------ #------------------------------------------------------------------ #------------------------------------------------------------------ #------------------------------------------------------------------ #------------------------------------------------------------------ is if failed"); #------------------------------------------------------------------ sl_send_reply() #------------------------------------------------------------------- caller==callee) "$voicemail")){ -------------------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. .