16 May
2005
16 May
'05
3:05 p.m.
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