Send voicemail to Exchange UM SIP Trunk

I have a client with a raw Asterisk system and they use Exchange Unified Messaging for their voicemail on it.

We would like to update their old system to FreePBX but we want to keep using Exchange UM for voicemail.

Setting up the SIP trunk to Exchange was a simple matter of copying the config from the old system. Then created an outbound route to send calls to a certian extension to Exchange. We can now dial in to the Exchange UM number from a phone on the new test system and leave a voicemail. Great.

Now, how do I tell the extension to send the call to Exchange?

I see there is a context option on each extension. WHen I put something in there other than default it just dumps the same settings as default in voicemail.conf, just in a different context. How can I use that context?
image

[ucm-vm]
5782 => 1234,FreePBX - Test 1,,,attach=no|saycid=no|envelope=no|delete=no
6115 => 1234,FreePBX - Test 2,,,attach=no|saycid=no|envelope=no|delete=no

[default]
3005 => 1234,FreePBX - Test 5,,,attach=no|saycid=no|envelope=no|delete=no

On the old Asterisk 1.8 system this is in extensions.conf

[send-to-vm]
exten => s,1,Wait(1)
same => n,Playback(nbdy-avail-to-take-call)
same => n,Playback(to-reach-operator)
same => n,Set(TIMEOUT(response)=6)
same => n,Set(TIMEOUT(digit)=1)
same => n,Background(press-0)
same => n,WaitExten(3)
same => n,SipAddHeader(Diversion:<tel:${EXTDIALED}>\;reason=no-answer\;screen=no\;privacy=off)
same => n,Dial(SIP/Exch4UM5065/6010)
same => n,Dial(SIP/ExchUM5065/6010)
same => n,Hangup()

Contexts inside of voicemail are for voicemail only. They aren’t routable

So I need to override the default extension context entirely to get this?

So looking at the call flow, macro-exten-vm is called.

That context has an include that does not exist anywhere.

[macro-exten-vm]
include => macro-exten-vm-custom

Can I drop in a [macro-exten-vm-custom] in extensions_custom.conf?

Also, does an include run before everything else in the calling context?

You can try this but you are about to learn the difficulties of using custom contexts in FreePBX, eg only 1% of them work because of how Asterisk works. Really this probably won’t work for you but you can try.

1 Like

I’ve used custom contexts before with no problems. I understand how Asterisk handles call flow. Certainly not as well as someone that is at this level every day. But I know it.

All contexts I have worked with have always been new, beyond any existing contexts. This is the first time I am trying to get into the middle of one.

Basically, I just want to know where i need to break in to short circuit the VM process.

Upon looking more, it seems macro-vm-custom may be the better place.

Quickly looking over those contexts, you won’t get anywhere by defining macro-vm-custom or macro-exten-vm-custom. You are going to need to copy the contexts macro-vm, macro-exten-vm (possibly others) into the file extensions_override_freepbx.conf and then start hacking at them until they do what you want.

Edit - actually, there may be a supported GUI way to do some of this. On the Advanced tab at the bottom you have Optional Destinations which you can define on no answer. Then you need to re-define the VM feature codes.

1 Like

I was really hoping not to have to do that. because then I have to rematch if something updates. That is why I was looking at -custom.

Specifically this bit is what I need to replicate in order to have their existing functionality work.

[send-to-vm]
exten => s,1,Wait(1)
same => n,SipAddHeader(Diversion:<tel:${EXTDIALED}>\;reason=no-answer\;screen=no\;privacy=off)
same => n,Dial(SIP/Exch4UM5065/6010)
same => n,Hangup()

I’ll look at it. The less custom the better, always. That is one of the reason for moving to FreePBX instead of a home grown system.

@lgaetz Possibilities… For an immediate test i did this.

I then called 5782 from 6115 and rejected the inbound call.

Exchange immediately picked up and ask for the pin for extension 6115. So it connected as the ext calling. Great. but not what I was after… So more testing of things, but this is a decent direction to try.

Referencing the old dialplan, it is calling ext 6010 and using SIP headers.

As my next simple test, I created a custom destination
image

Then I used this custom context.

[uc-vm]
exten => s,1,Wait(1)
;exten => s,n,SipAddHeader(Diversion:<tel:${EXTDIALED}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s,n,SipAddHeader(Diversion:<tel:5782>\;reason=no-answer\;screen=no\;privacy=off)
exten => s,n,Dial(SIP/ChiExch4UM5065/6010)
exten => s,n,Hangup()

I then called 5782 from 6115 and everything worked perfectly.

I need to have 5782 obviously be a variable.

This is called from ext-local, but I am having a hard time finding documentation on what variables are available in what context.

The life force of the channel, its qi, can be gleaned by the roughly named DumpChan Application:

[uc-vm]
exten => s,1,Wait(1)
exten => s,n,DumpChan
*snip*

All channel parameters including variables will be dumped to the console

Thanks.

@lgaetz Ok thanks, this works perfectly as is.

[uc-vm]
exten => s,1,Wait(1)
exten => s,n,SipAddHeader(Diversion:<tel:${DEXTEN}>\;reason=no-answer\;screen=no\;privacy=off)
exten => s,n,Dial(SIP/Exch4UM5065/6010)
;exten => s,n,DumpChan
exten => s,n,Hangup()

But now to add functionality!!

We have multiple Exchange UC servers all seutp as trunks and I made outbound routes specifically to test them.

Now I made a single outbound route with all the Exchange UC trunks. Can I send this context that way instead of dialling each trunk?

The old context had all four UC servers one after the other each time. Obviously I can do that here. But an outbound route would handle this better.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.