On 2023-04-29 14:44, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 10:13, Per Jessen wrote:
Carlos E. R. wrote:
Oh, we had to solve them, so we did. For private individuals, it is harder.
I was going to ask you to list some of these harder problems, but it's wayyyy off topic and not overly interesting anyway.
Ver brief, then: private individuals are less likely to have fixed IPs, so we need "hacks" like dynamic dns servers out there.
I think our ideas of "harder problems" are worlds apart.
For example, with IPv6 you can send email directly from your machine to somebody else direct, without any intermediate mail server collecting it.
Um, same with IPv4.
If you have routable addresses.
No, that is not necessary.
Technically, I can send a mail from my MUA here on 192.168.77.88 behind NAT directly to any mailserver on public IPv4. Of course, any semi-qualified mail admin will block that due to reverse lookup failure, but that applies to IPv6 too.
Technically, yes, but that is not what I'm suggesting.
Well, maybe you would care to explain exactly what you _are_ suggesting. It is difficult having a sane conversation when half the information is omitted.
I did, in the next paragraph.
I'm suggesting sending to your friend "whatever" who is also behind NAT, without using a mail server outside.
Rapidly moving goalposts ...
No, I haven't. I have been saying this from minute 1, but you did not understand, so I had to change my wordings, which instead you interpret as moving the goalposts.
Why don't you open port 25 on your router and forward it a postfix instance. If it is suitably configured, I'll be happy to send you an email - directly - from this workstation (on 192.168.2.114). I'll even use telnet.
Because with IPv6 the forwarding part is not needed. That's the whole point. Of course I know you and can do it with IPv4. With one dedicated machine doing it in the LAN. With IPv6 all machines in the LAN could do it. No port forwarding needed, just allowing it in the firewall. Direct connections from any machine inside a LAN to any other machine inside another LAN, is the whole point of IPv6 and getting rid of NAT. That's the original idea of Internet. Of course proper firewalls and security methods are required.
You don't even need a directory, just type the IP address (I have not tried, it is theory). But I did do VoIP inside the LAN in that manner with IPv4.
Carlos, the same applies to public IPv4/5/6. Like above, I can initiate SIP from my telephone here on 192.168.77.89 behind NAT directly to any VoIP device (on port 5060) on public IPv4.
Yes, but you are using a stun server out there, and a directory out there.
I am not using either. I don't understand why you think so.
It is perfectly feasible using e.g. "Ekiga" to contact, i.e. start a SIP session to a VoIP device (on port 5060) on public IPv4 or IPv6. I don't understand why you are so intent on turning SIP into black magic, with STUN servers and directories and whathaveyou.
You said: public IPv4. We people don't have public IPv4.
Or having to define virtual servers in the routers involved.
Huh? You have totally lost me. Virtual servers?
It is how routers call "port forwarding". It is on my router manual.
I'm saying establishing a voip call without registering anywhere (non configured VoIP client software), just by telling the software the address of the other party, perhaps their user name inside that destination host machine.
I'm sorry, exactly _what_ are you saying?
Let me explain what _I_ am saying -
Using e.g. "ekiga" I can dial a public ip address and establish a phone
public address. Not a NATted address.
call, provided the other side has a client looking out for incoming SIP requests on port 5060. It does not have to be a fully-fledged PABX or Asterisk, a simple VoIP client will suffice.
Alternatively, as I don't like dialling IP-addresses, I'll set up a SIP config in my Asterix, assign the IP-address and allocated a local number. Now I can dial '666', but in the end it is still just a SIP-session to some IP-address.
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)