Finally figured this out...answers inline:
Klaus Darilion wrote:
Greg Fausak wrote:
This is an interesting problem. I would venture to say that if you did NOT authenticate for those calls that you pass to a spa-3000, then that would work... that is, if your SERPROXY doesn't authenticate.
Good guess. When we disabled the failure route (see below) and SER authentication, the call was completed as expected. The 401 came back all the way to UA1 and it resent the INVITE with the proper credentials for the SPA3000.
Nevertheless I don't have any glue why ser blocks the 401 response from the SIPURA. Please post a SIP message dump.
SER blocked the 401 because we had a failure route associated with that route block. The purpose was to send calls to voicemail in case of some failure/timeout. The 401 was treated as a failure so it was never forwarded to UA1. I disabled the "t_on_failure", and now the 401 did reach back to the UA1. The UA1 would then redo the INVITE with the proper credentials for the SPA3000, but now SER would block and send back a 407 since we have a proxy_authorize on INVITES, and the credentials had already been modified. So now it is very clear that this is not possible. What had me stumped was the t_on_failure deal that was blocking the 401 response.
In any case we can now move on and implement security via other methods.
Thanks for the help!