I don’t think there is anything wrong with the Contact header. It is simply reflecting your ITSP’s policy.
Without checking, I assume that the expiry in the request says when the UAC intends to refresh the registration and that in the Contact, when the UAS requires it to do so.
That is correct - the expiration in a Contact or REGISTER Is what the client has requested, but the server is free to override that and provide back a different value which the client then has to re-register within. Exactly what is happening here, and perfectly fine.
Sorry, I haven’t dealt with “standalone” sip providers so far. My experience so far were dsl providers with sip service (next generation network). And they usually don’t allow nomadic registration. Probably that’s why they are usually keen on long intervals between registrations to lower the network traffic. (Just a guess.)
But if easybell offers 90 seconds, that’s fine with me. This way, there is no need to do any udp hole punching attempts, since the Linux conntrack module should recognize the registration traffic as “established” udp traffic (timeout for those is 180 seconds, as far as I can remember). Right?