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

Daniel

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 > >

>+ * save of the final reply per branch */ >+ Trans->uac[branch].reply = reply; > > /* run ON_FAILURE handlers ( route and callbacks) */ > if ( has_tran_tmcbs( Trans, > >

>@@ -769,6 +773,11 @@ > > >

> 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 > >

> covers the case in which a transaction is replied > >

>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 > >

>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 > >

>Conclusion: uac authentication in ser is not possible. >Please correct me if I'm wrong (I honestly want to be wrong on this > >

>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 >>> >>>

>>> 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)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > > > > >