Did you find a solution to your problem?
Actually, I do see the same thing and German Telekom is not really helpful. They have some technical documentation (like 1TR114 and 1TR118), but their customer service gets freaked out when you start to ask about some missing details in these documents…
Anyway, the problem looks as if it is not really Asterisk related. Assuming that there are no problems with the registration (which involves a couple of other tricks), the problem is likely occur, if there have been no outgoing calls for a longer period of time. In my case, restarting Asterisk (a simple sip reload does not seem to work) always helped. The only noticable difference from the outside is that the restart goes through the mandatory challenge/response sequence for the initial registrations, but this does not directly affect the outgoing calls. I do not know what is actually happening on the Telekom servers.
Currently I have SRV lookups enabled and the current IP gets looked up this way before each outgoing call, which is easy to verify with pcap traces. The Asterisk docs say that only the first entry gets resolved, but the Telekom returns at least two. I wonder whether one should periodically evaluate all returned records and correlate that with successful and failed calls.
I’d say, if the problem is related to the CNAME cascades that are usually returned, then registering to all servers returned by the dig SRV command and modifying the dial plan to check the other ones in case 403 gets returned, should solve the problem. If it is a deeper problem, not related to address changes, then a restart seems to solve the problem for chan_sip, though Idon’t know why. PJSIP might be more clever as there are provisions to cope with address changes, but I haven’t tested that yet.
Of course, any hints are much appreciated.