[Serusers] call forwarding

[Jiri Kuthan]

At 03:24 AM 8/7/2004, O'Shaughnessy Evans wrote:
>Jiri Kuthan <jiri at iptel.org> wrote:
>[...]
>> >I've seen some talk about cpl, which seems like it could be                  
>> >used to forward a call.  Has anyone used cpl to forward calls?               
>>                                                                               
>> If you are referring to things such as personalized user                      
>> call forwarding on busy, on unavailable, etc., yes, that's                    
>> what CPL is good for and we actually used it this way.                        
>
>What if I just want to forward all missed calls (forward on busy, on
>no answer, etc) to a ser/sems server?  Do I need to use CPL for that?
>Every example I've seen for forwarding to a voicemail server, where
>a failure_route is used, sends the call to a specific mailbox (at
>least as far as I understand it).  For example, from the end of
>http://www.mit.edu/afs/athena/project/sip/sip.edu/ser.shtml:
>
>    failure_route[4] {
>      append_branch("sip:80000 at 10.1.2.5");
>      append_urihf("CC-Diversion: ", "\r\n");
>      append_hf("P-hint: OFFLINE-VOICEMAIL\r\n");
>      t_relay();
>    }
>
>I've seen many other examples that do essentially the same thing.
>I want each user to have their own voicemail box (or, rather, their
>voicemail should be emailed to their own registered email address).
>It seems to me this is the way the voicemail system was designed to
>work, and for calls that go straight to voicemail (e.g. the user
>isn't online) it works fine.

Indeed -- you can do it using SER configuration for global (as 
opposed to personal) preferences.


>But for some reason routing to the voicemail server via forward() or
>t_relay() from a failure_route gets me a fast busy instead.  The odd
>thing is that the call is being forwarded to the VM server, but the
>caller never hears the announcement and just gets that fast busy
>immediately.  Can someone please point me in the right direction to sort
>this one out?

You need to troubleshoot config file and message dumps -- I can't say
more without seeing them either. One thing which strikes me is use
of forward -- for all the "do-something-on-error", you need stateful
processing, i.e., use the t_.* action family.

-jiri