[OpenSIPS-Devel] New contribution, uac_auth() in request route

[Bogdan-Andrei Iancu]

Hello Michael,

There are several issues here, not sure how you handle them:

1) what if the client is really dummy or does not have support for auth 
at all, so you cannot rely on the UAC to send a second INVITE with 
credentials

2) what if the client  -  server relation is not passwd based, so again 
the UAC cannot generate the INVITE with credentials

3) what if the the UAC is also authenticating to the server :
       UAC   -> INVITE            ->  proxy
       UAC   <- 407 proxy         <-  proxy
       UAC   -> INVITE+res_proxy  ->  proxy
                                      proxy  -> INVITE -> GW
                                      proxy  <- 407 gw <- GW
       UAC   <- 407 gw            <-  proxy

    at this moment the uac may stop responding (as it cannot answer to 
the new request - unknown realm, or because it things the first auth failed)

Regards,
Bogdan

Michael Schloh von Bennewitz wrote:
> Hello Bogdan,
>
> A while ago you posted a suggestion which sounded like more of
> a challenge to provide a workaround for an authentication problem:
>
>   http://lists.opensips.org/pipermail/users/2010-January/010215.html
>
> According to http://www.opensips.org/Development/Development you
> are the maintainer of the UAC module, and so I'd like to offer
> you the results of my work to provide a solution to your challenge.
> I've tested this code with a few different PSTN gateway providers
> which challenge either 401 or 407 and reject messages with constant
> (nonsequential) CSEQs.
>
>   http://scm.europalab.com/contrib/opensips/
>   http://scm.europalab.com/contrib/file/tip/opensips/
>   http://scm.europalab.com/contrib/file/tip/opensips/uac-reauth.txt
>   http://scm.europalab.com/contrib/file/tip/opensips/uac-reauth.diff
>
> Basically, files (only code, no documentation) in modules/uac of
> SVN trunk revision 6590 were modified to allow the function
> uac_auth() of the UAC module to be used in the request route.
> The purpose of this is to allow OpenSIPS to pass a challenge
> response from a dowstream proxy back to the originating UAC
> which increments the CSEQ and resubmits the message (probably
> a INVITE) to OpenSIPS. The resubmittal includes a Authorization
> header which can be overwritten using the new logic of this
> patch. OpenSIPS then forwards the message a second time to
> the downstream proxy which accepts the authorization header.
>
> The code work is complete, but this patch lacks XML documentation.
> I'll complete that work if I get the impression that this is popular
> enough to be committed to the trunk.
>
> Cheers,
> Michael
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro