I am still digging in this cseq uac problem which I need desperately to solve.
 
The problem is that the uac_auth function can create credentials for the downstream proxy after being challenged with a 401 or 407 message - but the downstream proxy (UAS) refuses this proxy_auth message since openser does not increase the cseq number. Increasing the cseq number only downstream wouldnt solve the problem since any replies of the downstream proxy back to the originating UAC would have cseq numbers which are out of sync.
 
I propose: In order to keep the cseq numbers in sync upstream and downstream one must generate challenges and proxy-auth responses on both legs of the route - and not only respond downstream as currently.
 
So whenever openser receives from the downstream proxy a challenge it must forward this challenge the originating UAC (if necessary modify the message in such a way that the UAC is guaranteed to respond). This upstream challenge causes the originating UAC to increase the cseq. Naturally openser must also increase the cseq number downstream  when generating its own proxy_auth repsonse to the downstream proxy. Whatever credentials UAC produces are discarted by openser.
 
The scheme:
 
1. UAC issues invite which is routed by OS to the downstream proxy (UAS) - as usual.
2. UAS issues challenge 401 or 407 - as usual
3. OS captures challenge on_failure route - as envisaged by UAC module
4. this is new:
a) OS relays the challenge upstream to UAC (would it be necessary to modify it before doing so ?)
b) OS constructs with uac_auth function correct proxy_auth credentials for UAS, increases the cseq with some text manipulation function and replies to UAS.
5. UAC responds with (wrong) proxy_auth credentials via OS to UAS
6. OS discards the credential message it received from the UAC - to avoid that the message reaches UAS.
7. Invite successful or failure : UAS responds with further messages which are routed to UAC.
 
Can this scheme work - or am I overlooking something here ?
 
TIA
 
Gerry