Vega 50 Forwarding Issue

Commercial Products and Partners Sangoma
1

Hi all,

I’m having an issue which may be caused by our Vega 50. I have several Grandstream phones using the Vega as a proxy to the FreePBX server. The Vega is configured to be in Forward To ITSP mode, so it is caching SIP registrations.

The problem is that when one extension configured to use the Vega as outboundy proxy calls another extension configured to use the Vega as outboundy proxy, the call goes immediately to voicemail and Asterisk shows “Everyone is busy/congested at this time”. If either phone is NOT configured to use the Vega, the call goes through normally. Calls to other destinations such as park slots or conference lines go through fine.

I did a factory reset on the Vega (firmware R088S055) and changed ONLY the following settings, just to see if something had been changed. The problem persists after doing this. I’ve removed certain values for security.

set lan.name [Deleted]
set quick.voip.proxy.outbound_proxy_addr 127.0.0.1	
set quick.voip.proxy.proxy_addr [Deleted]
set quick.voip.proxy.proxy_domain_name [Deleted]
set quick.voip.proxy.outbound_proxy_port 6060	
set quick.voip.useoutbound "Yes"	
set quick.country US	
set sipproxy.rx_port 6060	
set sipproxy.realm [Deleted]
set sipproxy.mode forward_to_itsp	
set sipproxy.itsp_proxy.1.enable 1
set sipproxy.itsp_proxy.1.ipname [Deleted]
set sipproxy.itsp_proxy.1.port 5060	
set sipproxy.trust.1.enable 1
set sipproxy.trust.1.ipmin [Deleted]	
set sipproxy.trust.1.ipmax [Deleted]
set lan.if.1.use_dhcp 0
set lan.if.1.ip [Deleted]
set lan.if.1.subnet 255.255.255.0	
set lan.gateway.ip [Deleted]	
set dns.1.ip [Deleted]
set ntp.ip pool.ntp.org	
set sip.profile.1.reg_domain [Deleted]
set sip.profile.1.proxy.1.enable 1	
set sip.profile.1.proxy.1.ipname 127.0.0.1	
set sip.profile.1.proxy.1.port 6060	
set sip.profile.1.registrar.1.enable 0	
set sip.profile.1.registrar.1.ipname 127.0.0.1	
set sip.profile.1.registrar.1.port 6060	
set planner.profile.23.plan.1.srce IF:99..,TEL:9<(.*)>	
set planner.profile.23.plan.2.srce IF:99..,TEL:9<(.*)>	
set planner.profile.23.plan.3.srce IF:99..,TEL:9<(.*)>	
set planner.profile.23.plan.4.srce IF:99..,TEL:9<(.*)>	
set planner.profile.20.plan.1.dest IF:9901,TEL:[ext]	
set planner.profile.20.plan.2.dest IF:9901,TEL:[ext]	
set planner.profile.20.plan.3.dest IF:9901,TEL:[ext]	
set planner.profile.20.plan.4.dest IF:9901,TEL:[ext]

These lines show up in the debug output from Asterisk when extension 3348 calls extension 3344 (this is just a snippet, the full output from start to finish can be found at http://pastebin.com/304RJ2Eq):

== Spawn extension (from-internal, 3344, 1) exited non-zero on 'PJSIP/3344-00000022'
    -- PJSIP/3344-00000022 Internal Gosub(func-apply-sipheaders,s,1) complete GOSUB_RETVAL=
    -- Called PJSIP/3344/sip:[email protected]:6060
    -- Connected line update to PJSIP/3348-00000021 prevented.
    -- Now forwarding PJSIP/3348-00000021 to 'Local/VSENP0000002f@from-internal' (thanks to PJSIP/3344-00000022)
[2016-09-22 09:44:19] NOTICE[22739][C-00000012]: app_dial.c:901 do_forward: Not accepting call completion offers from call-forward recipient Local/VSENP0000002f@from-internal-0000000c;1
[2016-09-22 09:44:19] NOTICE[22739][C-00000012]: core_local.c:701 local_call: No such extension/context VSENP0000002f@from-internal while calling Local channel
[2016-09-22 09:44:19] NOTICE[22739][C-00000012]: app_dial.c:1007 do_forward: Forwarding failed to dial 'Local/VSENP0000002f@from-internal'
  == Everyone is busy/congested at this time (1:0/0/1)

What caught my eye is the fifth line down that says it is forwarding 3348 to Local/VSENP. I have no idea what Local/VSENP is. ENP = Enhanced Network Proxy? I’m stumped on this one; we’d like to use the Vega in emergency situations if the network is not available to enable calling to 911, etc.

There is no NAT or firewall involved; all devices are on the same VLAN.

Any help is appreciated. Thanks in advance!

Spence

2

Have you contacted Sangoma Support on this?

3

No I haven’t yet.

4

Can you try this with chan_sip and not pjsip. chan_sip is the stable SIP driver and PJSIP is still very buggy.

5

I’ve tried using chan_sip before but when I do I get the following from Asterisk:

NOTICE[1681]: chan_sip.c:27875 handle_request_register: Registration from '<sip:3348@[FreePBX_IP]:5061>' failed for '[Phone_IP]:5060' - Wrong password

I have confirmed and re-confirmed that the SIP secret is correct. When I switch to PJSIP, it works. I’ve never gotten past issue, so I’ve always just used PJSIP. Amateur mistake?

6

Hello Steve,

Do me a favor:

  1. please capture a sip trace (sip monitor on in the Vega Console) to capture the registration dialog on any extension using the Vega as the outbound proxy.

  2. Execute this command: show sipproxy.itsp_register_path and tell me what the output is

Try to change:

  set sipproxy.itsp_register_path=off
  apply
  save

I’ll wait for your response.

7

That is because chan_sip is on a different port and you are trying to send chan_sip registration to a pjsip port.

8

Hi Spencer,
Im a Sangoma Customer Engineer, I would like to try and help you with this issue.

Both Tony and Ernesto have provided next steps that we should try, but I would like to try and add some more information.

The Gateway function and the resilient proxy function (ENP) operate independently, it is worth noting that ENP does operate as a Forwarding Proxy unless Trunking is involved.

As long as you are making simple extension to extension calling from the Grandstreams through ENP then this call flow should work and I have seen this working with multiple vendors, that said I believe all my personal testing would have been with chan_sip not PJsip.

I dont see any Vega logging and the Vega config extract isnt complete, I cant really make an informed judgement as to whether the Vega is misbehaving without these, that said:

I would like to echo Tony’s request to try chan_sip again. While I dont really read asterisk logging I think some of the lines suggest that the Invite from the Grandstream (after ENPs 302) might not be being processed by pjsip.

  • From Tonys comment the reason for chansip not working might be due to a mismatch of actual sip listen port used by the extension in FreePBX and the port that ENP is actually sending to (eg ext using chan_sip but ENP still sending to the pjsip port)
  • I think you could fix this one of two two ways:
    1> either in the FreePBX Asterisk SIP settings section exchanging ports used by pjsip/chan_sip (they can not be bound to the same port)
    2> or by changing the extension to use chan_sip, and then changing ENP to use the chan_sip listening port
    Vega > Expert Config>ENP setting> SIP ISTP Proxies>Port(in the ITSP table)
    FreePBX> Settings>Asterisk SIP Settings>chan sip settings>Advanced General Settings>Bind Port

If moving to chan_sip and verifying that the correct sip ports are being used still doesnt give us a working system I would like to ask if you can collect a full set of Vega traces and show support (we have a guide for - link below) and an asterisk log output for the test call between the extensions.

http://wiki.sangoma.com/Vega-Troubleshooting-Information

I am happy to keep working through this forum thread but I know you have concerns for security due to sharing passwords over config files etc, in this case I would like to suggest we use a Support Ticket where you can share the logs and configuration files securely, I would create but need an email address to contact you.

Please let us know how you get on

9

I should have mentioned in my original post that everything had been working up until a few weeks ago. I have not changed any settings for a couple months. I did upgrade the Vega’s firmware a few weeks ago when the new firmware was released to fix a known issue with BLF messages passing through the Vega; not sure if the firmware had anything to do with this but it is something that has changed.

I should also clarify that our use case for the Vega is the following: We want all calls to go to the server, even if calling extension to extension and both extensions are registered through the same Vega unit. We just want the device to take over if the network between it and the server should fail.

Chan_sip/PJSIP: I have the phones using the correct port for chan_sip (configured for 5061, as shown in the Asterisk output line above). PJSIP is using 5060. Chan_sip still will not authenticate the password. I have changed the extensions over to chan_sip in FreePBX as well.

NOTICE[1681]: chan_sip.c:27875 handle_request_register: Registration from '<sip:3348@[FreePBX_IP]:5061>' failed for '[Phone_IP]:5060' - Wrong password

SIP Trace: Here is the SIP trace from the Vega. There were a number of lines that went by before I actually made the call; I put a few spaces in between to mark the point where I actually placed the call that I knew would fail.

http://pastebin.com/PZcAd49S

Asterisk debug output: Here is Asterisk’s output during the call from one extension to another which does not go through.

http://pastebin.com/304RJ2Eq

sipproxy.itsp_register_path: The sipproxy.itsp_register_path config value was set to auto. I changed it to off. The problem persists.

Vega configuration: Here is a link to the full Vega configuration.

http://pastebin.com/cALAHqVD

Hopefully that covers all the bases. I’m going to keep trying to get chan_sip to work. PJSIP was working for us before, but perhaps an update changed its behavior.

Thanks all for your help! I’ve been impressed with Sangoma’s response time on this and other issues.

Spence

10

Sorry Spece, I said Steve… :frowning:

11

Haha I noticed that. No problem.

Also I believe I have chan_sip working… had to change the port in the ITSP server setting on the Vega. Duh.

12

After some more testing, it seems that switching to chan_sip has done the trick. Odd since PJSIP was working before. But oh well, at least it works now. Thanks all for your help.

Spence