handymenny Allora, ho fatto un po' di test. Dal tool del Mac si può fare al massimo copia e incolla in formato testo. Ho salvato un po' di log in formato .txt, se ti vuoi divertire dimmi come e te li mando.
Purtroppo le mie sim W3 e Very hanno tutte il VoLTE attivo, quindi non ho avuto modo di testare il comportamento con l'errore PCN 33.
Per quanto riguarda le chiamate, ho fatto un confronto tra W3 e Vodafone:
In caso di utente occupato, entrambi gli operatori rispondono con SIP 486 Busy Here, il messaggio viene interpretato correttamente (senza alcuna specifica nel carrier bundle) e la chiamata termina. Evidentemente, fino a poco tempo fa, W3 rispondeva con un messaggio diverso, ipotizzo il 480 Temporary Unavailable con nel campo reason "Q.850;cause=17". Dai log si evince che il telefono è in grado di interpretare questo campo e i cause codes sono questi (ecco perché ieri mi ero confuso).
Ora viene il bello, ho testato anche i casi "numero inesistente" e "nessuna risposta" (squilla a vuoto).
Nel primo caso (inesistente), la risposta del server, sia per W3 che per VF, è 480 (Temporary Unavailable) con nel campo reason: "Q.850;cause=31" (Normal, unspecified).
Questo con W3, dopo aver ascoltato il messaggio audio, fa scattare il CSFB (Circuit Switching Fallback) e parte una nuova chiamata in 3G (che spreco) in quanto nella configurazione è presente:
<key>InviteErrorResponsesToTriggerCSFB</key>
<string>3XX,4XX,5XX,6XX</string>
Nel secondo caso (no answer), con W3, dopo 58 secondi da quando inizia a squillare (180 Ringing) si riceve anche qui un bel 480 ma con il campo reason: "Q.850;cause=19" (no answer from user). Anche questo fa scattare il fallback, con il risultato che dopo aver squillato a vuoto per circa un minuto, parte una seconda chiamata in 3G e squilla di nuovo (pensa che scatole per chi riceve).
Risposta identica con la sim Vodafone ma la chiamata termina e non va in 3G. Perché? Ecco il motivo.
Anche Vodafone ha la stringa che fa scattare il fallback con gli errori 4XX, ma Apple per loro ha risolto aggiungendo queste righe:
<key>IncomingCallEndReasons</key>
<dict>
<key>NoAnswerFromUser1</key>
<dict>
<key>DisableCSFB</key>
<true/>
<key>Protocol</key>
<string>Q.850</string>
<key>ReasonHeaderCause</key>
<integer>31</integer>
<key>StatusCode</key>
<integer>480</integer>
<key>TerminationEvent</key>
<string>RemoteHangup</string>
</dict>
<key>NoAnswerFromUser2</key>
<dict>
<key>DisableCSFB</key>
<true/>
<key>Protocol</key>
<string>Q.850</string>
<key>ReasonHeaderCause</key>
<integer>19</integer>
<key>StatusCode</key>
<integer>480</integer>
<key>TerminationEvent</key>
<string>RemoteHangup</string>
</dict>
</dict>
Invece per TIM hanno tagliato la testa al toro e hanno risolto togliendo i codici 4XX da quelli che fanno scattare il fallback:
<key>InviteErrorResponsesToTriggerCSFB</key>
<string>3XX,5XX,6XX</string>
E secondo me non è neanche così sbagliato, i Network Failure sono altri.
Secondo me la soluzione scelta dipende molto dall'ingegnere Apple che mette mano alla configurazione (ho visto alcuni stili diversi nei file che ho analizzato) oppure hanno dei template a seconda del vendor utilizzato dall'operatore.
EDIT: Ho ripetuto il test "no answer" (sullo stesso numero) e ora la risposta di W3 è 408 Request Timeout con reason: "Q.850;cause=31". Boh, non capisco se ci stanno mettendo le mani oppure dipende dal gateway che risponde.
