FreePBX Voicemail Issue using SIP URI Issue

General Help
1

Good Afternoon All,

We are have a strange issue with Our FreePBX configuration, We are using a combination of SIP URI and Sip Trunks, We use the SIP URI on for phone numbers to be used as DID’s and the route into the phone system the phone rings like normal and will kick into voicemail but then will not display onto the users phone I have contacted the phone provider to see if they said that they send all the calls direct to our IP Address,

I ran a sip trace on the call to see if i could see anything strange but i’m not able to, i also sent the same logs to the telephone provider but they said it was out of their scope to even look at the trace.

The Voicemails work internally fine and also work when you call the extensions through the IVR but does not seem to work using URI, i must say this has worked in the past but recently stopped working, i have checked all the settings i can see possible and also updated the system, On the trace i can see the phone is ringing and the system has passed it off to the voicemail where it has created a temp recording but after that it never displays on the system.

I am unable to put a copy of the sip trace on here, Please contact me and that can be shared

Thanks ,

2

When you call the voicemail box, does it say there’s a new message there?

3

Hi,
No nothing, says there is no new messages, when the voicemail comes on I press 0 to see if it would go through to another extension setup and it doesn’t recognise the DTMF Codes either
Thanks,

4

You can post a pastebin link from the SIP trace as outlined here https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs

If you can’t post links, then posts it like this: pastebin .com/url

5

Just to clear things up, there is no difference in a SIP URI and a call sent to a “trunk”.

Regardless if you are using SIP Registration or IP Routing the provider is going to send the call as sip:number@ip:port the only difference between the two is Registration requires you to Auth and update them with your current Location. IP Routing means you’ve given them a static route (IP or FDQN) to send the calls to.

So for your “SIP URI” delivery you still need a Trunk that is going to match against the source IPs of those calls being sent to you. If you don’t have a trunk(s) that matches the source IP(s) then the PBX could reject the call, depending on how you have it setup. Additionally, a trunk just “lets” the call into the PBX you still need a proper Inbound Route to route the call based on the number.

Just wanted to clarify this a little since it seems the OP believes that incoming calls are handled differently between a “SIP URI” and a “Trunk that Registers”. They are not, the same concepts apply to both.

6

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] pbx_builtins.c: Goto (macro-vm,s-CHANUNAVAIL,1)

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] pbx.c: Executing [s-CHANUNAVAIL@macro-vm:1] Macro(“PJSIP/Sip_URI_Trunk-00000074”, “get-vmcontext,2015”) in new stack

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-get-vmcontext:1] Set(“PJSIP/Sip_URI_Trunk-00000074”, “VMCONTEXT=default”) in new stack

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-get-vmcontext:2] GotoIf(“PJSIP/Sip_URI_Trunk-00000074”, “0?200:300”) in new stack

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] pbx_builtins.c: Goto (macro-get-vmcontext,s,300)

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-get-vmcontext:300] NoOp(“PJSIP/Sip_URI_Trunk-00000074”, “”) in new stack

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] pbx.c: Executing [s-CHANUNAVAIL@macro-vm:2] VoiceMail(“PJSIP/Sip_URI_Trunk-00000074”, “2015@default,u”) in new stack

[2018-10-05 14:24:07] VERBOSE[12313][C-00000062] file.c: <PJSIP/Sip_URI_Trunk-00000074> Playing ‘/var/spool/asterisk/voicemail/default/2015/greet.slin’ (language ‘en’)

[2018-10-05 14:24:10] VERBOSE[12313][C-00000062] file.c: <PJSIP/Sip_URI_Trunk-00000074> Playing ‘vm-isunavail.ulaw’ (language ‘en’)

[2018-10-05 14:24:12] VERBOSE[12313][C-00000062] file.c: <PJSIP/Sip_URI_Trunk-00000074> Playing ‘vm-intro.ulaw’ (language ‘en’)

[2018-10-05 14:24:17] VERBOSE[12313][C-00000062] file.c: <PJSIP/Sip_URI_Trunk-00000074> Playing ‘beep.ulaw’ (language ‘en’)

[2018-10-05 14:24:18] VERBOSE[12313][C-00000062] app_voicemail.c: Recording the message

[2018-10-05 14:24:18] VERBOSE[12313][C-00000062] app.c: x=0, open writing: /var/spool/asterisk/voicemail/default/2015/tmp/Kh4r5P format: wav, 0x7fac2404c860

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] app.c: User hung up

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] app_voicemail.c: Recording was 0 seconds long but needs to be at least 1 - abandoning

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] app_macro.c: Spawn extension (macro-vm, s-CHANUNAVAIL, 2) exited non-zero on ‘PJSIP/Sip_URI_Trunk-00000074’ in macro ‘vm’

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] app_macro.c: Spawn extension (macro-exten-vm, s, 33) exited non-zero on ‘PJSIP/Sip_URI_Trunk-00000074’ in macro ‘exten-vm’

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Spawn extension (ext-local, 2015, 2) exited non-zero on ‘PJSIP/Sip_URI_Trunk-00000074’

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Executing [h@ext-local:1] Macro(“PJSIP/Sip_URI_Trunk-00000074”, “hangupcall,”) in new stack

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“PJSIP/Sip_URI_Trunk-00000074”, “1?theend”) in new stack

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx_builtins.c: Goto (macro-hangupcall,s,3)

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“PJSIP/Sip_URI_Trunk-00000074”, “0?Set(CDR(recordingfile)=)”) in new stack

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-hangupcall:4] NoOp(“PJSIP/Sip_URI_Trunk-00000074”, " monior file= ") in new stack

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-hangupcall:5] AGI(“PJSIP/Sip_URI_Trunk-00000074”, “attendedtransfer-rec-restart.php,”) in new stack

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] res_agi.c: Launched AGI Script /var/lib/asterisk/agi-bin/attendedtransfer-rec-restart.php

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] res_agi.c: <PJSIP/Sip_URI_Trunk-00000074>AGI Script attendedtransfer-rec-restart.php completed, returning 0

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Executing [s@macro-hangupcall:6] Hangup(“PJSIP/Sip_URI_Trunk-00000074”, “”) in new stack

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] app_macro.c: Spawn extension (macro-hangupcall, s, 6) exited non-zero on ‘PJSIP/Sip_URI_Trunk-00000074’ in macro ‘hangupcall’

[2018-10-05 14:24:24] VERBOSE[12313][C-00000062] pbx.c: Spawn extension (ext-local, h, 1) exited non-zero on ‘PJSIP/Sip_URI_Trunk-00000074’

7

There’s no voicemail being left.

8

There should be because i’m physically talking to the voicemail after the beep saying this is a test please ignore and then hanging up

9

It says you hung up which means the voicemail app isn’t getting your audio. You need to do a deeper debug of this.

Do the same thing this time from the ASterisk CLI run: pjsip set logger on

We need to see what is actually happening with the call at the SIP level.

10

Thank you,

I have ran the pjsip logger and this is what i got when i called into the system

<— Received SIP request (548 bytes) from UDP:94.75.247.45:5060 —>

BYE sip:IP Address SIP/2.0

Max-Forwards: 12

To: <sip:[email protected]>;tag=0108c07c-5f39-446c-b6c5-5c7a83b0b5f9

From: <sip:447378861994@IP>;tag=3747741827-197647549

Call-ID: [email protected]

CSeq: 2 BYE

Allow: UPDATE,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL

Via: SIP/2.0/UDP 94.75.247.45;branch=z9hG4bK963e.6444c1b7.0

Via: SIP/2.0/UDP 95.211.119.240:5060;rport=5060;branch=z9hG4bK963e.1aa2fb76.0

Reason: Q.850;cause=16;text=“Normal call clearing”

Content-Length: 0

<— Transmitting SIP response (476 bytes) to UDP:94.75.247.45:5060 —>

SIP/2.0 200 OK

Via: SIP/2.0/UDP IP;rport=5060;received=94.75.247.45;branch=z9hG4bK963e.6444c1b7.0

Via: SIP/2.0/UDP IP:5060;rport=5060;branch=z9hG4bK963e.1aa2fb76.0

Call-ID: [email protected]

From: <sip:000@IP>;tag=3747741827-197647549

To: <sip:[email protected]>;tag=0108c07c-5f39-446c-b6c5-5c7a83b0b5f9

CSeq: 2 BYE

Server: FPBX-14.0.3.19(13.22.0)

Content-Length: 0

Please let me know if this helps in anyway

11

No because it’s the end of the call. You need to capture it from the beginning.

12

Confirm that if the SIP URI call is answered at the extension, the extension user can hear the remote party (and vice-versa). If not, we’ll debug that first, being simpler than the voicemail case.

Next, call in via the SIP URI trunk, let it go to voicemail and during the greeting (before the beep) press *. You should hear Asterisk prompt for the password (for the box owner to retrieve his messages). If you can’t interrupt the greeting, it’s likely a re-invite or codec issue and we need a SIP trace. At the Asterisk command prompt, type
pjsip set logger on
make a failing call and post the log here.

If interrupting the greeting does work, it’s possible that Asterisk is not sending RTP during the recording, confusing the provider’s server. Look at /etc/asterisk/asterisk.conf and see whether transmit_silence_during_record is set to yes. If not, try setting it to yes, restart Asterisk and retest. Also, if you have g729 enabled in the trunk, try turning that off.

13

Hi,

I can confirm when the call is answered i can hear the person on the other end and when the voicemail comes onto the system i have tried pressing the * key and that doesn’t detect the DTMF codes

Thanks,

14

Can you post a log showing the incoming INVITE and subsequent responses, especially including the 200 OK and continuing through the BYE?

15

There is so much flying around on this logging screen

16

After making the failing call, view Reports → Asterisk Logfiles.
Copy the relevant info and paste it into http://pastebin.freepbx.org/ .
Post the link here.

17

This is not an efficient way to debug this issue. The “Asterisk Logfiles” will look at the logs but the default logging is set to a verbosity of 3, which is fine and good for basic reviews but you need to raise the verbosity to get more details during the call that the normal logging wouldn’t capture.

Additionally, look at the scenario. Incoming calls is hitting the PBX and going to voicemail. The caller can hear the voicemail greeting and the system recordings but the system does not get any audio or DTMF from the caller. This sounds more like a NAT/network issue and something up with the SDP or the DTMF settings of the trunk.

This is why I wanted to see the pjsip logger output to actually see how the call is being presented, how the RTP is being latched (what IPs, ports). The Asterisk logfiles are great for seeing how Asterisk is passing the call through diaplan and applications but for something like this where the SDP/RTP/Media is having issue, you need more than how the call traversed the dialplan.

So again, I asked for this call with the pjsip logger on please provide that debug.

18

By itself, sure, but pjsip logger is already on – the OP was complaining of its verbosity.
Having the full SIP trace with timestamps and with Asterisk actions interspersed is exactly what I was looking for.

Your idea that the DTMF issue could be a separate problem is interesting. Then, the audio issue could be related to transcoding or to Asterisk not sending RTP when recording.

I had originally ruled out NAT and firewall issues because audio works normally when the call is answered at the extension. However, it’s possible that there are re-invites involved, either explicit or for codec renegotiation, which cause the extension answers case to work differently.

@MichaelCollis01 is this trunk Localphone or Voxbeam (two brands of the same company)? If Localphone, have you tried the trunk with registration instead of SIP URI?

19

Hi,

Thanks for the reply, Its localphone, I have tried SIP Trunking, and that seems to work fine, I have put port forward on for 5060 and the RTP Ports but the SIP URI issues still remain, I can send screenshots of the SIP URI Trunk i have in place if that makes makes any sense to you?

Thanks,

20

That would be useful, but unless we can spot something obvious, we’ll still need the SIP trace.

Then why did you switch to URI? Were you losing registration? If it was only to distinguish multiple DIDs on the same account, changing the trunk context to from-pstn-toheader should allow you to route by DID.