New subject: [Serusers] UAC module (backport to 0.9.0)

23 May 2005

Does this module work on ser-0.9.0?
Or, was you guys able to make it work on ser-0.9.0

If you were able to make it worked, would you please share the tricks,

Thanks,
Mohammad

Original Message:
-----------------
From: Michael Ulitskiy mdu113(a)acedsl.com
Date: Mon, 23 May 2005 12:01:40 -0400
To: daniel(a)voice-system.ro, serusers(a)iptel.org
Subject: Re: [Serusers] UAC module (backport to 0.9.0)

On Sunday 22 May 2005 04:51 am, Daniel-Constantin Mierla wrote:
...
  Hello,

 the issue with CSeq is known and it is stated in the documentation (see 
 the note there):

 http://www.voice-system.ro/docs/uac/ar01s04.html#uac_auth 
Thanks. Actually I read that docs, but somehow overlooked that note.
Thanks for pointing it out.

...
  Daniel 
Michael

...

 On 05/16/05 22:05, Michael Ulitskiy wrote:

 >Hello,
 >
 >I succeeded to make UAC module calculate credentials and
 >resend message with the following simple patch on t_reply.c
 >of tm module:
 >
 >--- t_reply.c.bak       2005-05-13 14:57:25.000000000 -0400
 >+++ t_reply.c   2005-05-13 15:16:45.000000000 -0400
 >@@ -761,6 +761,10 @@
 >                   a callback; save branch count to be able to determine
 >                   later if new branches were initiated */
 >                branch_cnt=Trans->nr_of_outgoings;
 >+               /* also append the current reply to the transaction to
 >+                 * make it available in failure routes - a kind of
"fake"
...
  >+                 * save of the final reply per
branch */
 >+                Trans->uac[branch].reply = reply;
 >
 >                /* run ON_FAILURE handlers ( route and callbacks) */
 >                if ( has_tran_tmcbs( Trans,
TMCB_ON_FAILURE_RO|TMCB_ON_FAILURE)
...
  >@@ -769,6 +773,11 @@
 >                               
picked_branch==branch?reply:Trans->uac[picked_branch].reply,
...
  >                                picked_code);
 >                }
 >+
 >+               /* now reset it; after the failure logic, the reply may
 >+                * not be stored any more and we don't want to keep into
 >+                * transaction some broken reference */
 >+               Trans->uac[branch].reply = 0;
 >
 >                /* look if the callback perhaps replied transaction; it also
...
  >                   covers the case in which a
transaction is replied localy
...
  >
 >It's actually taken from cvs-head.
 >Now ser.cfg written below works as expected with just one
 >important issue. Authentication doesn't work anyway because
 >ser doesn't increase CSeq number when resending message
 >(INVITE) with credentials. I'm trying to authenticate
 >to asterisk and in case of asterisk it immediately replies 
 >"503 Service Unavailable" if it receives INVITE with the same CSeq.
 >I thought it could be asterisk-specific problem, but RFC3261 in
 >section "8.1.3.5 Processing 4xx Responses" says:
 >"new request constitutes a new transaction and SHOULD have the same 
 >value of the Call-ID, To, and From of the previous request, but the CSeq 
 >should contain a new sequence number that is one higher than the
previous."
...
  >So I guess this is not an asterisk-specific. 
 >It is my understanding that in order for this to work ser must increment 
 >CSeq when authenticating to UAS, but decrement CSeq in all subsequent 
 >in-dialog messages that will be sent to call originator including BYEs. 
 >This, in turn, requires for ser to be call-statefull which is not the case. 
...
  >Conclusion: uac authentication in ser is not
possible.
 >Please correct me if I'm wrong (I honestly want to be wrong on this
matter:))
...
  >Thank you,
 >
 >Michael
 >
 >On Sunday 15 May 2005 12:36 am, you wrote:
 >  
 >
 >>Michael Ulitskiy wrote:
 >>
 >>    
 >>
 >>>Hello,
 >>>
 >>>Has anyone succeeded in getting UAC authentication to work?
 >>>I'm doing the following:
 >>>
 >>>route {
 >>>       resetflag(1);
 >>>       t_on_failure("1");
 >>>       route(1);
 >>>}
 >>>
 >>>route[1]
 >>>{
 >>>       if
(uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)") {
...
  >>>           sl_send_reply("479",
"We don't forward to private IP addresses");
...

break;
       };
       if (!t_relay()) {
               sl_reply_error();
       };
}

failure_route[1] {
       # authentication reply received?
       if ( t_check_status("401|407") ) {
               if (!isflagset(1) && uac_auth()) {
                       setflag(1);
                       t_on_failure("1");
                       append_branch();
                       route(1);
               } else {
                       t_reply("500","Error occurred");
               }
               break;
       }

}

When uac_auth() is called I get the following in the:
0(28973) DEBUG:uac:uac_auth: picked reply is (nil), code 407
0(28973) BUG:uac:uac_auth: empty reply on picked branch

Any suggestions or ideas?
Thank  you,

Michael

 I am also getting same thing with different msg ..
BUG:uac:uac_auth: empty reply on picked branch

Anybody know how to overcome this?

Mohammad

_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serusers

_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serusers

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .