In debugging yet another SIP hardware device I found that it was not authenticating after an INVITE. That is, the device sends me 'INVITE', I say '401', it says 'ACK', but I never hear from it again.
I am expecting another INVITE with the proper credentials...
In talking with the hardware vendor they let me know that I should be sending back a 407 instead of a 401. I have always done a www_challenge sequence, but, I wonder if that is truly proper. After all, SER is a proxy. Should I be challenging with a 'proxy_challenge'?
Certainly either should work, because the device you are communicating with could be a UA or a PROXY. What is the 'proper' thing to do?
I guess I have always thought that the 'proxy_challenge' was for one proxy server communicating with another. However I don't see how that can be now, because the originating proxy server has no mechanism to provide authentication credentials...
The more I learn, the less I know,
---greg
At 04:13 PM 12/4/2003, Greg Fausak wrote:
In debugging yet another SIP hardware device I found that it was not authenticating after an INVITE. That is, the device sends me 'INVITE', I say '401', it says 'ACK', but I never hear from it again.
I am expecting another INVITE with the proper credentials...
In talking with the hardware vendor they let me know that I should be sending back a 407 instead of a 401. I have always done a www_challenge sequence, but, I wonder if that is truly proper. After all, SER is a proxy. Should I be challenging with a 'proxy_challenge'?
The standard wants to use proxy_challenge (407) for proxies, www_challenge (401) for UAS such as registrar. The practical value of having two does not seem to be big to me, but if it makes your device happy, there should be no issue.
So use www_challenge and www_authorize for REGISTERs and proxy_chalenge|proxy_authorize for non-REGISTERs.
-jiri