Filippo94 Io credo piuttosto che il problema sia proprio dovuto al fatto che fritz quel codec non lo supporti, il che può significare che il server voip che integrano non è configurato correttamente per questa codifica. Comunque con questa impostazione le chiamate in ingresso funzionano come un pippino.

    timyhack Ottimo, più tardi provo e ti dico se funziona tutto.
    Ma dici di disabilitare l'aggiornamento automatico o non è un problema?

    timyhack io ve l’avevo detto 11 gg fa di provare con un solo codec…

    https://forum.fibra.click/d/48958-voip-vodafone-e-fritzbox-chiamate-in-entrata-si-interrompono-dopo-32-secondi/134

    Già che ci sei togli pure PCMU che tanto in Italia è poco utilizzato.

    Ps. Avvisate anche AVM di questa scoperta così li mettete sulla buona strada…

    • [cancellato]

    timyhack

    In questo modo ti assicuri che se qualcuno cerca di chiamare in G.729 e non può passare ad altro codec (mi pare Eolo lo faccia), la chiamata non cominci neppure a meno che il proxy non faccia transcoding. È comunque interessante che in ingresso usi sempre G.729 che comunque è un codec di qualità audio inferiore, utile solo dove la banda è veramente limitata.

    timyhack Io credo piuttosto che il problema sia proprio dovuto al fatto che fritz quel codec non lo supporti,

    Nella documentazione effettivamente non è riportato, però allora perché nella 200 OK (vedi catture sopra) c'è? Al massimo gli dice che non supporta Annex B. Altrimenti comunque la chiamata non si instaurerebbe in G.729 se non ci fosse il supporto per il codec. Non è che AVM ha fatto la furba perché fino all 2017 c'erano problemi di brevetti?

    Rimane da capire perché viene selezionato G.729 e nel caso la chiamata viene buttata giù dopo i 32s. Nel caso di disabilitazione del caller ID, con che codec viene instaurata la chiamata? Perché adesso sappiamo di due configurazioni scorrelate - caller ID e codec - che funzionano da workaround.

      [cancellato] Perché adesso sappiamo di due configurazioni scorrelate - caller ID e codec - che funzionano da workaround.

      farebbe pensare a un problema di lunghezza dei messaggi SIP.
      Io nel dubbio proverei a disattivare un altro codec, mi aspetto un risultato simile

        • [cancellato]

        handymenny

        Potrebbe anche essere - anche se sarebbe veramente curioso che un server SIP moderno sbrocchi per una questione del genere. ma visto che gli anni '70 sono di moda in IT non mi meraviglierei troppo. C'è da chiedersi come mai con il Fritz superi questo limite mentre con altri no, è possibile che il Fritz sia magari particolaremente "verboso", bisognerrebe fare un confronto con altri sistemi. Rimane il fatto che l'ACK c'è, non dovrebbe, cosa che fa pensare comunque a qualche bug lato Vodafone.

        Ho appena effettuato 2 test, dallo stesso cellulare chiamante. La prima volta col CallerID no visibile e la seconda volta visibile. Come mi aspettavo la prima chiamata è andata oltre i 32 secondi, l'ho terminata ad 1:03. La seconda invece si è fermata come prevedibile ai 32 secondi.

        In entrambi i casi il codec concordato è stato il G.729.

        Mi sentirei pertanto di escludere il codec audio in se.

        Ho anche io lo stesso problema con VoIP Vodafone e Fritz!Box 7530, sia in entrata che in uscita. Che voi sappiate il problema del 7530 è solo con Vodafone?

        La station stessa utilizza il g729 stesso, non può essere lui il problema. Penso sia più probabile un problema di lunghezza messaggi, magari causa MTU in rete Vodafone e relativa frammetazione e 200 OK che non arriva mai a destinazione .

        Potreste verificare abilitando solo:
        alaw e g729

        timyhack use_audiocodecs = yes;
        audiocodecs = "PCMA", "PCMU";

        Prova a impostare, che sarebbe la configurazione corretta per Vodafone Italia:

        use_audiocodecs = yes;
        audiocodecs = "PCMA", "G729";

          • [cancellato]

          gandalf2016 200 OK che non arriva mai a destinazione .

          L'ACK però Vodafone lo manda... io propendo per qualcosa che triggera un bug di parsing della risposta che rende la sessione "instabile". Può essere che Vodafone debba aspettare una patch del sistema VoIP.

          Come detto nel penultimo msg, ho reinstallato il modem Vodafone Power Station (il giorno 7 febbraio, c.a.). Fino ad oggi le chiamate rifunzionavano regolarmente. Nel pomeriggio di nuovo non riuscivo più a ricevere (faceva solo uno squillo e poi la chiamata in ingresso cadeva). Analizzando il log Eventi ho rilevato un messaggio "monitor stat file missed, create it" (vedi immagine):

          Dopo di che le telefonate in ingresso non arrivavano più (elenco telefonate, dopo le 19.00 il modem è stato riavviato):

          Non so se questo possa essere utile a chi ne sa più di me. Alla fine ho dovuto riavviare il modem. Adesso funziona, ma non so per quanto...

          gandalf2016 Aggiungo un curiosità non riportata da nessun parte ovvero che le Vodafone Station utilizzano anche AMR-WB (G.722.2), non so però se è supportato dai Fritz! (penso di sì).

          Io credo che se il problema fosse il codec la chiamata nemmeno arriverebbe...

            xarabas non è il codec in sè quando il mandare tanti codec nell’offer che allunga il messaggio SIP, triggerando probabilmente il bug

            Qua però deve intervenire Vodafone o avm.
            Vodafone pare ci stia lavorando, avm invece mi sembra dormire un po'...

            Noto da un po' di notti che mi trovo questa scritta: "La connessione Internet (telefonia) viene interrotta brevemente per anticipare la chiusura forzata da parte del provider." Poi si disconnette e si riconnette, il tutto nell'arco di 2/3 secondi...avete idea?

            • Hadx ha risposto a questo messaggio

              Aggiungo una informazione alla discussione. Con la modifica indicata in precedenza avevo risolto il problema dell'interruzione delle chiamate in entrata dopo 32 secondi, il fix funziona da oltre una settimana.
              Avevo un ulteriore problema sporadico con le chiamate entranti: a volte il telefono non suonava ed al chiamante veniva rirpodotto il suono di prolemi di connessione e dispositivo non raggiungibile dopo due squilli.
              Per questo secondo problema la soluzione (almeno per me) è stata quella di impostare

              sip_options_ping_interval = 60s;

              Nella mia configurazione precedente era impostata a 0w, che significa disabilitata.

              L'impostazione sip_options_ping_interval è specificamente legata alla funzionalità di mantenimento della sessione e della registrazione in ambiente VoIP, utilizzando il protocollo SIP. Questa impostazione determina l'intervallo di tempo tra l'invio di messaggi SIP OPTIONS per verificare la disponibilità di un endpoint SIP (ad esempio, un telefono VoIP o un centralino) e per mantenere aperta la sessione attraverso dispositivi di rete configurati con NAT e firewall.

                Questa impostazione però la si può mettere anche dalla webgui se non ho capito male.

                Visto che il sistema di timyhack funziona l'ho comunicato ad avm, senza prendermi il merito, ora vediamo che rispondono...

                [cancellato] Altrimenti comunque la chiamata non si instaurerebbe in G.729 se non ci fosse il supporto per il codec. Non è che AVM ha fatto la furba perché fino all 2017 c'erano problemi di brevetti?

                Magari per non pagare la licenza hanno installato il codec in versione "trial" che funziona per 30 secondi e poi si chiude. 🤣

                Provato ad aggiungere il codec 729 alla stringa...niente, dopo 32 secondi le telefonate in arrivo cadono.

                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