- Joined
- Aug 15, 2017
- Messages
- 2,855
- Reaction score
- 478
3CX is v16 SP3 using Yealink T46S phones firmware 66.84.0.95 (latest 3CX supported).
Anyone experienced issues with the above, as I cannot get to the bottom of this particular problem so looking for some advise
on something I have noticed when tracing.
3CX system is hosted, with VPN tunnel down to the customer premise. Handsets involved in the issue are all on the same site.
Customer uses the call pickup feature https://www.3cx.com/docs/pbx-dial-codes/#h.m824f8l4wxkq and gets no audio traffic on the picked up call.
When looking at a PCAP of the problem (fragment from the effected endpoint attached) I see all the normal elements of a call pickup in the trace
(using ** as our pickup code) and actually see RTP being sent both ways (192.168.254.1 being the PBX, and 10.20.14.51 being the endpoint initiating the call pickup)
but wanted to query this ICMP destination/port unreachable packet (which I have seen before in other traces but not taken notice since it has not ever been related to an issue).
The RTP in this case is using random ports 7004 on the PBX side and 12230 on the handset, these are both noted in the ICMP packet as source and
destination ports. Seems a bit of a coincidence based on the issue, however unsure so experience and feedback welcome.
Sure it to be a network level problem but what leads me to doubt is that if this were, it would not make sense since the endpoints and system are all connected by rout-able subnets/LAN to LAN IPSec VPN with traffic at layer 3 through the VPN interfaces from these subnets allowed.
Note: Have tried with both "PBX Delivers audio" on and off also.
Anyone experienced issues with the above, as I cannot get to the bottom of this particular problem so looking for some advise
on something I have noticed when tracing.
3CX system is hosted, with VPN tunnel down to the customer premise. Handsets involved in the issue are all on the same site.
Customer uses the call pickup feature https://www.3cx.com/docs/pbx-dial-codes/#h.m824f8l4wxkq and gets no audio traffic on the picked up call.
When looking at a PCAP of the problem (fragment from the effected endpoint attached) I see all the normal elements of a call pickup in the trace
(using ** as our pickup code) and actually see RTP being sent both ways (192.168.254.1 being the PBX, and 10.20.14.51 being the endpoint initiating the call pickup)
but wanted to query this ICMP destination/port unreachable packet (which I have seen before in other traces but not taken notice since it has not ever been related to an issue).
The RTP in this case is using random ports 7004 on the PBX side and 12230 on the handset, these are both noted in the ICMP packet as source and
destination ports. Seems a bit of a coincidence based on the issue, however unsure so experience and feedback welcome.
Sure it to be a network level problem but what leads me to doubt is that if this were, it would not make sense since the endpoints and system are all connected by rout-able subnets/LAN to LAN IPSec VPN with traffic at layer 3 through the VPN interfaces from these subnets allowed.
Note: Have tried with both "PBX Delivers audio" on and off also.