<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1543" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>I am still digging in this cseq uac problem which I
need desperately to solve.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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. </FONT><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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 </FONT><FONT
face=Arial size=2>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.
</FONT><FONT face=Arial size=2>Whatever credentials UAC produces are discarted
by openser.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The scheme:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>1. UAC issues invite which is routed by OS to the
downstream proxy (UAS) - as usual.</FONT></DIV>
<DIV><FONT face=Arial size=2>2. UAS issues challenge 401 or 407 - as
usual</FONT></DIV>
<DIV><FONT face=Arial size=2>3. OS captures challenge on_failure route - as
envisaged by UAC module</FONT></DIV>
<DIV><FONT face=Arial size=2>4. this is new:</FONT></DIV>
<DIV><FONT face=Arial size=2>a) OS relays the challenge upstream to UAC (would
it be necessary to modify it before doing so ?)</FONT></DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2>5. UAC responds with (wrong) proxy_auth
credentials via OS to UAS</FONT></DIV>
<DIV><FONT face=Arial size=2>6. OS discards the credential message it
received from the UAC - to avoid that the message reaches UAS.</FONT></DIV>
<DIV><FONT face=Arial size=2>7. Invite successful or failure : UAS responds with
further messages which are routed to UAC.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Can this scheme work - or am I overlooking
something here ?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>TIA</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Gerry</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></BODY></HTML>