30 May
2006
30 May
'06
5:19 p.m.
I am still digging in this cseq uac problem which I need desperately to solve.
The problem is that the uac_auth function can create credentials for the downstream proxy
after being challenged with a 401 or 407 message - but the downstream proxy (UAS) refuses
this proxy_auth message since openser does not increase the cseq number. Increasing the
cseq number only downstream wouldnt solve the problem since any replies of the downstream
proxy back to the originating UAC would have cseq numbers which are out of sync.
I propose: In order to keep the cseq numbers in sync upstream and downstream one must
generate challenges and proxy-auth responses on both legs of the route - and not only
respond downstream as currently.
So whenever openser receives from the downstream proxy a challenge it must forward this
challenge the originating UAC (if necessary modify the message in such a way that the UAC
is guaranteed to respond). This upstream challenge causes the originating UAC to increase
the cseq. Naturally openser must also increase the cseq number downstream when generating
its own proxy_auth repsonse to the downstream proxy. Whatever credentials UAC produces are
discarted by openser.
The scheme:
1. UAC issues invite which is routed by OS to the downstream proxy (UAS) - as usual.
2. UAS issues challenge 401 or 407 - as usual
3. OS captures challenge on_failure route - as envisaged by UAC module
4. this is new:
a) OS relays the challenge upstream to UAC (would it be necessary to modify it before
doing so ?)
b) OS constructs with uac_auth function correct proxy_auth credentials for UAS, increases
the cseq with some text manipulation function and replies to UAS.
5. UAC responds with (wrong) proxy_auth credentials via OS to UAS
6. OS discards the credential message it received from the UAC - to avoid that the message
reaches UAS.
7. Invite successful or failure : UAS responds with further messages which are routed to
UAC.
Can this scheme work - or am I overlooking something here ?
TIA
Gerry
31 May
31 May
12:40 p.m.
Hi Gerry,
there are couple of problems with this approach:
1) you presume that the UAC phone supports authentication, but uac
module is intended to be used also in front of devices that are not able
to do auth.
2) there is no standard recipe that guarantee that the UAC phone will
actually resend and INVITE to a fake authentication challenge - even if
you mangle the user and domain in challenge, some phones do not try
again if already failed with same credentials.
3) the dialog may be brake - you close the dialog with the UAC for the
original INVITE, force it to generate a new one (via challenge), but on
the UAS side there is only one dialog matching the first on UAC side -
so when the UAS sends 200 OK (based on first dialog), it may to match
the second dialog (on UAC side) - there is no guarantee that both
dialogs will have same ftag or even that the callid is preserved.
maybe a simpler solution will be to increase the cseq on UAS side, allow
the transaction to be completed (as you are transaction stateful,
keeping cseq consistency is not difficult). AFter that, either send an
re-INVITE or NOTIFY within the dialog only on UAC side to increase its
CSEQ also and to get rid of dialog synchronization.
but, that should work in theory...practice is a different thing ;)
regards,
bogdan
G.Jacobsen wrote:
I am still digging in this cseq uac problem which I
need desperately
to solve.
The problem is that the uac_auth function can create credentials for
the downstream proxy after being challenged with a 401 or 407 message
- but the downstream proxy (UAS) refuses this proxy_auth message since
openser does not increase the cseq number. Increasing the cseq number
only downstream wouldnt solve the problem since any replies of the
downstream proxy back to the originating UAC would have cseq numbers
which are out of sync.
I propose: In order to keep the cseq numbers in sync upstream and
downstream one must generate challenges and proxy-auth responses on
both legs of the route - and not only respond downstream as currently.
So whenever openser receives from the downstream proxy a challenge it
must forward this challenge the originating UAC (if necessary
modify the message in such a way that the UAC is
guaranteed to respond). This upstream challenge causes the
originating UAC to increase the cseq. Naturally openser must also
increase the cseq number downstream when generating its own
proxy_auth repsonse to the downstream proxy. Whatever credentials UAC
produces are discarted by openser.
The scheme:
1. UAC issues invite which is routed by OS to the downstream proxy
(UAS) - as usual.
2. UAS issues challenge 401 or 407 - as usual
3. OS captures challenge on_failure route - as envisaged by UAC module
4. this is new:
a) OS relays the challenge upstream to UAC (would it be necessary to
modify it before doing so ?)
b) OS constructs with uac_auth function correct proxy_auth
credentials for UAS, increases the cseq with some text manipulation
function and replies to UAS.
5. UAC responds with (wrong) proxy_auth credentials via OS to UAS
6. OS discards the credential message it received from the UAC - to
avoid that the message reaches UAS.
7. Invite successful or failure : UAS responds with further messages
which are routed to UAC.
Can this scheme work - or am I overlooking something here ?
TIA
Gerry
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6753
days inactive
6754
days old
1 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
G.Jacobsen