Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > uk.telecom.voip > #9091 > unrolled thread

About 5% of outgoing calls fail with one-way sound only - fix?

Back to article view | Back to uk.telecom.voip

Contents

  About 5% of outgoing calls fail with one-way sound only - fix? Chris Green <cl@isbd.net> - 2026-01-23 15:35 +0000
    Re: About 5% of outgoing calls fail with one-way sound only - fix? Richmond <dnomhcir@gmx.com> - 2026-01-23 15:51 +0000
      Re: About 5% of outgoing calls fail with one-way sound only - fix? Chris Green <cl@isbd.net> - 2026-01-23 17:51 +0000
        Re: About 5% of outgoing calls fail with one-way sound only - fix? Richmond <dnomhcir@gmx.com> - 2026-01-23 22:44 +0000
          Re: About 5% of outgoing calls fail with one-way sound only - fix? Chris Green <cl@isbd.net> - 2026-01-24 09:35 +0000
            Re: About 5% of outgoing calls fail with one-way sound only - fix? Richmond <dnomhcir@gmx.com> - 2026-01-24 10:44 +0000
              Re: About 5% of outgoing calls fail with one-way sound only - fix? David Higton <dave@davehigton.me.uk> - 2026-01-24 17:27 +0000
                Re: About 5% of outgoing calls fail with one-way sound only - fix? Richmond <dnomhcir@gmx.com> - 2026-01-24 17:31 +0000
              Re: About 5% of outgoing calls fail with one-way sound only - fix? David Woolley <david@ex.djwhome.demon.invalid> - 2026-01-25 12:58 +0000
            Re: About 5% of outgoing calls fail with one-way sound only - fix? Richmond <dnomhcir@gmx.com> - 2026-01-24 15:47 +0000
          Re: About 5% of outgoing calls fail with one-way sound only - fix? David Higton <dave@davehigton.me.uk> - 2026-01-24 17:23 +0000
            Re: About 5% of outgoing calls fail with one-way sound only - fix? Richmond <dnomhcir@gmx.com> - 2026-01-24 17:32 +0000
              Re: About 5% of outgoing calls fail with one-way sound only - fix? David Woolley <david@ex.djwhome.demon.invalid> - 2026-01-25 12:43 +0000
    Re: About 5% of outgoing calls fail with one-way sound only - fix? Andy Burns <usenet@andyburns.uk> - 2026-01-23 16:16 +0000
      Re: About 5% of outgoing calls fail with one-way sound only - fix? Chris Green <cl@isbd.net> - 2026-01-23 17:53 +0000
        Re: About 5% of outgoing calls fail with one-way sound only - fix? David Higton <dave@davehigton.me.uk> - 2026-01-23 22:31 +0000
          Re: About 5% of outgoing calls fail with one-way sound only - fix? Chris Green <cl@isbd.net> - 2026-01-24 09:39 +0000
            Re: About 5% of outgoing calls fail with one-way sound only - fix? David Higton <dave@davehigton.me.uk> - 2026-01-24 17:18 +0000
    Re: About 5% of outgoing calls fail with one-way sound only - fix? "J. P. Gilliver" <G6JPG@255soft.uk> - 2026-01-23 17:02 +0000

#9091 — About 5% of outgoing calls fail with one-way sound only - fix?

Our VOIP is a straightforward (?) Yealink DECT system, a W70B base
station and five W73H handsets.  It works well for most calls but a
small percentage of outgoing calls fail with 'them' being able to hear
'us' but we can't hear them.

These are always (so far) calls to businesses or local government,
however it is just one or two that fail, most calls to banks etc. work
perfectly OK.  It's consistent with any particular destination, if it
doesn't work first time then it's never going to work.

We're with Plexatalk whose 'support' (it's a one man band I think) has
disappeared for the moment.

Is there an 'obvious' fix for this? Is it something awry at Plaxatalk?
Is it worth trying another VOIP provider (I'm tempted, given the lack
of response at Plexatalk)?

-- 
Chris Green
·

[toc] | [next] | [standalone]

#9092

Chris Green <cl@isbd.net> writes:

> Our VOIP is a straightforward (?) Yealink DECT system, a W70B base
> station and five W73H handsets.  It works well for most calls but a
> small percentage of outgoing calls fail with 'them' being able to hear
> 'us' but we can't hear them.
>
> These are always (so far) calls to businesses or local government,
> however it is just one or two that fail, most calls to banks etc. work
> perfectly OK.  It's consistent with any particular destination, if it
> doesn't work first time then it's never going to work.
>
> We're with Plexatalk whose 'support' (it's a one man band I think) has
> disappeared for the moment.
>
> Is there an 'obvious' fix for this? Is it something awry at Plaxatalk?
> Is it worth trying another VOIP provider (I'm tempted, given the lack
> of response at Plexatalk)?

I had a similar problem and I fixed it by switching on SIP ALG, which is
frowned upon. But it could be the same underlying problem of packets not
being routed back to the right address, because there is no stun server
perhaps.

[toc] | [prev] | [next] | [standalone]

#9095

Richmond <dnomhcir@gmx.com> wrote:
> Chris Green <cl@isbd.net> writes:
> 
> > Our VOIP is a straightforward (?) Yealink DECT system, a W70B base
> > station and five W73H handsets.  It works well for most calls but a
> > small percentage of outgoing calls fail with 'them' being able to hear
> > 'us' but we can't hear them.
> >
> > These are always (so far) calls to businesses or local government,
> > however it is just one or two that fail, most calls to banks etc. work
> > perfectly OK.  It's consistent with any particular destination, if it
> > doesn't work first time then it's never going to work.
> >
> > We're with Plexatalk whose 'support' (it's a one man band I think) has
> > disappeared for the moment.
> >
> > Is there an 'obvious' fix for this? Is it something awry at Plaxatalk?
> > Is it worth trying another VOIP provider (I'm tempted, given the lack
> > of response at Plexatalk)?
> 
> I had a similar problem and I fixed it by switching on SIP ALG, which is
> frowned upon. But it could be the same underlying problem of packets not
> being routed back to the right address, because there is no stun server
> perhaps.

It's enabled, maybe I should disable it as recommended by most. It was
enabled by default, I didn't do it.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#9098

Chris Green <cl@isbd.net> writes:

> Richmond <dnomhcir@gmx.com> wrote:
>> Chris Green <cl@isbd.net> writes:
>> 
>> > Our VOIP is a straightforward (?) Yealink DECT system, a W70B base
>> > station and five W73H handsets.  It works well for most calls but a
>> > small percentage of outgoing calls fail with 'them' being able to
>> > hear 'us' but we can't hear them.
>> >
>> > These are always (so far) calls to businesses or local government,
>> > however it is just one or two that fail, most calls to banks
>> > etc. work perfectly OK.  It's consistent with any particular
>> > destination, if it doesn't work first time then it's never going to
>> > work.
>> >
>> > We're with Plexatalk whose 'support' (it's a one man band I think)
>> > has disappeared for the moment.
>> >
>> > Is there an 'obvious' fix for this? Is it something awry at
>> > Plaxatalk?  Is it worth trying another VOIP provider (I'm tempted,
>> > given the lack of response at Plexatalk)?
>> 
>> I had a similar problem and I fixed it by switching on SIP ALG, which
>> is frowned upon. But it could be the same underlying problem of
>> packets not being routed back to the right address, because there is
>> no stun server perhaps.
>
> It's enabled, maybe I should disable it as recommended by most. It was
> enabled by default, I didn't do it.

You could try disabling it as can cause problems depending on the
implementation.

I am using ipv6 but that didn't help me at all because I am still behind
NAT.

SIP was designed at a time when it was expected that every device would
have its own public IP address. But that isn't what happened, what
happened is NAT. So you have to work around NAT with something, or find
a way to give each of your devices a public IP address.

Some places that you phone will have systems which can correct
problems with SIP, but older systems don't.

[toc] | [prev] | [next] | [standalone]

#9100

Richmond <dnomhcir@gmx.com> wrote:
> Chris Green <cl@isbd.net> writes:
> 
> > Richmond <dnomhcir@gmx.com> wrote:
> >> Chris Green <cl@isbd.net> writes:
> >> 
> >> > Our VOIP is a straightforward (?) Yealink DECT system, a W70B base
> >> > station and five W73H handsets.  It works well for most calls but a
> >> > small percentage of outgoing calls fail with 'them' being able to
> >> > hear 'us' but we can't hear them.
> >> >
> >> > These are always (so far) calls to businesses or local government,
> >> > however it is just one or two that fail, most calls to banks
> >> > etc. work perfectly OK.  It's consistent with any particular
> >> > destination, if it doesn't work first time then it's never going to
> >> > work.
> >> >
> >> > We're with Plexatalk whose 'support' (it's a one man band I think)
> >> > has disappeared for the moment.
> >> >
> >> > Is there an 'obvious' fix for this? Is it something awry at
> >> > Plaxatalk?  Is it worth trying another VOIP provider (I'm tempted,
> >> > given the lack of response at Plexatalk)?
> >> 
> >> I had a similar problem and I fixed it by switching on SIP ALG, which
> >> is frowned upon. But it could be the same underlying problem of
> >> packets not being routed back to the right address, because there is
> >> no stun server perhaps.
> >
> > It's enabled, maybe I should disable it as recommended by most. It was
> > enabled by default, I didn't do it.
> 
> You could try disabling it as can cause problems depending on the
> implementation.
> 
> I am using ipv6 but that didn't help me at all because I am still behind
> NAT.
> 
Surely, in the main, if you have IPV6 there's no NAT involved is there?

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#9101

Chris Green <cl@isbd.net> writes:

> Richmond <dnomhcir@gmx.com> wrote:
>> Chris Green <cl@isbd.net> writes:
>> 
>> > Richmond <dnomhcir@gmx.com> wrote:
>> >> Chris Green <cl@isbd.net> writes:
>> >> 
>> >> > Our VOIP is a straightforward (?) Yealink DECT system, a W70B
>> >> > base station and five W73H handsets.  It works well for most
>> >> > calls but a small percentage of outgoing calls fail with 'them'
>> >> > being able to hear 'us' but we can't hear them.
>> >> >
>> >> > These are always (so far) calls to businesses or local
>> >> > government, however it is just one or two that fail, most calls
>> >> > to banks etc. work perfectly OK.  It's consistent with any
>> >> > particular destination, if it doesn't work first time then it's
>> >> > never going to work.
>> >> >
>> >> > We're with Plexatalk whose 'support' (it's a one man band I
>> >> > think) has disappeared for the moment.
>> >> >
>> >> > Is there an 'obvious' fix for this? Is it something awry at
>> >> > Plaxatalk?  Is it worth trying another VOIP provider (I'm
>> >> > tempted, given the lack of response at Plexatalk)?
>> >> 
>> >> I had a similar problem and I fixed it by switching on SIP ALG,
>> >> which is frowned upon. But it could be the same underlying problem
>> >> of packets not being routed back to the right address, because
>> >> there is no stun server perhaps.
>> >
>> > It's enabled, maybe I should disable it as recommended by most. It
>> > was enabled by default, I didn't do it.
>> 
>> You could try disabling it as can cause problems depending on the
>> implementation.
>> 
>> I am using ipv6 but that didn't help me at all because I am still
>> behind NAT.
>> 
> Surely, in the main, if you have IPV6 there's no NAT involved is
> there?

That is the case with my mobile devices I think, as they have unique
public IP addresses and I never had any problem using the Linphone app.

But the other phones I have are analog DECT phones, and they are plugged
into the router, so they don't have their own IP address or MAC address,
they share the router's.

As I understand it, with SIP, the outgoing packets can contain local IP
addresses anyway, so if it is a local ipv6 address beginning with fe80::
that wouldn't be any use either. I never got to the bottom of what was
happening with my system because I could not look at the packets. These
local addresses are in the payload of the packets.

Your Yealink devices might be quite different.

[toc] | [prev] | [next] | [standalone]

#9103

In message <82ms23i937.fsf@example.com>
          Richmond <dnomhcir@gmx.com> wrote:

> As I understand it, with SIP, the outgoing packets can contain local IP
> addresses anyway, so if it is a local ipv6 address beginning with fe80::
> that wouldn't be any use either.

An IPv6 address begining with fe80: is the equivalent of 127.0.0.1, i.e.
localhost.

There would be no point in sending out non-routable IPv6 addresses.

David

[toc] | [prev] | [next] | [standalone]

#9106

David Higton <dave@davehigton.me.uk> writes:

> In message <82ms23i937.fsf@example.com>
>           Richmond <dnomhcir@gmx.com> wrote:
>
>> As I understand it, with SIP, the outgoing packets can contain local IP
>> addresses anyway, so if it is a local ipv6 address beginning with fe80::
>> that wouldn't be any use either.
>
> An IPv6 address begining with fe80: is the equivalent of 127.0.0.1, i.e.
> localhost.
>
> There would be no point in sending out non-routable IPv6 addresses.
>

Exactly, that's the problem with SIP and NAT.

[toc] | [prev] | [next] | [standalone]

#9109

On 24/01/2026 10:44, Richmond wrote:
> As I understand it, with SIP, the outgoing packets can contain local IP
> addresses anyway

They should not contain them anywhere where they are used as addresses, 
although there are some commonly used additions to SIP which allow them 
to be ignored, and the detected public source address to be used 
instead.  This isn't perfect, e.g. for the media address, at least one 
side must supply its true public address, and must send media without 
having received any.

(With the latest round of NAT coping features (ICE), multiple addresses 
can be sent, but any local addresses there are there because the sender 
doesn't know that the other party can't use them.)

[toc] | [prev] | [next] | [standalone]

#9102

Chris Green <cl@isbd.net> writes:

> Richmond <dnomhcir@gmx.com> wrote:
>> Chris Green <cl@isbd.net> writes:
>> 
>> > Richmond <dnomhcir@gmx.com> wrote:
>> >> Chris Green <cl@isbd.net> writes:
>> >> 
>> >> > Our VOIP is a straightforward (?) Yealink DECT system, a W70B
>> >> > base station and five W73H handsets.  It works well for most
>> >> > calls but a small percentage of outgoing calls fail with 'them'
>> >> > being able to hear 'us' but we can't hear them.
>> >> >
>> >> > These are always (so far) calls to businesses or local
>> >> > government, however it is just one or two that fail, most calls
>> >> > to banks etc. work perfectly OK.  It's consistent with any
>> >> > particular destination, if it doesn't work first time then it's
>> >> > never going to work.
>> >> >
>> >> > We're with Plexatalk whose 'support' (it's a one man band I
>> >> > think) has disappeared for the moment.
>> >> >
>> >> > Is there an 'obvious' fix for this? Is it something awry at
>> >> > Plaxatalk?  Is it worth trying another VOIP provider (I'm
>> >> > tempted, given the lack of response at Plexatalk)?
>> >> 
>> >> I had a similar problem and I fixed it by switching on SIP ALG,
>> >> which is frowned upon. But it could be the same underlying problem
>> >> of packets not being routed back to the right address, because
>> >> there is no stun server perhaps.
>> >
>> > It's enabled, maybe I should disable it as recommended by most. It
>> > was enabled by default, I didn't do it.
>> 
>> You could try disabling it as can cause problems depending on the
>> implementation.
>> 
>> I am using ipv6 but that didn't help me at all because I am still
>> behind NAT.
>> 
> Surely, in the main, if you have IPV6 there's no NAT involved is
> there?

I found this video which describes the problems with SIP and NAT, and
also mentions how firewalls can get in the way.

https://youtu.be/Tb_8mZMWQjQ

[toc] | [prev] | [next] | [standalone]

#9104

In message <82cy30gd9r.fsf@example.com>
          Richmond <dnomhcir@gmx.com> wrote:

> I am using ipv6 but that didn't help me at all because I am still behind
> NAT.

NAT is unnecessary with IPv6.  It was only necessary with IPv4 because
the number of network-connected devices exceeded the supply of routable
IPv4 addresses.

NAT with IPv6 would be counter-productive.

> SIP was designed at a time when it was expected that every device would
> have its own public IP address. But that isn't what happened, what happened
> is NAT. So you have to work around NAT with something, or find a way to
> give each of your devices a public IP address.

STUN and later TURN were invented for exactly that.  But IPv6 should
solve all the problems more simply and neatly.

David

[toc] | [prev] | [next] | [standalone]

#9107

David Higton <dave@davehigton.me.uk> writes:

> In message <82cy30gd9r.fsf@example.com>
>           Richmond <dnomhcir@gmx.com> wrote:
>
>> I am using ipv6 but that didn't help me at all because I am still behind
>> NAT.
>
> NAT is unnecessary with IPv6.  It was only necessary with IPv4 because
> the number of network-connected devices exceeded the supply of routable
> IPv4 addresses.
>
> NAT with IPv6 would be counter-productive.
>
>> SIP was designed at a time when it was expected that every device would
>> have its own public IP address. But that isn't what happened, what happened
>> is NAT. So you have to work around NAT with something, or find a way to
>> give each of your devices a public IP address.
>
> STUN and later TURN were invented for exactly that.  But IPv6 should
> solve all the problems more simply and neatly.
>

Yes it should. But it doesn't, probably because of firewalls. And if you
make a hole in the firewall for SIP, then you have a security risk.

[toc] | [prev] | [next] | [standalone]

#9108

On 24/01/2026 17:32, Richmond wrote:
> And if you
> make a hole in the firewall for SIP, then you have a security risk.

You need to have holes in the firewall for SIP to work at all.  Although 
NAT is not the same as firewalls, NAT has a firewall effect, and the two 
are often combined in the implementation.  Most of the problems with SIP 
behind NAT relate to managing those holes, making sure the other party 
knows where they are,  and making sure they don't go away when still needed.

[toc] | [prev] | [next] | [standalone]

#9093

Chris Green wrote:

> Is there an 'obvious' fix for this?

ISTR you asking about STUN settings recently, did you end up with a STUN 
server set?  presumably you're not on CGNAT, just "normal" domestic 
broadband with a single layer of NAT rather than cascaded routers?

[toc] | [prev] | [next] | [standalone]

#9096

Andy Burns <usenet@andyburns.uk> wrote:
> Chris Green wrote:
> 
> > Is there an 'obvious' fix for this?
> 
> ISTR you asking about STUN settings recently, did you end up with a STUN 
> server set?  presumably you're not on CGNAT, just "normal" domestic 
> broadband with a single layer of NAT rather than cascaded routers?
> 
No STUN enabled.  No, not CGNAT, simple NAT and a fixed IPV4 address.

Would enabling IPV6 help, or is that likely to open a new can of worms?

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#9097

In message <v5pc4m-ujoh1.ln1@q957.zbmc.eu>
          Chris Green <cl@isbd.net> wrote:

> Andy Burns <usenet@andyburns.uk> wrote:
> > Chris Green wrote:
> > 
> > > Is there an 'obvious' fix for this?
> > 
> > ISTR you asking about STUN settings recently, did you end up with a STUN 
> > server set?  presumably you're not on CGNAT, just "normal" domestic 
> > broadband with a single layer of NAT rather than cascaded routers?
> > 
> No STUN enabled.  No, not CGNAT, simple NAT and a fixed IPV4 address.
> 
> Would enabling IPV6 help, or is that likely to open a new can of worms?

It may well help.  It should not cause any problems.

NAT is the bane of VoIP.  NAT is simply unnecessary with IPv6, hence
IPv6 may well solve your probelms.  It requires that both ends support
IPv6, of course.

David

[toc] | [prev] | [next] | [standalone]

#9099

David Higton <dave@davehigton.me.uk> wrote:
> In message <v5pc4m-ujoh1.ln1@q957.zbmc.eu>
>           Chris Green <cl@isbd.net> wrote:
> 
> > Andy Burns <usenet@andyburns.uk> wrote:
> > > Chris Green wrote:
> > > 
> > > > Is there an 'obvious' fix for this?
> > > 
> > > ISTR you asking about STUN settings recently, did you end up with a STUN 
> > > server set?  presumably you're not on CGNAT, just "normal" domestic 
> > > broadband with a single layer of NAT rather than cascaded routers?
> > > 
> > No STUN enabled.  No, not CGNAT, simple NAT and a fixed IPV4 address.
> > 
> > Would enabling IPV6 help, or is that likely to open a new can of worms?
> 
> It may well help.  It should not cause any problems.
> 
> NAT is the bane of VoIP.  NAT is simply unnecessary with IPv6, hence
> IPv6 may well solve your probelms.  It requires that both ends support
> IPv6, of course.
> 
Yes, that's sort of what I thought.  Enabling IPV6 is dead easy at my
end (and IPV6 seems fairly easy to implement on the W70B base stattion).

When you say 'both ends' presumably the other end is my VOIP provider
rather than the phone number I'm calling.  If so that may add a new
requirement to my short list of VOIP providers.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#9105

In message <hjge4m-l7uk1.ln1@q957.zbmc.eu>
          Chris Green <cl@isbd.net> wrote:

> David Higton <dave@davehigton.me.uk> wrote:
> > In message <v5pc4m-ujoh1.ln1@q957.zbmc.eu>
> >           Chris Green <cl@isbd.net> wrote:
> > 
> > > Andy Burns <usenet@andyburns.uk> wrote:
> > > > Chris Green wrote:
> > > > 
> > > > > Is there an 'obvious' fix for this?
> > > > 
> > > > ISTR you asking about STUN settings recently, did you end up with a
> > > > STUN  server set?  presumably you're not on CGNAT, just "normal"
> > > > domestic  broadband with a single layer of NAT rather than cascaded
> > > > routers?
> > > > 
> > > No STUN enabled.  No, not CGNAT, simple NAT and a fixed IPV4 address.
> > > 
> > > Would enabling IPV6 help, or is that likely to open a new can of worms?
> > 
> > It may well help.  It should not cause any problems.
> > 
> > NAT is the bane of VoIP.  NAT is simply unnecessary with IPv6, hence IPv6
> > may well solve your probelms.  It requires that both ends support IPv6,
> > of course.
> > 
> Yes, that's sort of what I thought.  Enabling IPV6 is dead easy at my end
> (and IPV6 seems fairly easy to implement on the W70B base stattion).
> 
> When you say 'both ends' presumably the other end is my VOIP provider
> rather than the phone number I'm calling.  If so that may add a new
> requirement to my short list of VOIP providers.

Yes.

David

[toc] | [prev] | [next] | [standalone]

#9094

On 2026/1/23 15:35:19, Chris Green wrote:
> Our VOIP is a straightforward (?) Yealink DECT system, a W70B base
> station and five W73H handsets.  It works well for most calls but a

My VoIP is going to be one 'phone and one ATA. You definitely needed
that "(?)" there! :-)

> small percentage of outgoing calls fail with 'them' being able to hear
> 'us' but we can't hear them.
[]

(Sorry, don't know the answer. Two followups mention STUN, so that
sounds hopeful ...)
> 
> Is there an 'obvious' fix for this? Is it something awry at Plaxatalk?
> Is it worth trying another VOIP provider (I'm tempted, given the lack
> of response at Plexatalk)?
> 
I'd say do so, even if it doesn't solve the initial problem; poor (no)
support isn't something to stay with, unless you have a very good reason
(as I get older, even "a significantly lower price" is becoming
something I won't use as a reason for poor CS).

-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

"... all your hard work in the hands of twelve people too stupid to get
off jury duty." CSI, 200x

[toc] | [prev] | [standalone]

Back to top | Article view | uk.telecom.voip

csiph-web