Microsoft Teams Integration
Hikvision Intercom Integration
ISDN Switch-off Migration
All materials to evaluate Yeastar as a PBX vendor on products, solutions, partner program, support, learning resources, etc.
After the upgrade to version 30.5.0.8 Call Parking with *6 is not working.
When we have a call and press *6, nothing happens.
Is there someone who have this working?
Date
Votes
14 comments
-
Oscar Colka Carlo,
The issue sounds like the DTMF detection issue. Check if transfer feature code *3 work or not.
Did you change anything related to DTMF after firmware updating?
Did all the phones(IP phone and analog phone) have the same problem?
-
Carlo van Dongen Hi Oscar,
*3 is working without any problem.
There is nothing changed after the update, and we only work with Tiptel 32XX SIP phones.
-
Oscar Colka Carlo,
I try with Yealink IP phone and didn't have the same issue, I would suggest you to try with another brand of IP phone or soft phone and check if you would have the same issue.
-
Carlo van Dongen Hi Oscar,
I tryed with an Gigaset and a X-Lite softphone, same results.
Other functions work fine.
-
Oscar Colka Carlo,
Follow below steps to troubleshoot this issue:
1. Check if the DTMF settings on the IP phone and the extension setting on PBX are the same;
2. Check if the feature code is *6 or not by checking the web GUI feature code;
If above settings were correctly configured, try capture a pacp logs follow below instruction:
1. Login web GUI of your S PBX, Go to Maintenance -> Troubleshooting -> Ethernet capture tool;
2. Click start button and make the call, press *6 on the IP phone that you have the call parking issue; Press *6 again if nothing happen;
3. Click stop button and download the logs;
4. Upload the logs here (You may need to upload somewhere for your logs and provide a download for that logs here).
I can help to check the logs if you can get the logs.
-
Carlo van Dongen Hi Oscar,
The phone's and PBS looking fine to me, but still don't got it working.
For the Pcap
-
Larry Neblett The first thing to do is to make an extension to extension call and see if the dial code then functions. If so, then the code itself works.
The pcap is showing several things, the first of which is the SIP messaging appears incorrect. The contact header and the SDP IP you are using to tell the provider how to reach the PBX is using the local IP and not the Public. Presumably, the provider is seeing the public on the registration and using that instead. As a result, I assume that the PBX is not handling certain aspects correctly as:
In the first park attempt, the dial string used was *6#, the # was passed to the provider, the PBX had no response to the other. The second attempt used *6 only, yet the *6 was passed to the provider which because of passing on, the PBX would not be expected to respond . Both attempts came across as RFC DTMF events so this aspect is correct.
I assume that because the NAT is not corfrect in the messaging, the PBX is not able to discern that which it is expected to react to versus what it should be passing on.
-
Larry Neblett The first thing to do is to make an extension to extension call and see if the dial code then functions. If so, then the code itself works.
The pcap is showing several things, the first of which is the SIP messaging appears incorrect. The contact header and the SDP IP you are using to tell the provider how to reach the PBX is using the local IP and not the Public. Presumably, the provider is seeing the public on the registration and using that instead. As a result, I assume that the PBX is not handling certain aspects correctly as:
In the first park attempt, the dial string used was *6#, the # was passed to the provider, the PBX had no response to the other. The second attempt used *6 only, yet the *6 was passed to the provider which because of passing on, the PBX would not be expected to respond . Both attempts came across as RFC DTMF events so this aspect is correct.
I assume that because the NAT is not corfrect in the messaging, the PBX is not able to discern that which it is expected to react to versus what it should be passing on.
I tested my setup using a GS GXV3275 and it works fine on the S-series 30.5.0.8 firmware.
-
Oscar Colka Yes, from the logs, I noticed the same that Larry mentioned: The DTMF was passed to the provider. If the call parking feature code would work, the DTMF should not be passed to the provider.
The PBX seems doesn't think *6 is feature code of call parking. This sounds like there is something wrong with the feature code settings.@Carlo, I would suggest you to:
1. Check if there is any other feature code start with *6, if yes, try change to another feature code and see if that helps;
2. Switch call transfer(default feature code *3, change to *6) and call parking(default *6, change to *3) feature code settings and see if call park would works; -
Carlo van Dongen Hi Larry,
The IP of the PBX is in a VPN, that is also used at the provider.
We don't use any NAT, everything is on routed base.
I will test the suggestion off Oscar, to change *3 and *6.
I will let you know.
Thanx for the help.
Regards Carlo
-
Carlo van Dongen *6 is not used for something else and I test to change *6 and *3.
*6 give's the transfer now and *3 is not responding.
So I changed it back, before a lot of people start to complain to me ;)
-
Oscar Colka Carlo, I am sorry, but I couldn't find out what would be the reason with the current information and logs. I would suggest you to submit a ticket and ask help from Yeastar support team. Remember to copy this discuss topic to the ticket. I think it would be better to schedule a remote assist from them. Yeastar support team might require to access to your device, please get that ready.
-
Carlo van Dongen Thanx for the help to all, I'm now in contact with the support team.
-
Jonathan Did this ever get fixed?
Please sign in to leave a comment.