When SIP requests (like INVITE or REGISTER) are issued the SIP gateway server
can send back 407 Proxy Authentication Required or 401 Unauthorized.
In this case RFC compliant UA must:
1) Send ACK response to the server response to close the transaction.
2) Repeat the initial request and provide additional Authorization (for 401) or Proxy-Authorization (for 407) header in this message. This request must be sent with the same Call-ID and To, From headers as the original one. However, CSeq value must be incremented.
Generation of Authorization header
Regarding generation of Authorization header. From now on, the explanation of generation of Proxy-Authorization header (for 407 server response) is omitted because it is completely identical to scheme described below except “Authorization” header name must be changed to “Proxy-Authorization”.
In 401 Unauthorized server response, the SIP server must provide Authenticate header which will contain parameters of the authorization mechanism supported by server.
SIP servers usually offer Digest authorization scheme which implies that
client does not send user credentials in an open form but calculates digest value which is transmitted on the channel.
The digest value is calculated according to the algorithm specified by server.
When no algorithm is specified in Authenticate header it is assumed that MD5 is used to create digest value.
Authenticate: Digest realm="name_of_realm", nonce="123456AB"
For the example specified above, client is required to form Authorization header containing scheme name, username, realm, URI, server supplied nonce value, nonce counter and digest response string. This digest response string is the product of the algorithm specified (or MD5 by default) in Authentication scheme.
Example of authorization header:
Authorization: Digest username="alexander",realm="name_of_realm", uri="sip:128-195-155-11", nonce="123456AB",nc=00000001,response="0556aeb59034f6b229d1d8d45382ee59"
Generation of digest response
Digest response for MD5 based authorization is generated as follows.
1) First MD5 value is calculated as shown below and converted to HEX representation:
string strH1; MD5("username:name_of_realm:password", (char *) pBinaryBuffer); BINARY_TO_HEX((char *) pBinaryBuffer, strH1);
2) Second MD5 value is calculated as shown below and converted to HEX representation.
The input for the MD5 function contains SIP request name, and some URI.
I believe the URI is not a meaningful value here. The only rule that worked for me
is that URI string which is passed to MD5 must be exactly the same as it is specified in
Authorization header. And I am not sure that full qualified SIP URI will work
for most SIP servers. Instead of REGISTER method there could be INVITE.
string strH2; MD5("REGISTER:sip:128-195-155-11", pBuffer); BINARY_TO_HEX(pBuffer, strH2);
3) Third MD5 is calculated using server nonce value which was supplied in the Authenticate header
in the server 401 response. Note, that nonce value is not converted to binary form and only taken
as a string as it was provided.
string strH3; MD5(strH1 + ":" + strNonce + ":" + strH2, pBuffer); BINARY_TO_HEX(pBuffer, strH3); string DigestResponse = strH3;
After the digest response is created it is included in the authorization header.
When there are problem with provided credentials server can send back 403 Forbidden response.
Otherwise if user is authorized successfuly server should process the request as usual.