|
|
@@ -7,10 +7,10 @@ Jan Janak
|
|
|
|
|
|
Juha Heinanen
|
|
|
|
|
|
- Song Networks
|
|
|
+ TutPro Inc
|
|
|
<[email protected]>
|
|
|
|
|
|
- Copyright © 2002, 2003 FhG FOKUS
|
|
|
+ Copyright © 2002, 2003 FhG FOKUS
|
|
|
Revision History
|
|
|
Revision $Revision$ $Date$
|
|
|
__________________________________________________________________
|
|
|
@@ -33,17 +33,10 @@ Juha Heinanen
|
|
|
1.3.10. secret (string)
|
|
|
1.3.11. nonce_expire (integer)
|
|
|
1.3.12. nonce_auth_max_drift (integer)
|
|
|
- 1.3.13. rpid_prefix (string)
|
|
|
- 1.3.14. rpid_suffix (string)
|
|
|
|
|
|
1.4. Functions
|
|
|
|
|
|
- 1.4.1. www_challenge(realm,qop)
|
|
|
- 1.4.2. proxy_challenge(realm, qop)
|
|
|
- 1.4.3. consume_credentials()
|
|
|
- 1.4.4. is_rpid_user_e164()
|
|
|
- 1.4.5. append_rpid_hf()
|
|
|
- 1.4.6. append_rpid_hf(prefix, suffix)
|
|
|
+ 1.4.1. consume_credentials()
|
|
|
|
|
|
1.1. Overview
|
|
|
|
|
|
@@ -61,9 +54,7 @@ Juha Heinanen
|
|
|
|
|
|
1.2. Dependencies
|
|
|
|
|
|
- The module depends on the following modules (in the other words the
|
|
|
- listed modules must be loaded before this module):
|
|
|
- * sl. The modules needs sl module to send stateless replies.
|
|
|
+ The module does not depend on any other module.
|
|
|
|
|
|
1.3. Parameters
|
|
|
|
|
|
@@ -76,7 +67,7 @@ Juha Heinanen
|
|
|
These three module parameters control which optional integrity checks
|
|
|
will be performed on the SIP message carrying digest response during
|
|
|
digest authentication. auth_check_register controls integrity checks to
|
|
|
- be peformed on REGISTER messages, auth_checks_no_dlg controls which
|
|
|
+ be performed on REGISTER messages, auth_checks_no_dlg controls which
|
|
|
optional integrity checks will be performed on SIP requests that have
|
|
|
no To header field or no To tag (in other words the requests either
|
|
|
establishing or outside dialogs). auth_checks_in_dlg controls which
|
|
|
@@ -430,95 +421,12 @@ modparam("auth", "nonce_expire", 600) # Set nonce_expire to 600s
|
|
|
Example 12. nonce_auth_max_drift example
|
|
|
modparam("auth", "nonce_auth_max_drift", 1) # set max drift to 1 s
|
|
|
|
|
|
-1.3.13. rpid_prefix (string)
|
|
|
-
|
|
|
- Prefix to be added to Remote-Party-ID header field just before the URI
|
|
|
- returned from either radius or database.
|
|
|
-
|
|
|
- Default value is "" (empty string).
|
|
|
-
|
|
|
- Example 13. rpid_prefix
|
|
|
-modparam("auth", "rpid_prefix", "Whatever <")
|
|
|
-
|
|
|
-1.3.14. rpid_suffix (string)
|
|
|
-
|
|
|
- Suffix to be added to Remote-Party-ID header field after the URI
|
|
|
- returned from either radius or database.
|
|
|
-
|
|
|
- Default value is ";party=calling;id-type=subscriber;screen=yes".
|
|
|
-
|
|
|
- Example 14. rpid_suffix
|
|
|
-modparam("auth", "rpid_suffix", "@1.2.3.4>")
|
|
|
-
|
|
|
1.4. Functions
|
|
|
|
|
|
Revision History
|
|
|
Revision $Revision$ $Date$
|
|
|
|
|
|
-1.4.1. www_challenge(realm,qop)
|
|
|
-
|
|
|
- The function challenges a user agent. It will generate a WWW-Authorize
|
|
|
- header field containing a digest challenge, it will put the header
|
|
|
- field into a response generated from the request the server is
|
|
|
- processing and send the reply. Upon reception of such a reply the user
|
|
|
- agent should compute credentials and retry the request. For more
|
|
|
- information regarding digest authentication see RFC2617.
|
|
|
-
|
|
|
- Meaning of the parameters is as follows:
|
|
|
- * realm - Realm is a opaque string that the user agent should present
|
|
|
- to the user so he can decide what username and password to use.
|
|
|
- Usually this is domain of the host the server is running on.
|
|
|
- If an empty string "" is used then the server will generate it from
|
|
|
- the request. In case of REGISTER requests To header field domain
|
|
|
- will be used (because this header field represents a user being
|
|
|
- registered), for all other messages From header field domain will
|
|
|
- be used.
|
|
|
- * qop - Value of this parameter can be either "1" or "0". When set to
|
|
|
- 1 then the server will put qop parameter in the challenge. When set
|
|
|
- to 0 then the server will not put qop parameter in the challenge.
|
|
|
- It is strongly recommended to use qop parameter, however there are
|
|
|
- still some user agents that cannot handle qop parameter properly so
|
|
|
- we made this optional. On the other hand there are still some user
|
|
|
- agents that cannot handle request without qop parameter too.
|
|
|
-
|
|
|
- Example 15. www_challenge usage
|
|
|
-...
|
|
|
-if (www_authorize("iptel.org", "subscriber")) {
|
|
|
- www_challenge("iptel.org", "1");
|
|
|
-};
|
|
|
-...
|
|
|
-
|
|
|
-1.4.2. proxy_challenge(realm, qop)
|
|
|
-
|
|
|
- The function challenges a user agent. It will generate a
|
|
|
- Proxy-Authorize header field containing a digest challenge, it will put
|
|
|
- the header field into a response generated from the request the server
|
|
|
- is processing and send the reply. Upon reception of such a reply the
|
|
|
- user agent should compute credentials and retry the request. For more
|
|
|
- information regarding digest authentication see RFC2617.
|
|
|
-
|
|
|
- Meaning of the parameters is as follows:
|
|
|
- * realm - Realm is a opaque string that the user agent should present
|
|
|
- to the user so he can decide what username and password to use.
|
|
|
- Usually this is domain of the host the server is running on.
|
|
|
- If an empty string "" is used then the server will generate it from
|
|
|
- the request. From header field domain will be used as realm.
|
|
|
- * qop - Value of this parameter can be either "1" or "0". When set to
|
|
|
- 1 then the server will put qop parameter in the challenge. When set
|
|
|
- to 0 then the server will not put qop parameter in the challenge.
|
|
|
- It is strongly recommended to use qop parameter, however there are
|
|
|
- still some user agents that cannot handle qop parameter properly so
|
|
|
- we made this optional. On the other hand there are still some user
|
|
|
- agents that cannot handle request without qop parameter too.
|
|
|
-
|
|
|
- Example 16. proxy_challenge usage
|
|
|
-...
|
|
|
-if (!proxy_authorize("", "subscriber)) {
|
|
|
- proxy_challenge("", "1"); # Realm will be autogenerated
|
|
|
-};
|
|
|
-...
|
|
|
-
|
|
|
-1.4.3. consume_credentials()
|
|
|
+1.4.1. consume_credentials()
|
|
|
|
|
|
This function removes previously authorized credentials from the
|
|
|
message being processed by the server. That means that the downstream
|
|
|
@@ -528,59 +436,9 @@ if (!proxy_authorize("", "subscriber)) {
|
|
|
little bit shorter. The function must be called after www_authorize or
|
|
|
proxy_authorize.
|
|
|
|
|
|
- Example 17. consume_credentials example
|
|
|
+ Example 13. consume_credentials example
|
|
|
...
|
|
|
if (www_authorize("", "subscriber)) {
|
|
|
consume_credentials();
|
|
|
};
|
|
|
...
|
|
|
-
|
|
|
-1.4.4. is_rpid_user_e164()
|
|
|
-
|
|
|
- The function checks if the SIP URI received from the database or radius
|
|
|
- server and will potentially be used in Remote-Party-ID header field
|
|
|
- contains an E164 number (+ followed by up to 15 decimal digits) in its
|
|
|
- user part. Check fails, if no such SIP URI exists (i.e. radius server
|
|
|
- or database didn't provide this information).
|
|
|
-
|
|
|
- Example 18. is_rpid_user_e164 usage
|
|
|
-...
|
|
|
-if (is_rpid_user_e164()) {
|
|
|
- # do something here
|
|
|
-};
|
|
|
-...
|
|
|
-
|
|
|
-1.4.5. append_rpid_hf()
|
|
|
-
|
|
|
- Appends to the message a Remote-Party-ID header that contains header
|
|
|
- 'Remote-Party-ID: ' followed by the saved value of the SIP URI received
|
|
|
- from the database or radius server followed by the value of module
|
|
|
- parameter radius_rpid_suffix. The function does nothing if no saved SIP
|
|
|
- URI exists.
|
|
|
-
|
|
|
- Example 19. append_rpid_hf usage
|
|
|
-...
|
|
|
-append_rpid_hf(); # Append Remote-Party-ID header field
|
|
|
-...
|
|
|
-
|
|
|
-1.4.6. append_rpid_hf(prefix, suffix)
|
|
|
-
|
|
|
- This function is the same as the function described in Section 1.4.5,
|
|
|
- "append_rpid_hf()". The only difference is that it accepts two
|
|
|
- parameters, prefix and suffix to be added to Remote-Party-ID header
|
|
|
- field. This function ignores rpid_prefix and rpid_suffix parameters,
|
|
|
- instead of that allows to set them for every call.
|
|
|
-
|
|
|
- Meaning of the parameters is as follows:
|
|
|
- * prefix - Prefix of the Remote-Party-ID URI. The string will be
|
|
|
- added at the begining of body of the header field, just before the
|
|
|
- URI.
|
|
|
- * suffix - Suffix of the Remote-Party-ID header field. The string
|
|
|
- will be appended at the end of the header field. It can be used to
|
|
|
- set various URI parameters, for example.
|
|
|
-
|
|
|
- Example 20. append_rpid_hf(prefix, suffix) usage
|
|
|
-...
|
|
|
-append_rpid_hf("", ";party=calling;id-type=subscriber;screen=yes"); # Append Re
|
|
|
-mote-Party-ID header field
|
|
|
-...
|
Juha Heinanen