• Welcome to SAIL Community Supported PBX . Please login or sign up.
 
May 18, 2024, 11:36:21 PM

News:

SMF updated to 2.0


Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jsnider

1
Debian / SAIL ASHA new versions
October 23, 2019, 02:08:35 AM
We have a customer who has been running a v4 HA build for ~5 years and is looking for a refresh.

Is there anything comparable available in the v5 or v6 versions on modern Debian?

I seem to remember dependencies for ASHA were not available in Jessie last time I tried, something to do with changing to systemd.

Plan B is to build Wheezy v4 on newer hardware.

Thanks,
Jordan
2
The SIP client device is either a Soft phone or IP PBX connected to the SARK box.

The two main scenarios were are dealing with are as follows:

Scenario 1:
A client with multiple DID numbers and 1 SAIL SIP extension registered as a trunk on their soft phone or PBX, they wish to present a different DID as their Outbound Caller ID on a call by call basis, the soft phone or PBX does present the from Caller ID in the outgoing call but this is then overridden by the settings on the SAIL extension.

Something like this: http://blog.davidvassallo.me/2013/07/23/asterisk-voip-getting-your-outbound-callerid-to-show-properly/

Scenario 2:
Again a client with 1 SAIL extension registered on a soft phone or PBX with an incoming call hair-pinned back out. The PBX collects the incoming caller ID and hairpins the call back out as a new call, presenting the originating Caller ID in the from SIP field, again this is overridden by the Caller ID settings on the SAIL extension.


In both cases if the customers main Caller ID is set on their SAIL extension this is presented regardless of the SIP from field in the SIP trace. If no caller ID is set the call is presented as Anonymous regardless of the SIP from field in the SIP trace.

Thanks,
Jordan
3
In this particular instance the inbound call is diverted back out to a mobile number, the diversion is occurring on the SIP client device which is "hair-pining" the call back out as a new call, we want the new call to take on the same caller ID as the original call.

Another example would be dynamically defining the CallerID for a 100 number group from a soft phone.

In either case the system ignores the CallerID defined by the SIP client and presents the CallerID defined on the extension within Sail or no caller ID if this field is left blank.

Thanks,
Jordan.
4
Are there any settings required to allow a SIP client to define the outbound CallerID?

I can see from the SIP debug that the sip client is sending a from CallerID as defined but this is ignored by the extension, either using the CallerID set under the extension settings in Sail or as anonymous if this is left blank.

System is Sail 4.1 asterisk 11.

Thanks,
Jordan.
5
I have managed to solve the problem by applying the Alert-Info string to the Call Groups, this works reliably on both 4.x and 5.x.

This Alert Info string works for Yealink and Grandstream handsets:

Alert-Info:<http://192.168.100.101/public/external.wav>;info=external;x-line-id=0

The address http://192.168.100.101/public/external.wav does not need to be a real address but it does need to be defined.

Jordan.
6
We are having trouble getting Alert Info to present so that we can identify internal vs external calls by ring tone.

Our deployments are predominantly Yealink handsets, I was able to get Alert Info working once on 4.x when added to the inbound routes section but the combination of quotes, brackets and slashes got messed up by the webui and cleared on the next change to that route as the text field was considered empty and half of the Alert Info string was presented on the page after the text field.

Any other efforts to add Alert Info to ring groups or trunks on either 4.x or 5 does not appear to be effective, the string does not seem to appear at all when wiresharking the traffic.

Any help would be greatly appreciated.