[cancellato]
Ma passando a questioni frivole...non sarebbe ora di aggiornare quell'istanza di PVE?
Ma passando a questioni frivole...non sarebbe ora di aggiornare quell'istanza di PVE?
hitech95 Non riesco neanche a focalizzare il perchè piantava tutto.
Perché le query DNS sono pacchetti UDP, e la regola di NAT da ANY
a WAN IP
traslava le sorgenti dagli IPv6 global unicast a indirizzi link local fe80::/10
che aveva l'interfaccia e che quindi non sono ruotabili all'interno della rete del provider.
hitech95 Non capisco la cosa del HOST che secondo me non ha senso in quanto sono linee consumer.
Nel senso che non ti trova un record DNS inverso dall'IP? Pace e bene, non è rilevante a quanto so... E sicuramente i provider non si mettono a sbattersi e delegare la zona inversa al DNS del cliente (te lo vedi la casalinga a mettersi su una roba del genere? ).
hitech95 Ora voglio invece capire come dare un senso agli indirizzi che mi danno. Perchè mi farebbe davvero piacere averli più ordinati e non a casaccio. una cosa del tipo XXXX::YYYY:ZZZZ
Dove YYYY è la subnet e ZZZZ è l'identificativo della macchina!
Hai 64k subnet... penso tu ti possa divertire un bel po'
Il 4° gruppo di cifre è tutto tuo, puoi scegliere come assegnare le subnet. La parte client (gli ultimi 64bit), non sperarci di avere qualcosa di neanche vagamente sensato, se li creano "a caso" via SLAAC, alla peggio puoi dire di assegnare il clientid ::1
al router, ma giusto perché hai sbatti.
[cancellato] Nì, ad esistere esistono (fc00::/7)
Infatti non volevo complicare la spiegazione Gli ULA non devono essere utilizzati come le classi private IPv4. Hanno usi molto più specifici, e quando si inizia con IPv6 meglio lasciarli da parte.
[cancellato]
Fatto
[cancellato] Perché le query DNS sono pacchetti UDP, e la regola di NAT da ANY a WAN IP traslava le sorgenti dagli IPv6 global unicast a indirizzi link local fe80::/10 che aveva l'interfaccia e che quindi non sono ruotabili all'interno della rete del provider.
Vero vero! In IPV6 questo non deve farlo. Solo con IPv4.
[cancellato] Hai 64k subnet... penso tu ti possa divertire un bel po'
![]()
Il 4° gruppo di cifre è tutto tuo, puoi scegliere come assegnare le subnet. La parte client (gli ultimi 64bit), non sperarci di avere qualcosa di neanche vagamente sensato, se li creano "a caso" via SLAAC, alla peggio puoi dire di assegnare il clientid ::1 al router, ma giusto perché hai sbatti.
Eh diciamo che vorrei ottenere una cosa del genere:
XXXX:XXXX:XXXX:SSSS::IIII:MMMM:AAAA
XXXX:XXXX:XXXX:: è il prefix assegnatomi dal operatore.
SSSS vorrei fosse la mia subnet, questo per dividere la roba accessibile da fuori e i miei PC.
IIII: è l'identificativo della macchina fisica/interfaccia
MMMM: Identificativo della VM/Container quindi del "server" vero e proprio.
AAAA: sono gli alias di quel server.
Un pò come spiegato qui:
https://docs.netgate.com/pfsense/en/latest/network/ipv6/addresses.html#determining-an-ipv6-addressing-scheme.
hitech95 Eh diciamo che vorrei ottenere una cosa del genere:
XXXX:XXXX:XXXX:SSSS::IIII:MMMM:AAAA
XXXX:XXXX:XXXX:: è il prefix assegnatomi dal operatore.
SSSS vorrei fosse la mia subnet, questo per dividere la roba accessibile da fuori e i miei PC.
IIII: è l'identificativo della macchina fisica/interfaccia
MMMM: Identificativo della VM/Container quindi del "server" vero e proprio.
AAAA: sono gli alias di quel server.
Puoi sicuramente dividere le subnet e renderne qualcuna accessibile da fuori e qualcuna no, crei delle nuove interfacce LAN sul pfsense collegate a dei bridge diversi di proxmox e metti il prefixid diverso, poi devi sistemare il firewall.
Per il resto devi mettere IP statici oppure DHCPv6 (che però su android non funziona)
edofullo Per il resto devi mettere IP statici oppure DHCPv6 (che però su android non funziona)
Si si ma quel discorso lo farei solo per la rete dei server.
Per gli altri PC al massimo gli metto io un alias a mano.
edofullo crei delle nuove interfacce LAN sul pfsense collegate a dei bridge diversi di proxmox e metti il prefixid diverso, poi devi sistemare il firewall.
Eh ieri ho provato ma non ne vuole sapere di assegnare un IP sull'altra interfaccia. [Come non detto dovevo riavviare la WAN il perchè non lo so] (In IPv4 Funziona tutto)
Ora come ora vorrei capire perchè unbound non mi risolve i domini del voip nonostante li ho configurati come override...
C:\Users\Hitech95>nslookup
Server predefinito: p55.lan
Address: 192.168.1.254
> server 2a0e:404:0:a::1
Server predefinito: [2a0e:404:0:a::1]
Address: 2a0e:404:0:a::1
> sky.it
Server: [2a0e:404:0:a::1]
Address: 2a0e:404:0:a::1
Risposta da un server non autorevole:
Nome: sky.it
Addresses: 185.26.143.165
185.26.140.70
> voip.sky.it
Server: [2a0e:404:0:a::1]
Address: 2a0e:404:0:a::1
*** [2a0e:404:0:a::1] non è in grado di trovare voip.sky.it: Non-existent domain
> voip.it.isp.sky
Server: [2a0e:404:0:a::1]
Address: 2a0e:404:0:a::1
Nome: voip.it.isp.sky
C:\Users\Hitech95>nslookup
Server predefinito: p55.lan
Address: 192.168.1.254
> voip.it.isp.sky
Server: p55.lan
Address: 192.168.1.254
*** Nessun record internal type for both IPv4 and IPv6 Addresses (A+AAAA) disponibile per voip.it.isp.sky
> server 2a0e:XXXX:XXXX:0:XXXX:56ff:fe29:XXXX
Server predefinito: p55.lan
Address: 2a0e:XXXX:XXXX:0:XXXX:56ff:fe29:XXXX
> voip.it.isp.sky
Server: p55.lan
Address: 2a0e:XXXX:XXXX:0:XXXX:56ff:fe29:XXXX
*** Nessun record internal type for both IPv4 and IPv6 Addresses (A+AAAA) disponibile per voip.it.isp.sky
spnick No e non sono tenuti a pubblicare i dati per il collegamento, ma io uso un modem Huawei in bridge sulla Mikrotik, basta googlare.
hitech95 perchè unbound non mi risolve i domini del voip
Occhio però che non sono tutti record AAAA, quindi dovrai cambiare il tipo di query con set type=srv
se non sbaglio
hitech95 Mi sa che sei fuori strada per il voip.
voip.sky.it è solamente il dominio di rete. come Telecomitalia.it per TIM.
la query prova a farla su:
nslookup -query=AAAA voip.it.isp.sky 2a0e:404:0:a::1
Questa dovrebbe funzionare:
nslookup -query=srv _sip._udp.voip.it.isp.sky 2a0e:404:0:a::1
`
x_term Il discorso invece del test su ipv6-test, intanto considera che ICMP appare filtered giustamente, tu non vuoi che il tuo PC risponda ai ping da tutto internet, no?
In realtà in IPv6 ICMP gioca un ruolo più importante che in IPv4: https://datatracker.ietf.org/doc/html/rfc4890
hitech95 Comunque non ho ancora ben capito la differenza tra DHCPv6, SLAAC e RA.
Sembrano fare tutti la stessa cosa.
Sì, ma la fanno in modo diverso. Poi IPv6 complica le cose con DHCPv6 stateful e stateless, più SLAAC e RA.
DHCPv6 stateful funziona come in IPv4 - il server DHCP genera l'indirizzo, ne tiene traccia (ecco perché stateful) e lo invia a chi ne fa richiesta più le altre informazioni. Io uso questo perché 1) il server DHCP registra gli indirizzi nel DNS e solo lui può farlo 2) ho il log dei client che hanno richiesto un IP. L'unico problema è Android perché in Google c'è un deficiente che non vuole che i suoi "tessssori" abbiano l'accesso controllato dal proprietario della rete.
Con DHCPv6 stateless il client ottiente il prefisso via RA e poi usa SLAAC per generare l'indirizzo. Poi usa DHCP per ottenere le altre informazioni (es. server DNS). Il server DHCP non tiene traccia dei client. Se vuoi la registrazione nel DNS deve registrarsi il client per conto suo. A me non piace per questo motivo.
Oppure puoi usare solo SLAAC e RA - ti perdi il controllo centralizzato di DHCP.
fracarza nslookup -query=any voip.sky.it 2a0e:404:0:a::1 cosa dice?
gandalf2016 nslookup -query=AAAA voip.it.isp.sky 2a0e:404:0:a::1
nslookup -query=srv sip.udp.voip.it.isp.sky 2a0e:404:0:a::1
C:\Users\Hitech95>nslookup -query=AAAA voip.it.isp.sky 2a0e:404:0:a::1
Server: UnKnown
Address: 2a0e:404:0:a::1
*** UnKnown non è in grado di trovare voip.it.isp.sky: No response from server
C:\Users\Hitech95>nslookup -query=srv _sip._udp.voip.it.isp.sky 2a0e:404:0:a::1
Server: UnKnown
Address: 2a0e:404:0:a::1
*** UnKnown non è in grado di trovare _sip._udp.voip.it.isp.sky: No response from server
C:\Users\Hitech95>nslookup -query=any voip.sky.it 2a0e:404:0:a::1
Server: UnKnown
Address: 2a0e:404:0:a::1
*** UnKnown non è in grado di trovare voip.sky.it: No response from server
C:\Users\Hitech95>
gandalf2016 voip.sky.it mi sa che è solamente il dominio di rete
Si si infatti, ma io ci avevo provato lo stesso!
fracarza Ora però ti sta dando un altro problema, che il server non risponde. Se fai
Si per qualche ragione radvd era andato giù e non avevo più un indirizzo IPv6
C:\Users\Hitech95>nslookup -query=any sky.it 2a0e:404:0:a::1
Server: UnKnown
Address: 2a0e:404:0:a::1
Risposta da un server non autorevole:
sky.it internet address = 185.26.143.165
sky.it internet address = 185.26.140.70
sky.it text =
"MS=ms90374774"
sky.it text =
"MS=ms97918068"
sky.it text =
"v=spf1 ip4:185.26.140.52/32 include:spf.protection.outlook.com -all"
sky.it text =
"google-site-verification=FcJkvvSDYWAZixO3SPwluEgx9Slo8-9Vwsdy2kEhdr4"
sky.it text =
"MS=ms45245552"
sky.it
primary name server = ns1.sky.it
responsible mail addr = hostmaster.sky.it
serial = 2021053005
refresh = 86400 (1 day)
retry = 3600 (1 hour)
expire = 3600000 (41 days 16 hours)
default TTL = 3600 (1 hour)
sky.it nameserver = ns1.sky.it
sky.it nameserver = ns2.sky.it
sky.it MX preference = 10, mail exchanger = sky-it.mail.protection.outlook.com
ns1.sky.it internet address = 185.26.140.129
ns2.sky.it internet address = 185.26.142.129
C:\Users\Hitech95>nslookup -query=any voip.it.isp.sky 2a0e:404:0:a::1
Server: UnKnown
Address: 2a0e:404:0:a::1
Risposta da un server non autorevole:
voip.it.isp.sky ??? unknown type 35 ???
it.isp.sky nameserver = ns1.it.isp.sky
it.isp.sky nameserver = ns0.it.isp.sky
it.isp.sky nameserver = ns2.it.isp.sky
ns0.it.isp.sky internet address = 101.62.253.25
ns1.it.isp.sky internet address = 101.62.253.26
ns2.it.isp.sky internet address = 101.62.253.27
C:\Users\Hitech95>nslookup -query=any voip.sky.it 2a0e:404:0:a::1
Server: UnKnown
Address: 2a0e:404:0:a::1
*** UnKnown non è in grado di trovare voip.sky.it: Non-existent domain
C:\Users\Hitech95>
Comunque Asterisk non ne vuole sapere di registrare la trunk.
<Registration/ServerURI..............................> <Auth..........> <Status.......>
==========================================================================================
Clouditalia/sip:voip.eutelia.it Clouditalia Registered
SkyWifi/sip:voip.sky.it:5060 SkyWifi Rejected
Objects found: 2
[2021-05-14 14:32:00] WARNING[10287] res_pjsip_outbound_registration.c: No response received from 'sip:voip.sky.it:5060' on registration attempt to 'sip:NNNNNNXXXXXXXXX@voip.sky.it', retrying in '60'
Più tardi vado di debug cattivo -vvvv
e miguardo tutti i frame SIP...
Dalla macchina PBX:
[root@freepbx ~]# host -t NAPTR voip.it.isp.sky
voip.it.isp.sky has NAPTR record 10 100 "S" "SIP+D2U" "" _sip._udp.voip.glb.it.isp.sky.
[root@freepbx ~]#
Non conosco questa tipologia di DNS, ma immagino che venga correttamente interpretata.
Mi sembra tutto regolare:
PJSIP Endpoint
[SkyWifi]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=ulaw,alaw
aors=SkyWifi
language=it
outbound_proxy=sip:voip.it.isp.sky:5060
outbound_auth=SkyWifi
from_domain=sip:voip.sky.it:5060
from_user=sip:<username>@voip.sky.it:5060
user_eq_phone=no
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rtp_symmetric=yes
dtmf_mode=auto
PJSIP Auth
[SkyWifi]
type=auth
auth_type=userpass
password=<redacted>
username=<redacted>
hitech95 Questa configurazione mi puzza un po', ci sono un paio di cose che non mi convincono. Puoi mandare anche aor e registration?
transport
deve essere IPv6 quindi 0.0.0.0-udp
non va bene, dovresti avere bind su ::
non 0.0.0.0
(se il bind è corretto in 0.0.0.0-udp
allora ok, ma dovresti cambiargli il nome per rendere più chiaro o meglio ancora creare due trasporti diversi). outbound_proxy
non deve avere :5060
. from_domain
è solo voip.sky.it
e from_user
solo <username>
, ma entrambi non sono particolarmente necessari.
fracarza
Super pappardella per voi
AOR
[SkyWifi]
type=aor
qualify_frequency=61
contact=sip:XXXXXXXXXXXXXXXX@voip.sky.it
outbound_proxy=sip:voip.it.isp.sky:5060
Registration:
[SkyWifi]
type=registration
transport=0.0.0.0-udp
outbound_auth=SkyWifi
retry_interval=60
fatal_retry_interval=0
forbidden_retry_interval=10
max_retries=10
expiration=3600
line=yes
endpoint=SkyWifi
auth_rejection_permanent=yes
server_uri=sip:voip.sky.it:5060
client_uri=sip:XXXXXXXXXXXXXXXX@voip.sky.it
outbound_proxy=sip:voip.it.isp.sky:5060
Verbose log di asterisk: (occhio che ho un altra trunk con eutelia)
freepbx*CLI> pjsip set logger on
PJSIP Logging enabled
[2021-05-14 20:02:06] DEBUG[7901]: res_pjsip_registrar.c:1176 check_expiration_thread: Woke up at 1621015326 Interval: 30
[2021-05-14 20:02:06] DEBUG[7901]: res_pjsip_registrar.c:1183 check_expiration_thread: Expiring 0 contacts
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_options.c:926 sip_options_qualify_aor: Qualifying all contacts on AOR 'SkyWifi'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_options.c:856 sip_options_qualify_contact: Qualifying contact 'SkyWifi@@81175c713807c4225acf899c8c745ae2' on AOR 'SkyWifi'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip.c:3983 endpt_send_request: 0x7fb03000a278: Wrapper created
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip.c:3998 endpt_send_request: 0x7fb03000a278: Set timer to 3000 msec
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:477 sip_resolve: Performing SIP DNS resolution of target 'voip.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:504 sip_resolve: Transport type for target 'voip.it.isp.sky' is 'UDP'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:547 sip_resolve: [0x7fb03000b600] Created resolution tracking for target 'voip.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target 'voip.it.isp.sky' with record type '35', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target '_sip._udp.voip.it.isp.sky' with record type '33', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target 'voip.it.isp.sky' with record type '1', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:616 sip_resolve: [0x7fb03000b600] Starting initial resolution using parallel queries for target 'voip.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:277 sip_resolve_callback: [0x7fb03000b600] All parallel queries completed
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:371 sip_resolve_callback: [0x7fb03000b600] NAPTR record received on target 'voip.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target '_sip._udp.voip.glb.it.isp.sky' with record type '33', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:413 sip_resolve_callback: [0x7fb03000b600] New queries added, performing parallel resolution again
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:277 sip_resolve_callback: [0x7fb03000b600] All parallel queries completed
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7fb03000b600] SRV record received on target '_sip._udp.voip.glb.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target 'sbc.rmle1.voip.glb.it.isp.sky' with record type '1', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7fb03000b600] SRV record received on target '_sip._udp.voip.glb.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target 'sbc.mid41.voip.glb.it.isp.sky' with record type '1', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7fb03000b600] SRV record received on target '_sip._udp.voip.glb.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target 'sbc.rmtp1.voip.glb.it.isp.sky' with record type '1', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:349 sip_resolve_callback: [0x7fb03000b600] SRV record received on target '_sip._udp.voip.glb.it.isp.sky'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000b600] Added target 'sbc.mica1.voip.glb.it.isp.sky' with record type '1', transport 'UDP', and port '5060'
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:413 sip_resolve_callback: [0x7fb03000b600] New queries added, performing parallel resolution again
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:277 sip_resolve_callback: [0x7fb03000b600] All parallel queries completed
[2021-05-14 20:02:20] DEBUG[7899]: res_pjsip/pjsip_resolver.c:419 sip_resolve_callback: [0x7fb03000b600] Resolution completed - 0 viable targets
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_resolver.c:207 sip_resolve_invoke_user_callback: [0x7fb03000b600] Invoking user callback with '0' addresses
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip.c:3861 endpt_send_request_cb: 0x7fb03000a278: PJSIP tsx response received
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip.c:3874 endpt_send_request_cb: 0x7fb03000a278: Cancelling timer
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip.c:3883 endpt_send_request_cb: 0x7fb03000a278: Timer cancelled
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip.c:3904 endpt_send_request_cb: 0x7fb03000a278: Callbacks executed
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip.c:3960 send_request_wrapper_destructor: 0x7fb03000a278: wrapper destroyed
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_options.c:758 sip_options_contact_status_notify_task: Contact SkyWifi/sip:XXXXXXXXXXXXXXXX@voip.sky.it status didn't change: Unreachable, RTT: 0.000 msec
[2021-05-14 20:02:20] DEBUG[10287]: res_pjsip/pjsip_options.c:776 sip_options_contact_status_notify_task: AOR 'SkyWifi' now has 0 available contacts
[2021-05-14 20:02:28] DEBUG[3950]: manager.c:6473 process_message: Running action 'Login'
[2021-05-14 20:02:29] DEBUG[3950]: manager.c:6473 process_message: Running action 'Command'
[2021-05-14 20:02:29] DEBUG[3950]: manager.c:6473 process_message: Running action 'Command'
[2021-05-14 20:02:29] DEBUG[3950]: manager.c:6473 process_message: Running action 'Command'
[2021-05-14 20:02:29] DEBUG[3950]: manager.c:6473 process_message: Running action 'Command'
[2021-05-14 20:02:29] DEBUG[3950]: manager.c:6473 process_message: Running action 'Command'
[2021-05-14 20:02:29] DEBUG[3950]: manager.c:6473 process_message: Running action 'Command'
[2021-05-14 20:02:29] DEBUG[3950]: devicestate.c:367 _ast_device_state: No provider found, checking channel drivers for PJSIP - SkyWifi
[2021-05-14 20:02:29] DEBUG[3950]: manager.c:6473 process_message: Running action 'Command'
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip_outbound_registration.c:575 handle_client_registration: Outbound REGISTER attempt 3 to 'sip:voip.sky.it:5060' with client 'sip:XXXXXXXXXXXXXXXX@voip.sky.it'
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip/pjsip_resolver.c:477 sip_resolve: Performing SIP DNS resolution of target 'voip.it.isp.sky'
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip/pjsip_resolver.c:504 sip_resolve: Transport type for target 'voip.it.isp.sky' is 'UDP'
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip/pjsip_resolver.c:547 sip_resolve: [0x7fb03000af40] Created resolution tracking for target 'voip.it.isp.sky'
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip/pjsip_resolver.c:177 sip_resolve_add: [0x7fb03000af40] Added target 'voip.it.isp.sky' with record type '1', transport 'UDP', and port '5060'
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip/pjsip_resolver.c:616 sip_resolve: [0x7fb03000af40] Starting initial resolution using parallel queries for target 'voip.it.isp.sky'
[2021-05-14 20:02:31] DEBUG[7899]: res_pjsip/pjsip_resolver.c:277 sip_resolve_callback: [0x7fb03000af40] All parallel queries completed
[2021-05-14 20:02:31] DEBUG[7899]: res_pjsip/pjsip_resolver.c:419 sip_resolve_callback: [0x7fb03000af40] Resolution completed - 0 viable targets
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip/pjsip_resolver.c:207 sip_resolve_invoke_user_callback: [0x7fb03000af40] Invoking user callback with '0' addresses
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip_outbound_registration.c:1056 sip_outbound_registration_response_cb: Received REGISTER response 503(No answer record in the DNS response (PJLIB_UTIL_EDNSNOANSWERREC))
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip_outbound_registration.c:906 handle_registration_response: Processing REGISTER response 503 from server 'sip:voip.sky.it:5060' for client 'sip:XXXXXXXXXXXXXXXX@voip.sky.it'
[2021-05-14 20:02:31] DEBUG[10287]: res_pjsip_outbound_registration.c:635 schedule_registration: Scheduling outbound registration to server 'sip:voip.sky.it:5060' from client 'sip:XXXXXXXXXXXXXXXX@voip.sky.it' in 60 seconds
[2021-05-14 20:02:31] WARNING[10287]: res_pjsip_outbound_registration.c:796 schedule_retry: No response received from 'sip:voip.sky.it:5060' on registration attempt to 'sip:XXXXXXXXXXXXXXXX@voip.sky.it', retrying in '60'
[2021-05-14 20:02:31] DEBUG[13044]: manager.c:6017 match_filter: Examining AMI event:
Event: Registry
Privilege: system,all
ChannelType: PJSIP
Username: sip:XXXXXXXXXXXXXXXX@voip.sky.it
Domain: sip:voip.sky.it:5060
Status: Rejected
Non manda nessun pacchetto SIP fuori o perlomeno non mi mostra nulla riguardo la trunk di sky!
Informativa privacy
-
Informativa cookie
-
Termini e condizioni
-
Regolamento
-
Disclaimer
-
🏳️🌈
P.I. IT16712091004 - info@fibraclick.it
♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile