Custom Query (2195 matches)

Problem description:

In the old registration sequence, we sent a first REGISTER request without Authorization header that was challenged with a nonce and a second REGISTER request with username and response.

However in IMS, the server is unable to send the right nonce as long as it does not have received the private identity in the username. So the second REGISTER is rejected again with a new nonce.

With the pjsip_auth_clt_pref stucture, we can configure the initial REGISTER to contain an empty Authorization header, with just a realm, username and uri. This way the server can challenge it with the right nonce as it know the username and the second REGISTER request can succeed.

However, this sequence force the user to know the realm in advance as the ‘*’ wildcard can not be used here. This complicates the provisioning and is source of more problems of support.

Basic Idea:

One way to prevent the provisioning of this realm:

• Send a first REGISTER request without Authorization header
• Receive back the realm and a provisional nonce
• Send a second REGISTER request with Authorization header, filled with the username, realm, response, etc
• Receive back the realm and the definitive nonce associated with the username
• Send a third REGISTER request with Authorization header, filled with the username, realm, final response, etc

Proposed solution:

We can add support to putting wildcard ("*") for IMS, which will activate three stage auth as explained above. So when sending empty Authorization setting is set and when the realm is wildcard, the auth framework will do the three stage auth as above.

Drawback:

With above, authentication for all requests will use three stage authentication, which will increase message round-trips. However this is deemed acceptable as it happens only when application specifies wild-card as the realm.

gcc-4.2.1, arm926ej-s, Linux-2.6.23

Crash on pjmedia_wsola_create() function, specificly in the fixed-point version of create_win() function. The symptom is the "i" variable value in the "for(i=0; i<count; ++i)" loop goes beyond the range and possibly writes data to some random memory location, causing the segmentation fault.

The segfault occurs when the library is compiled with -O2/-O3 (and possibly higher). It does not happen when the optimization is turned off. So we suspect that this is due to some gcc optimization bug.

The workaround that we used now is to force WSOLA to use linear window when floating point is disabled. If you wish to disable this workaround, declare this in your config_site.h:

 #define PJMEDIA_WSOLA_LINEAR_WIN  0

Assertion is triggered when 200/OK is received with strict Record-Route, while the original INVITE request doesn't contain the corresponding Route request.

Please see attachment for the log.