On 16/07/2023 11:19, The Natural Philosopher wrote:
> You probably could. SIP works *behind* router NAT.

SIP wasn't designed to work behind NAT. There are various kludges in
SIP implementations to cope with it, and at least one in SIP itself.
Not setting up those kludges properly is the biggest reason for getting
one way, or no way audio, and calls that drop after 32 seconds.

The kludge in SIP itself is rport, which tells the other end to ignore
what it is being told about the initial signalling address, and just
reply to wherever the request appears to have come from.

The cleanest operation tends to happen when the user agents are either
told, or work out, what their public address is and send that in the
protocol.

Other old kludges, are pretending rport was used even when it was not,
ignoring contact headers and using the de facto signalling address, and
assuming media goes to where it comes from, rather than where the
signalling says it goes (only one side can use this tactic).

For WebRTC, there is ICE, which seems to be that the user agent makes
guesses as to the possible correct address for media, and the other side
tries them in turn, stopping if it finds one that works. That can
sometimes result in very slow starts.

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 16/07/2023 11:19, The Natural Philosopher wrote:
>> You probably could. SIP works *behind* router NAT.
>
> SIP wasn't designed to work behind NAT. There are various kludges in
> SIP implementations to cope with it, and at least one in SIP itself.
> Not setting up those kludges properly is the biggest reason for getting
> one way, or no way audio, and calls that drop after 32 seconds.
>
> The kludge in SIP itself is rport, which tells the other end to ignore
> what it is being told about the initial signalling address, and just
> reply to wherever the request appears to have come from.
>
> The cleanest operation tends to happen when the user agents are either
> told, or work out, what their public address is and send that in the
> protocol.
>
> Other old kludges, are pretending rport was used even when it was not,
> ignoring contact headers and using the de facto signalling address, and
> assuming media goes to where it comes from, rather than where the
> signalling says it goes (only one side can use this tactic).
>
> For WebRTC, there is ICE, which seems to be that the user agent makes
> guesses as to the possible correct address for media, and the other side
> tries them in turn, stopping if it finds one that works. That can
> sometimes result in very slow starts.
>

I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
bothered by NAT.

On 28/07/2023 16:53, Tweed wrote:
> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
> bothered by NAT.

They are newer, and at least WhatsApp's protocol in not published.
However one of the ways they are made to work is by going through a
public server, which is, itself, not-natted.

I suspect, also, that ICE came from the tactics they used.

They were designed, from the start, to work with over a consumer
oriented web browsing service, whereas SIP was designed to work on the
internet.

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> On 28/07/2023 16:53, Tweed wrote:
>> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
>> bothered by NAT.
>
> They are newer, and at least WhatsApp's protocol in not published.
> However one of the ways they are made to work is by going through a
> public server, which is, itself, not-natted.
>
> I suspect, also, that ICE came from the tactics they used.
>
> They were designed, from the start, to work with over a consumer
> oriented web browsing service, whereas SIP was designed to work on the
> internet.
>

ICE?

On 28/07/2023 16:53, Tweed wrote:
> David Woolley <david@ex.djwhome.demon.invalid> wrote:
>> On 16/07/2023 11:19, The Natural Philosopher wrote:
>>> You probably could. SIP works *behind* router NAT.
>>
>> SIP wasn't designed to work behind NAT. There are various kludges in
>> SIP implementations to cope with it, and at least one in SIP itself.
>> Not setting up those kludges properly is the biggest reason for getting
>> one way, or no way audio, and calls that drop after 32 seconds.
>>
>> The kludge in SIP itself is rport, which tells the other end to ignore
>> what it is being told about the initial signalling address, and just
>> reply to wherever the request appears to have come from.
>>
>> The cleanest operation tends to happen when the user agents are either
>> told, or work out, what their public address is and send that in the
>> protocol.
>>
>> Other old kludges, are pretending rport was used even when it was not,
>> ignoring contact headers and using the de facto signalling address, and
>> assuming media goes to where it comes from, rather than where the
>> signalling says it goes (only one side can use this tactic).
>>
>> For WebRTC, there is ICE, which seems to be that the user agent makes
>> guesses as to the possible correct address for media, and the other side
>> tries them in turn, stopping if it finds one that works. That can
>> sometimes result in very slow starts.
>>
>
> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely seem
> bothered by NAT.
>
They are not peer to peer. A server of a known address is involved that
relays the calls.

The problem with NAT is that it allows outbound connections but makes
very little provision for inbound ones.

SIP worked flawlessly on my VOIP equipped router though, and works on
the new one too. They *are* the NAT, not behind it!

I suspect that is the way it will go, Phone ports in the router for
third party VOIP/SIP or in the fibre modem thingie for locked into
BT/ISP shit
There are boxes that will work inside NAT, and there are ways to accept
incoming connections behind NAT. PnP is one ghastly one.

As with things like ftp transfers in the early days, the router needs to
understand the protocol and accept incoming SYN packets and allow a
remote peer to set up a connection.

Or we all go IPV6 for voip and forget NAT

--
How fortunate for governments that the people they administer don't think.

Adolf Hitler

Tweed wrote:

> David Woolley wrote:
>
>> I suspect, also, that ICE came from the tactics they used.
>
> ICE?

<https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment>

I've never used it, but some SBCs I've installed offer it, either not
using NAT or using STUN has always worked for me.

In uk.telecom Andy Burns <usenet@andyburns.uk> wrote:
> Tweed wrote:
>
> > David Woolley wrote:
> >
> >> I suspect, also, that ICE came from the tactics they used.
> >
> > ICE?
>
> <https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment>
>
> I've never used it, but some SBCs I've installed offer it, either not
> using NAT or using STUN has always worked for me.

I found this useful in understanding:
https://wayback.archive-it.org/20635/20230207091459/https://www.ietfjournal.org/interactive-connectivity-establishment/

Briefly, STUN asks a server on the internet to tell you what IP your packets
came from (roughly like https://whatismyipaddress.com/ but for machines).
Then you can embed that in your packets.

TURN acts as a proxy for your packets, so you send all your audio to the
TURN server and that forwards it. That's expensive.

ICE tries both STUN and TURN at the same time at each end and the sides
then negotiate over which method is best.

This does sound a little like the protocol Skype used in its original P2P
implementation, except that clients were also servers. A client would try
to decide if it was on the public internet and if so announce itself as a
'supernode', and non-internet clients would funnel their traffic through the
nearest supernode. This was a big headache for network managers who
suddenly found somebody running Skype on one of their machines would
suddenly generate a massive spike in traffic.

Theo

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 28/07/2023 16:53, Tweed wrote:
>> David Woolley <david@ex.djwhome.demon.invalid> wrote:
>>> On 16/07/2023 11:19, The Natural Philosopher wrote:
>>>> You probably could. SIP works *behind* router NAT.
>>>
>>> SIP wasn't designed to work behind NAT. There are various kludges in
>>> SIP implementations to cope with it, and at least one in SIP itself.
>>> Not setting up those kludges properly is the biggest reason for getting
>>> one way, or no way audio, and calls that drop after 32 seconds.
>>>
>>> The kludge in SIP itself is rport, which tells the other end to ignore
>>> what it is being told about the initial signalling address, and just
>>> reply to wherever the request appears to have come from.
>>>
>>> The cleanest operation tends to happen when the user agents are either
>>> told, or work out, what their public address is and send that in the
>>> protocol.
>>>
>>> Other old kludges, are pretending rport was used even when it was not,
>>> ignoring contact headers and using the de facto signalling address, and
>>> assuming media goes to where it comes from, rather than where the
>>> signalling says it goes (only one side can use this tactic).
>>>
>>> For WebRTC, there is ICE, which seems to be that the user agent makes
>>> guesses as to the possible correct address for media, and the other side
>>> tries them in turn, stopping if it finds one that works. That can
>>> sometimes result in very slow starts.
>>>
>> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely
>> seem
>> bothered by NAT.
>>
> They are not peer to peer. A server of a known address is involved
> that relays the calls.
>
> The problem with NAT is that it allows outbound connections but makes
> very little provision for inbound ones.
>
> SIP worked flawlessly on my VOIP equipped router though, and works on
> the new one too. They *are* the NAT, not behind it!
>
> I suspect that is the way it will go, Phone ports in the router for
> third party VOIP/SIP or in the fibre modem thingie for locked into
> BT/ISP shit
> There are boxes that will work inside NAT, and there are ways to
> accept incoming connections behind NAT. PnP is one ghastly one.
>
> As with things like ftp transfers in the early days, the router needs
> to understand the protocol and accept incoming SYN packets and allow a
> remote peer to set up a connection.
>
> Or we all go IPV6 for voip and forget NAT

I think without NAT one would need a firewall. So using a software phone
or a mobile app there probably is a firewall which might prevent
incoming connections.

On 01/08/2023 12:25, Richmond wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> On 28/07/2023 16:53, Tweed wrote:
>>> David Woolley <david@ex.djwhome.demon.invalid> wrote:
>>>> On 16/07/2023 11:19, The Natural Philosopher wrote:
>>>>> You probably could. SIP works *behind* router NAT.
>>>>
>>>> SIP wasn't designed to work behind NAT. There are various kludges in
>>>> SIP implementations to cope with it, and at least one in SIP itself.
>>>> Not setting up those kludges properly is the biggest reason for getting
>>>> one way, or no way audio, and calls that drop after 32 seconds.
>>>>
>>>> The kludge in SIP itself is rport, which tells the other end to ignore
>>>> what it is being told about the initial signalling address, and just
>>>> reply to wherever the request appears to have come from.
>>>>
>>>> The cleanest operation tends to happen when the user agents are either
>>>> told, or work out, what their public address is and send that in the
>>>> protocol.
>>>>
>>>> Other old kludges, are pretending rport was used even when it was not,
>>>> ignoring contact headers and using the de facto signalling address, and
>>>> assuming media goes to where it comes from, rather than where the
>>>> signalling says it goes (only one side can use this tactic).
>>>>
>>>> For WebRTC, there is ICE, which seems to be that the user agent makes
>>>> guesses as to the possible correct address for media, and the other side
>>>> tries them in turn, stopping if it finds one that works. That can
>>>> sometimes result in very slow starts.
>>>>
>>> I wonder how the likes of WhatsApp/Teams/FaceTime work? They rarely
>>> seem
>>> bothered by NAT.
>>>
>> They are not peer to peer. A server of a known address is involved
>> that relays the calls.
>>
>> The problem with NAT is that it allows outbound connections but makes
>> very little provision for inbound ones.
>>
>> SIP worked flawlessly on my VOIP equipped router though, and works on
>> the new one too. They *are* the NAT, not behind it!
>>
>> I suspect that is the way it will go, Phone ports in the router for
>> third party VOIP/SIP or in the fibre modem thingie for locked into
>> BT/ISP shit
>> There are boxes that will work inside NAT, and there are ways to
>> accept incoming connections behind NAT. PnP is one ghastly one.
>>
>> As with things like ftp transfers in the early days, the router needs
>> to understand the protocol and accept incoming SYN packets and allow a
>> remote peer to set up a connection.
>>
>> Or we all go IPV6 for voip and forget NAT
>
> I think without NAT one would need a firewall. So using a software phone
> or a mobile app there probably is a firewall which might prevent
> incoming connections.

I find I do not need incoming connections to receive calls via my VoIP
service. I just set my end to keep a SIP connection to my VoIP service
open all the time.

--
Brian Gregory (in England).

On 01/08/2023 18:10, Brian Gregory wrote:
> I find I do not need incoming connections to receive calls via my VoIP
> service. I just set my end to keep a SIP connection to my VoIP service
> open all the time.
I dont think you exactly understand how TCP/IP works...

SIP does not proxy.

--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

On 02/08/2023 17:51, The Natural Philosopher wrote:
> On 01/08/2023 18:10, Brian Gregory wrote:
>> I find I do not need incoming connections to receive calls via my VoIP
>> service. I just set my end to keep a SIP connection to my VoIP service
>> open all the time.
> I dont think you exactly understand how TCP/IP works...

I don't think you understand how modern VoIP works.

Do you seriously think that I have to open a port to the world for any
and all spammers to just connect to my phone and spam me for free?

> SIP does not proxy.
Irrelevant and wrong. Nothing "doesn't proxy" if you build the right proxy.

I receive incoming calls though NAT (or through an IPv6 firewall)
without problems.

--
Brian Gregory (in England).

On 03/08/2023 00:10, Brian Gregory wrote:
> On 02/08/2023 17:51, The Natural Philosopher wrote:
>> On 01/08/2023 18:10, Brian Gregory wrote:
>>> I find I do not need incoming connections to receive calls via my
>>> VoIP service. I just set my end to keep a SIP connection to my VoIP
>>> service open all the time.
>> I dont think you exactly understand how TCP/IP works...
>
> I don't think you understand how modern VoIP works.
>
> Do you seriously think that I have to open a port to the world for any
> and all spammers to just connect to my phone and spam me for free?
>
You already have exactly that on a land line or mobile phone

>> SIP does not proxy.
> Irrelevant and wrong. Nothing "doesn't proxy" if you build the right proxy.
>
Starw man. its not a matter of what you could do, its a matter of how it
currently works

> I receive incoming calls though NAT (or through an IPv6 firewall)
> without problems.
>
Precisely, but you have no idea how that happens, do you?

--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra

On 02/08/2023 17:51, The Natural Philosopher wrote:
> On 01/08/2023 18:10, Brian Gregory wrote:
>> I find I do not need incoming connections to receive calls via my VoIP
>> service. I just set my end to keep a SIP connection to my VoIP service
>> open all the time.
> I dont think you exactly understand how TCP/IP works...
>
> SIP does not proxy.
>

Did you mean to say it was connectionless? Large parts of RFC 3261 are
about using proxies with SIP, and bigger users use Session Border
Controllers, which are, I believe, proxy servers.

SIPS can use TCP and TLS, which are connection oriented.

My guess is that Brian really meant that he keeps the dynamic NAT rules
in router open.