[Devel] Re: patch uac_auth cseq - however still problems ...

[Bogdan-Andrei Iancu]

Hi Gerry,

not tried but you may increment the cseq by script with existing functions:
    - avp_write -> get the whole cseq body
    - avp_subst -> extract only the number part
    - avp_copy -> cast the string value to int value
    - avp_op -> increment the int value
    - avp_printf -> compose the new cseq body
    - remove_hf -> delete old cseq header
    - append_hf -> add new cseq hdr with new body.

complex isn't it :D ?

on the other hand, just increasing the cseq in the INVITE does not solve 
the problem since cseq is dialog persistent - so all sequential messages 
needs to be adjusted.

regards,
bogdan

G.Jacobsen wrote:

>Bogdan,
>
>thanks a lot for your comments regarding the cseq, UAC_authentication
>problem.
>
>Since I couldnt find any way to increment the CSeq Value via script language
>I have patched textops.c of Openser 1.0.1 and introduced a new function
>inc_cseq_val() in the textops module with no parameters. The Textops module
>might not be the most suitable place for this function but appeared to me
>the best place not to mess things up - given my coding skills and lack of
>insight
>into openser internals. If someone could have a look over this patch I would
>be most grateful.
>
>You wrote:
>
>  
>
>>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.
>>    
>>
>
>Unfortunately I did not understand you correctly here. As far
>as I understand, the transaction (INVITE) is only completed when the remote
>party has picked up the call. So any 100 or 180 ringing messages from the
>UAS would have to be relayed to the UAC with the "wrong" CSeq number - or be
>manipulated down again. Any cancel message of the UAC would fail with the
>UAS due to the wrong CSeq number. Or did you mean I should issue a RE-INVITE
>to the UAS after the UAC gives me back the first 100 trying or ringing 180
>after the successful authentication ?
>
>Secondly, I do not understand how OS can generate a RE-INVITE or NOTIFY by
>itself by script language ?
>
>I thought that there is an other way for me: I need to authenticate all UAC
>against my OS anyway on each INVITE (Causing a CSeq number of minimum 2
>after
>authentication (if UAS are RFC compliant). So in the second INVITE from the
>UAC  (which passed with the credentials for OS) I could theoretically
>DEcrease the CSeq value when relaying it on the
>downstream leg to the UAS, and INcrease again the CSeq when answering the
>407 challenge from the downstream UAC. After that both CSeq legs would be in
>sync again.
>
>However as I had to discover a problem with this approach - openser sends
>the ACK to the UAS challenge with NOT decreased CSeq number (although the
>UAS challenge comes back with the decreased CSeq number). I suppose OS is
>"too clever" here and caches the the old CSeq value and ignores the CSeq
>number of the UAS challenge. Also other wierd things were happening in later
>messages. I guess the module gets utterly confused by a decreased CSeq.
>
>
>I would be most grateful if you could clarify what you meant.
>
>TIA
>
>Gerry
>
>
>patch attached
>
>----- Original Message ----- 
>From: "Bogdan-Andrei Iancu" <bogdan at voice-system.ro>
>To: "G.Jacobsen" <g_jacobsen at yahoo.co.uk>
>Cc: <users at openser.org>
>Sent: Wednesday, May 31, 2006 12:40 PM
>Subject: [Bulk] Re: [Users] Can this work?: re. uac_auth cseq problem
>
>
>  
>
>>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
>>>
>>>      
>>>