Hi Sebastian,
thanks for further investigation. Indeed, the avps were not backed
up/restored when sending self-generated request.
I just committed a patch to tm module in master branch. If you can give
it a try and report if it works ok, then I will backport to 3.1.
Cheers,
Daniel
On 7/28/11 4:57 PM, Sebastian Damm wrote:
Hi Daniel, Hi Klaus,
after hours of searching I think we found the problem. This is what
our route that actually sends out the packets looks like:
route[2] {
xlog("........................................... START OF
ROUTE 2....................................\n");
xlog("AVP LEG_ID has Value $(avp(s:leg_id))\n");
$(avp(s:dsttype)) = 0;
if ($rd =~ "pstnout") { $(avp(s:dsttype)) = 2; }
if ($rd =~ "media") { $(avp(s:dsttype)) = 1; }
if (isflagset(0)) {
$(avp(s:dsttype)) = 3;
t_on_reply("4");
$uac_req(method)="PDDTRACKING";
$uac_req(ruri)="sip:store@172.20.21.3:5160
<http://sip:store@172.20.21.3:5160>";
$uac_req(furi)="sip:kamai...@sipgate.net
<mailto:sip%3akamai...@sipgate.net>";
$uac_req(hdrs)="Content-Type: text/timetracking-csv\r\n";
pv_printf("$uac_req(body)",
"$ci,$fU,$tU,$TV(Sn),$rm,$rd");
uac_req_send();
}
if ((!defined ($(avp(s:tariffannouncement))) ||
!($(avp(s:tariffannouncement)) == "true")) && method=="INVITE" &&
defined $(avp(s:cid)) && !($(avp(s:cid)) == "")) {
$uac_req(method)="TIMETRACKING";
$uac_req(ruri)="sip:store@172.20.21.3:5160
<http://sip:store@172.20.21.3:5160>";
$uac_req(furi)="sip:kamai...@sipgate.net
<mailto:sip%3akamai...@sipgate.net>";
$uac_req(hdrs)="Content-Type: text/timetracking-csv\r\n";
pv_printf("$uac_req(body)",
"$(avp(s:cid)),$ci,$fU,$tU,$TV(Sn),$(avp(s:dsttype)),$rm,$rd");
uac_req_send();
}
xlog("........................................... AFTER UAC
REQUEST ....................................\n");
xlog("AVP LEG_ID has Value $(avp(s:leg_id))\n");
t_on_reply("ABC");
if (!t_relay()) {
xlog("L_ERR", "route(2): error to <$tu> from <$fu>\n");
if (method=="INVITE" || method=="ACK") {
unforce_rtp_proxy();
}
sl_reply_error();
return;
};
return;
}
I probably need to explain that a little. We have another kamailio
process just for accounting. We do it separately for being independent
of the database in our "routing Kamailio", because there would be the
chance of blocked processes, if the database is too slow, if we did it
in the routing Kamailio.
We try to to measure Post Dial Delay when sending calls out to the
carrier, and we monitor the time differences for one call each time
Kamaiio is passed. That's all the other process does. So we send
handcrafted SIP packages with the needed information with
uac_req_send(). And it looks like the AVPs get lost at that point.
That's what the log says:
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17684]: ERROR: <script>:
........................................... START OF ROUTE
2....................................
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17684]: ERROR: <script>: AVP
LEG_ID has Value 9962182
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17684]: ERROR: <script>:
........................................... AFTER UAC REQUEST
....................................
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17684]: ERROR: <script>: AVP
LEG_ID has Value <null>
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17681]: NOTICE: <script>:
REPLY START
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17681]: NOTICE: <script>:
reply: 100 Trying - F=sip:anonym...@sipgate.de
<mailto:sip%3aanonym...@sipgate.de> T=sip:0211xxxxx...@sipgate.de
<mailto:sip%3a0211xxxxx...@sipgate.de> SRCIP=217.116.120.220:5060
<http://217.116.120.220:5060>
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17681]: NOTICE: <script>: Now
in named reply route...............................................
Jul 28 16:41:35 hagi /usr/sbin/kamailio[17681]: ERROR: <script>: AVP
LEG_ID has Value <null>
If I disable the UAC part of route[2], I get the following output:
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17404]: ERROR: <script>:
........................................... START OF ROUTE
2....................................
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17404]: ERROR: <script>: AVP
LEG_ID has Value 5770077
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17404]: ERROR: <script>:
........................................... AFTER UAC REQUEST
....................................
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17404]: ERROR: <script>: AVP
LEG_ID has Value 5770077
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17403]: NOTICE: <script>:
REPLY START
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17403]: NOTICE: <script>:
reply: 100 Trying - F=sip:anonym...@sipgate.de
<mailto:sip%3aanonym...@sipgate.de> T=sip:0211xxxxxx...@sipgate.de
<mailto:sip%3a0211xxxxxx...@sipgate.de> SRCIP=217.116.120.220:5060
<http://217.116.120.220:5060>
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17403]: NOTICE: <script>: Now
in named reply route...............................................
Jul 28 16:25:20 hagi /usr/sbin/kamailio[17403]: ERROR: <script>: AVP
LEG_ID has Value 5770077
The behavior was different in Kamailio 1.5, and I think using the uac
module shouldn't destroy AVPs.
Am I missing something?
Best regards,
Sebastian
P.S.: Of course, the named onreply_route is executed AFTER the
standard onreply_route. I misinterpreted my logs last week.
On Fri, Jul 15, 2011 at 2:32 PM, Daniel-Constantin Mierla
<mico...@gmail.com <mailto:mico...@gmail.com>> wrote:
Hi Sebastian,
On 7/15/11 11:42 AM, Sebastian Damm wrote:
Hi,
On Fri, Jul 15, 2011 at 9:02 AM, Klaus Darilion
<klaus.mailingli...@pernau.at
<mailto:klaus.mailingli...@pernau.at>> wrote:
The named reply routes are only executed if t_on_reply()
was called for
the request. This reply route will be executed after the
default
reply-route. It is triggered by tm module.
I just inserted a new reply_route, which just prints out some
variables (and does avp_print). From what I see in the logs
now, the
named route is executed before the default reply_route. And
there are
no AVPs in the named route. Actually, I don't even need the
AVPs in
the replies, I need them to be there, when the 200 OK comes in
or in
failure route when the call is cancelled. In both cases the
AVPs are
<null> if i directly address them.
Any more ideas?
I am a bit confused about what you explain above, with "named
route is executed before the default reply_route". Can you send
like the structure of the config for this case? I mean the routes
involved and the calls of t_on_reply(). Is it like for example:
route {
...
$avp(xyz) = 1;
t_on_reply("ABC");
t_relay();
exit;
}
onreply_route[ABC] {
...
xlog("avp(xyz) is $avp(xyz)\n");
...
}
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
--
Dipl.-Inf.
Sebastian Damm - VoIP-Engineer - d...@sipgate.de <mailto:d...@sipgate.de>
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de <http://www.sipgate.de> - www.sipgate.at
<http://www.sipgate.at> - www.sipgate.co.uk <http://www.sipgate.co.uk>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
