[Serusers] UAC module (backport to 0.9.0)
Michael Ulitskiy
mdu113 at acedsl.com
Tue May 24 17:36:20 CEST 2005
It's in this thread in my post from 05/16.
Also, yesterday, I posted it to serdev.
Michael
On Tuesday 24 May 2005 09:00 am, you wrote:
> Would u please send me link for that patch?
>
> Thanks,
> Mohammad
>
>
> Michael Ulitskiy wrote:
>
> >It works with above-posted patch and with limitations stated in the docs
> >as Daniel pointed out.
> >You won't be able to authenticate to RFC-compliant implementations.
> >
> >Michael
> >
> >On Monday 23 May 2005 12:05 pm, info at beeplove.com wrote:
> >
> >
> >>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 at acedsl.com
> >>Date: Mon, 23 May 2005 12:01:40 -0400
> >>To: daniel at voice-system.ro, serusers at lists.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 at lists.iptel.org
> >>>>http://lists.iptel.org/mailman/listinfo/serusers
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>_______________________________________________
> >>Serusers mailing list
> >>serusers at lists.iptel.org
> >>http://lists.iptel.org/mailman/listinfo/serusers
> >>
> >>--------------------------------------------------------------------
> >>mail2web - Check your email from the web at
> >>http://mail2web.com/ .
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
More information about the sr-users
mailing list