Zulu no audio when dialing through DAHDI

I have a strange problem with Zulu. If I make a call to any “internal” extension (or feature code) everything works fine, but if I try to dial an external number through PSTN (using E1) I do not get any audio on the call. I can see the call start on the Asterisk CLI but I cannot hear the prompt for the pin.

Is there a setting I need to set so DAHDI can talk to Zulu?

Your reference to a PIN makes me think that the outbound route is configured with a PIN to allow access. If so, you will need Zulu client 3.2.3 for early media to work. 3.2.3 is released as Alpha now.

That is very problematic. All external calls require a PIN. How can I download the alpha version? Or si there a workaround?

You can switch to the Alpha track in the Preferences menu in Zulu client.

I’m guessing that only works on the desktop client?

I disabled PIN on a single extension and I can now make external calls but this is simply not possible to do for all extensions. Zulu was a big selling point for getting PBXact and this will prevent deployment until the Alpha version goes stable.

Go to the Alpha version now, it will be Beta in a couple weeks and in production shortly after that. Versions on Zulu seem to be rolling through ridiculously fast.

Just for laughs, I copied the [macro-pinsets] context from extensions_additional.conf, edited it replacing Progress with Answer() and put the modified version in extensions_override_freepbx.conf.

It works, but there are a few unwanted side effects:

  1. On answered calls, the CDR shows duration starting from the PIN prompt.
  2. Calls abandoned before completely entering the PIN show as answered with app Read.
  3. The calling device shows all calls as answered.

(1) could be fixed by resetting the CDR after accepting the PIN.
Possibly this workaround or something similar would be useful.

How is the PIN used? Unless it’s identifying the client on whose behalf the call is made, e.g. in a law firm, there may be an automated way to get the information, improving productivity in addition to solving the present technical issue. For example, some companies use a PIN to allocate phone charges to a specific department. But if the call costs less than 1% of the cost of the person making it, this is counterproductive.

We can use the Alpha on the desktop client but not on the mobile. This means that IOS and Android users cannot make external calls until this is fixed. I hope the Alpha goes well and gets into production soon.

Can you temporarily set those extensions to not require a PIN? To use a different SIP app? To call via DISA? To call using Callback? To call the receptionist and ask that the call be transferred? How many of these extensions are involved?

FYI the codebase for mobile and desktop are completely different. There is no Alpha to fix early media for mobile at this time.

Stewart’s workaround here is probably the best way forward for the foreseeable future. The only real downside is that call times (and billing seconds) will be off, which are worthless anyway if you’re using analog DAHDI channels.

Maybe I can modify macro-pinsets with an ExecIF to exchange Progress to Answer only if the call cames from a Zulu client? How can I determine if Zulu is making the call from the dialplan? That way only Zulu calls get a messy CDR and the rest are unaffected. At first glance I do not see anything to tell the difference between a regular IP phone and Zulu. Any ideas?

We are using a couple E1 for PSTN connectivity.

Check out the section titled " How do I apply custom dialplan selectively on some outbound calls?" in this post: Hooking for fun and income

You don’t want to use dialplan hooks for this, but the technique described there shows how to selectively apply dialplan based on the originating extension. We can easily work this up in support if you need assistance.

The only problem I am trying to solve now is how to identify when a caller is using Zulu or their regular phone. We have over 200 extensions and I do not know who will be using Zulu at any given time. So far the only unique thing I can find to use is the IP address of the calling phone. If it is then it has to be Zulu since regular desktop phones use their own IP address. If I look at the CHANNEL(pjsip,local_addr) function I should be able to test with ExecIF in the dialplan. Thank you for all the help.

OR you could set up a different local context for your Zulu phones (instead of from-internal, for example, call it ‘from-zulu’ and set some kind of “Warrior Flag” in the context.

The problem with Zulu is that they are not separate from the regular extension for the user so there is no way to have them on another context separate from the desk phones. Unless I missed some obscure configuration setting. That is why I need to extract the information directly from the channel function.

It actually is separate technically. So if your extension is 1000. Then zulu is always 901000. Using the is also a good trick but if you are going that far you could also parse out the user agent which has zulu set for both desktop and mobile.

1 Like

What I meant to say was that there is no separate entry to configure the Zulu extension. It is automatically created with the regular extension and you just enable Zulu for that. It may be a separate extension internally for Freepbx but the individual configuration for the endpoint is not exposed to the GUI.

I will try the PJSIP_CONTACT function to get the User Agent. Thanks.

Just in case anyone is interested this is what I ended up doing to get around the Early Media problem. I used the solution proposed by Stewart1 and changed the Progress line to:

exten => cdr,n(auth),Set(IP=${CUT(CHANNEL(pjsip,local_addr),:,1)})
exten => cdr,n,ExecIF($["${IP}" = “”]?Answer():Progress)

That way any WebRTC Zulu phone that makes a call uses Answer and all other IP phones use Progress. Not the most elegant solution but it works. Now I just have to keep an eye on the original macro-pinsets to make sure any updates are reflected in the override file. I hope they fix this in the Zulu mobile and desktop code sooner rather than later.

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