time conditions

[s2svoip]

can anyone shed any light on what you need in the alternate destination field to send a call to an external number in a time condition, my thought was just an extension with call forward enabled but want to confirm. thanks!

 

[Adrian Fretwell]

In its simplest form, you can create a dialplan entry with a couple of lines and set it's destination field to True, see the screenshot below. This uses local extension 788 to call external 123 (123 is the speaking clock in the UK).

Of course you may want to also add other channel variables that you would normally set in an outbound route - maybe??

 

[s2svoip]

thanks Adrian, will do some testing with this!

 

[hamagid]

You can set an outbound destination and select it from the dropdown in the time condition.

 

[s2svoip]

thanks @hamagid and @Adrian Fretwell i ended up copying the standard outbound route so it had all the channel variables, it shows up in outbound destinations, the dialplan looks like the below, but I am seeing some odd behaviour on forwarded calls, it connects but the destination receiving the calls gets the call but then has no audio / dead air - very odd, this is a live server with no firewall issues etc so I don't think its a nat issue or anything like that , its just a call forward

 

[Adrian Fretwell]

There is nothing in that screenshot that would affect audio. I would bet the problem is elsewhere. In situations like this I always get a packet capture so I can see where audio is being sent.
Have you tried a different destination to see if the problem still exists. I often send or receive from/to a mobile phone in an attempt to reduce anyone else's VoIP involvement.

 

[s2svoip]

ive started testing with my mobile and yes its the same thing dead air, I've got the sngrep -c on the server - would that help?

 

[s2svoip]

this was an interesting firewall issue blocking the voice, still looking into what caused it. live server has been running for years with no issues, so still investigating.

 

[whut]

Which firewall is blocking the voice? fail2ban, iptables, event guard, vps-level? You can turn them all off and start testing after turning each one on. @hamagid 's answer is a very simple way to have an external number be available to your destinations and alternate destinations.

 

[s2svoip]

@whut thanks for prompting for more info, might help someone else

in this case it was the vps level, i plan on doing some more testing but i think it was the fact I had the RTP UDP ports locked down, did not notice because 99% of client calls are analogue via my sip trunk provider, but I think the odd call was voip where the upstream peer was trying to send voice direct to mine