simonebortolin

Mmmmmh non viene fatto per il Voip che serve per il vo-wifi?

In realtà si faceva, poi è stato tolto per semplicificare la configurazione del modem libero.
TIM ancora oggi comunque ha la VLAN 837 che ha un CoS migliore dedicata al VoIP che è ancora in funzione anche se ormai non la utilizza più nessuno.. manco i modem TIM

    ErnyTech TIM ancora oggi comunque ha la VLAN 837 che ha un CoS migliore dedicata al VoIP che è ancora in funzione anche se ormai non la utilizza più nessuno.. manco i modem TIM

    La hanno mai utilizzata? Cioè io non ho ricordi di usi di quella VLAN, forse nel caso di centralini.

      simonebortolin Per anni è stata usata per il VoIP quando non esisteva ancora il modem libero e non si poteva usare il VoIP senza modem TIM

      ErnyTech VLAN 837

      OT, sempre PPPoE solite credenziali?

        eutampieri Se intendi le solite credenziali che si usavano anni fa per fare funzionare il VoIP allora si altrimenti se intendi le credenziali che si usano oggi no, oltre questo non rispondo qua che si va OT

        ErnyTech TIM ancora oggi comunque ha la VLAN 837 che ha un CoS migliore dedicata al VoIP

        è vero che lato trasporto esiste ancora ma lato trasmissivo da un po' di tempo sui nuovi circuiti non viene proprio più provisionata tra l'altro se non ricordo male è anch'essa cos0 (magari nei prox gg chiedo, non vorrei ricordare male)

          ErnyTech Io mi ricordavo CoS 5

          Confermo, e tuttora alcuni OLO continuano ad affittare profili VULA MultiCOS pur avendo abbandonato la configurazione con voce su VLAN dedicata (che un operatore però ha usato in coesistenza con la voce pubblica fino all'anno scorso, altri non so)

          Fine OT

          simonebortolin Non è vero, basta con sta storia che i provider applicano QoS all'interno della marea di traffico che ricevono, costerebbe troppo farlo

          E invece e' vero, un esempio che mi viene in mente e' Planetel che applica QoS per il VoIP interno (voce dot planetel dot it), i pacchetti SIP arrivano con DSCP 24 (CS3) e quelli RTP con DSCP 26 (AF31), gli altri con DSCP 0. Non ho modo di vedere al momento se applicano anche CoS differenti, pero' almeno all'interno della loro rete prima della consegna, il traffico voce e' priorizzato.

          E cmq anche nel caso generale, non credo sia vero che "costerebbe troppo farlo", la marcatura in base a regole statiche e' banale, e in passato ci sono stati anche Operatori che facevano DPI per shapare dinamicamente (e pesantemente) il traffico P2P anche su porte "(non) strane", per cui...

          /OT

            • [cancellato]

            LATIITAY Sì ma il discorso resta zoppo perché se anche marchi i tag DSCP poi vengono persi nel trasporto attivo OF/FC/FW 😉 Altrimenti se bastasse questo non ci sarebbero le offerte wholesale con i multi-CoS 😉 e comunque la connessione utente è una PPPoE su VLAN, il router dovrebbe riportare il tag CoS del pacchetto ricevuto sul frame ethernet che contiene quello PPP... no non ha senso... la cosa potrebbe vagamente funzionare in presenza della rete proprietaria gestita da loro e su connessioni IPoE.

            adsltrunks Possibile, ma rimane sempre una gestione di priorità a valle del tuo dispositivo utente, una volta che butta il traffico nella WAN operatore i pacchetti diventano tutti uguali...

              [cancellato] Sì ma il discorso resta zoppo perché se anche marchi i tag DSCP poi vengono persi nel trasporto attivo OF/FC/FW 😉

              Ma io infatti cosa ho detto? Che intanto nella rete di OLO i pacchetti vengono priorizzati correttamente, e che non ho modo al momento di verificare se lo facciano anche sulla consegna verso Telecom (per farlo o devo recarmi in sede a sostituire il modem con uno libero, oppure devo exploitare a distanza il modem, che tanto e' un Lantiq VRX200 pure quello, solo con fuffa proprietaria e pricetag assurdamente elevato... 😛)

              [cancellato] Altrimenti se bastasse questo non ci sarebbero le offerte wholesale con i multi-CoS 😉

              Potrebbe benissimo bastare, se OF/FC/FW volessero. Tutto sta a cosa viene detto agli apparati di controllare per stabilire l'associazione di un pacchetto con una coda.

              [cancellato] e comunque la connessione utente è una PPPoE su VLAN, il router dovrebbe riportare il tag CoS del pacchetto ricevuto sul frame ethernet che contiene quello PPP...

              E che problema ci sarebbe?

              [cancellato] no non ha senso... la cosa potrebbe vagamente funzionare in presenza della rete proprietaria gestita da loro e su connessioni IPoE.

              LOL vabeh convinto tu

              [cancellato] una volta che butta il traffico nella WAN operatore i pacchetti diventano tutti uguali...

              (LOL vabeh convinto tu)2

              handymenny Android usa semplicemente i DNS di sistema (DHCP, statico, "VPN" o DOH in base a cosa ha configurato l'utente)

              Eh ma Android tende sempre a mettere in coda anche 8.8.8.8 e 8.8.4.4 oltre alla configurazione immessa dall'utente oppure ottenuta via DHCP...

                • [cancellato]

                LATIITAY Potrebbe benissimo bastare, se OF/FC/FW volessero.

                Ehmmmm... no. Il trasporto metro ethernet è leggermente più complesso di così. 😉

                LATIITAY E che problema ci sarebbe?

                A farlo con linux/*BSD, nessuno, a convincere i vari TPLink/AVM/Zyxel/whathever son mica tanto convinto...

                  [cancellato] Ehmmmm... no. Il trasporto metro ethernet è leggermente più complesso di così. 😉

                  Ehm... basta far rimappare come si vuole all'OLT e al kit di consegna, eh, non e' che si debba fare chissa' quali magheggi in cio' che sta in mezzo...

                  [cancellato] A farlo con linux/*BSD, nessuno, a convincere i vari TPLink/AVM/Zyxel/whathever son mica tanto convinto...

                  E su cosa pensi che siano tutti basati, secondo te? Linux + SDK proprietari... Se un cliente di quei brand ha bisogno di una feature del genere, gliela implementano. Sempre che non ci pensi gia' Linux e/o l'SDK proprietario... Ora non ho tempo per andare a controllare il codice della kernel interface di ppp/pppoe per Linux (pero' vedi che bello l'open source 😍)

                  E cmq, cioe', se OF/FC/FW volessero potrebbero chiedere ai produttori di ONT/OLT questa customizzazione, per mappare la priorita' IP dentro PPPoE nel CoS della VLAN in base a tabella fornita in qualche modo (hardcoded/OMCI/whatever)... Non vedo perche' porla come se fosse una cosa impossibile quando non lo e', basta che le parti coinvolte lo vogliano e quindi richiedano (e beh ne paghino l'implementazione, visto che e' tutto in qualche modo esternalizzato)...

                  /OT 🙄 😇

                    LATIITAY

                    E cmq, cioe', se OF/FC/FW volessero potrebbero chiedere ai produttori di ONT/OLT questa customizzazione, per mappare la priorita' IP dentro PPPoE nel CoS della VLAN

                    Ma in realtà non bisogna manco farlo:

                    Alla rete se trasporto IP, PPP o banane dentro la VLAN non gliene frega nulla sempre traffico L2 si tratta e la priorità viene applicata proprio sul L2 non sul pacchetto IP (poi eventualmente l'OLO può applicare un ulteriore priorità sul pacchetto IP una volta che ha raggiunto la sua rete).

                      ErnyTech vero, visto che offrono il modello multi VLAN oltre a quello mono VLAN multi CoS... E in fondo per l'OLO e' piu' facile far cosi', piuttosto che stare a modificare le CPE per fargli taggare il traffico specifico su singola VLAN...

                      ErnyTech poi eventualmente l'OLO può applicare un ulteriore priorità sul pacchetto IP una volta che ha raggiunto la sua rete

                      Questo direi che e' essenziale a prescindere, andrebbe fatto direttamente sul primo apparato connesso direttamente al kit di consegna.

                        LATIITAY E così una volta che raggiunge la rete OLO è sufficente applicare la priorità a tutti i pacchetti IP che arrivano da quella specifica VLAN invece di dovere combinare cose complesse sulla CPE

                          ErnyTech gia'... (stavo rispondendo editando prima di vedere la tua risposta 😅)

                          Tutti i pacchetti cmq non saprei, starei sempre attento a classificarmi prioritari solo i pacchetti "buoni" con certi criteri, magari facendo anche ad esempio ratelimit in base al tipo e quantita' di traffico attesi per cliente, altrimenti basta una linea che flooda la VLAN prioritaria (non necessariamente malevolmente eh, bug ed errori umani son sempre dietro l'angolo...) e puo' causare disservizi per tutti...

                            LATIITAY Beh oltre ad andare a verificare IP e porta di destinazione non so che altro si potrebbe controllare senza aumentare eccessivamente il "consumo di risorse"

                              ErnyTech io direi anche la dimensione dei singoli pacchetti (per RTP e RTCP), e se il sistema in uso lo permette senza "problemi", anche il numero di pacchetti per intervallo di tempo (per SIP, RTP e RTCP, in base alla sorgente, IPv4 /32 oppure IPv6 /64), tenendo pur sempre un certo margine nei limiti imposti.

                              Posson sembrare accorgimenti banali e/o superflui, ma poi verra' sempre il giorno in cui saranno serviti... 😅

                              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