14 Jul
2011
14 Jul
'11
8:01 p.m.
Hi,
I'm still fighting problems in our Kamailio 1.5 to 3.1 migration. Right now
I'm stuck with a strange behavior of AVPs in my dialplan.
I set a lot of AVPs for accounting in the route directive, and I just
inserted an avp_print() statement right before t_relay() is called, all
values are set. Then I call avp_print() as the first statement of
onreply_route(), and it doesn't print out anything. I call it again at the
end of onreply_route, and the only AVP printed out is the one I set directly
there.
In 1.5 there was an option in the tm module to control AVP behavior in
replies, but that doesn't exist anymore, I even found a mailing list post
from Daniel where he explained that all AVPs I set in route are also
available in onreply_route.
Am I doing something wrong? Is there still a secret option that I
accidentally turned on? What else could make kamailio forget all AVPs after
t_relay? I tried both version 3.1.3 and 3.1.4.
Any help appreciated.
Best regards,
Sebastian
14 Jul
14 Jul
9:10 p.m.
Hi Sebastian,
On 7/14/11 7:01 PM, Sebastian Damm wrote:
Hi,
I'm still fighting problems in our Kamailio 1.5 to 3.1 migration.
Right now I'm stuck with a strange behavior of AVPs in my dialplan.
I set a lot of AVPs for accounting in the route directive, and I just
inserted an avp_print() statement right before t_relay() is called,
all values are set. Then I call avp_print() as the first statement of
onreply_route(), and it doesn't print out anything. I call it again at
the end of onreply_route, and the only AVP printed out is the one I
set directly there.
In 1.5 there was an option in the tm module to control AVP behavior in
replies, but that doesn't exist anymore, I even found a mailing list
post from Daniel where he explained that all AVPs I set in route are
also available in onreply_route.
Am I doing something wrong? Is there still a secret option that I
accidentally turned on? What else could make kamailio forget all AVPs
after t_relay? I tried both version 3.1.3 and 3.1.4.
the avps should be available in tm onreply_route. Just to double check,
you are not accessing them in the default onreply_route?
Can you try to see if xlog prints the value of the avps? Like:
xlog("=== myavp is: $avp(myavp)\n");
I will test, but if you are faster I want to see if the issue is in
avp_print() or not.
Thanks,
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
15 Jul
15 Jul
10:02 a.m.
Am 14.07.2011 20:10, schrieb Daniel-Constantin Mierla:
In 1.5 there was an option in the tm module to control
AVP behavior in
replies, but that doesn't exist anymore, I even found a mailing list
post from Daniel where he explained that all AVPs I set in route are
also available in onreply_route.
As Daniel said, the default on_reply route (without name) is executed
for every response - stateless or statefull.
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.
As AVPs are stored in the transaction, the AVPs are only available in
named reply routes.
regards
Klaus
12:42 p.m.
Hi,
On Fri, Jul 15, 2011 at 9:02 AM, Klaus Darilion
<klaus.mailinglists(a)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?
Best regards,
Sebastian
3:32 p.m.
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.mailinglists(a)pernau.at> wrote:
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
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?
28 Jul
28 Jul
5:57 p.m.
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";
$uac_req(furi)="sip:kamailio@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";
$uac_req(furi)="sip:kamailio@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:anonymous@sipgate.de T=sip:0211XXXXXXXX@sipgate.de SRCIP=
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:anonymous@sipgate.de T=sip:0211XXXXXXXXX@sipgate.de SRCIP=
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 <miconda(a)gmail.com
wrote:
Hi Sebastian,
On 7/15/11 11:42 AM, Sebastian Damm wrote:
--
Dipl.-Inf.
Sebastian Damm - VoIP-Engineer - damm(a)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 - www.sipgate.at - www.sipgate.co.uk
Hi,
On Fri, Jul 15, 2011 at 9:02 AM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
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
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?
6:02 p.m.
Am 28.07.2011 16:57, schrieb Sebastian Damm:
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.
IIR I had similar issues when implementing the pua_dialoginfo module,
which internally creates a PUBLISH request while processing the INVITE.
There were also issues that AVPs were affected, but I can't remember the
details.
regards
Klaus
1 Aug
1 Aug
3:51 p.m.
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:kamailio@sipgate.net
<mailto:sip%3Akamailio@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:kamailio@sipgate.net
<mailto:sip%3Akamailio@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:anonymous@sipgate.de
<mailto:sip%3Aanonymous@sipgate.de> T=sip:0211XXXXXXXX@sipgate.de
<mailto:sip%3A0211XXXXXXXX@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:anonymous@sipgate.de
<mailto:sip%3Aanonymous@sipgate.de> T=sip:0211XXXXXXXXX@sipgate.de
<mailto:sip%3A0211XXXXXXXXX@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
<miconda(a)gmail.com <mailto:miconda@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.mailinglists(a)pernau.at
<mailto:klaus.mailinglists@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 - damm(a)sipgate.de <mailto:damm@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(a)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
2 Aug
2 Aug
10:32 a.m.
Hi Daniel,
thanks for looking into it again.
On Mon, Aug 1, 2011 at 2:51 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
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.
OK, I took a default config, added this uac part in RELAY route:
xlog("BEFORE UAC: avp(s:testavp) = $avp(s:testavp)\n");
avp_print();
$uac_req(method)="SPAM";
$uac_req(ruri)="sip:store@127.0.0.1:5160";
$uac_req(furi)="sip:kamailio@sipgate.net";
$uac_req(hdrs)="Content-Type: text/csv\r\n";
$uac_req(body)="foo bar baz";
uac_req_send();
xlog("AFTER UAC: avp(s:testavp) = $avp(s:testavp)\n");
avp_print();
And with an unpatched 3.1.4 looks like this:
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: ERROR: <script>: BEFORE
UAC: avp(s:testavp) = ThisIsJustATest
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f7c0c0e95e8, flags=0x0113
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: ERROR: <script>: AFTER UAC:
avp(s:testavp) = <null>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20379]: ERROR: <script>: DEFAULT
REPLY ROUTE: avp(s:testavp) = <null>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20380]: ERROR: <script>: REPLY
ROUTE REPLY_ONE: avp(s:testavp) = <null>
Aug 2 09:09:13 flake /usr/sbin/kamailio[20379]: ERROR: <script>: FAILURE
ROUTE FAIL_ONE: avp(s:testavp) = <null>
Then I installed the nightly build (Ubuntu Lucid), and tried that again:
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: ERROR: <script>: BEFORE
UAC: avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: ERROR: <script>: AFTER UAC:
avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22675]: ERROR: <script>: DEFAULT
REPLY ROUTE: avp(s:testavp) = <null>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: ERROR: <script>: REPLY
ROUTE REPLY_ONE: avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: ERROR: <script>: FAILURE
ROUTE FAIL_ONE: avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Looks exactly as expected. Thanks! I think you can go ahead and
backport it to 3.1.
Best Regards,
Sebastian
--
Dipl.-Inf.
Sebastian Damm - VoIP-Engineer - damm(a)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 - www.sipgate.at - www.sipgate.co.uk
4 Aug
4 Aug
12:57 p.m.
Hi Sebastian,
thanks for reporting back the results. On a second thought I updated the
patch a bit to use a local variable for backup in order to allow nested
execution of event_route[tm:local-request] which can be triggered by
sending local generated requests. The commit was:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=08798a6…
I will backport to 3.1 soon.
Cheers.
Daniel
On 8/2/11 9:32 AM, Sebastian Damm wrote:
Hi Daniel,
thanks for looking into it again.
On Mon, Aug 1, 2011 at 2:51 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
--
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
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.
OK, I took a default config, added this uac part in RELAY route:
xlog("BEFORE UAC: avp(s:testavp) = $avp(s:testavp)\n");
avp_print();
$uac_req(method)="SPAM";
$uac_req(ruri)="sip:store@127.0.0.1:5160
<http://sip:store@127.0.0.1:5160>";
$uac_req(furi)="sip:kamailio@sipgate.net
<mailto:sip%3Akamailio@sipgate.net>";
$uac_req(hdrs)="Content-Type: text/csv\r\n";
$uac_req(body)="foo bar baz";
uac_req_send();
xlog("AFTER UAC: avp(s:testavp) = $avp(s:testavp)\n");
avp_print();
And with an unpatched 3.1.4 looks like this:
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: ERROR: <script>:
BEFORE UAC: avp(s:testavp) = ThisIsJustATest
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f7c0c0e95e8, flags=0x0113
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20378]: ERROR: <script>:
AFTER UAC: avp(s:testavp) = <null>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20379]: ERROR: <script>:
DEFAULT REPLY ROUTE: avp(s:testavp) = <null>
Aug 2 09:09:10 flake /usr/sbin/kamailio[20380]: ERROR: <script>:
REPLY ROUTE REPLY_ONE: avp(s:testavp) = <null>
Aug 2 09:09:13 flake /usr/sbin/kamailio[20379]: ERROR: <script>:
FAILURE ROUTE FAIL_ONE: avp(s:testavp) = <null>
Then I installed the nightly build (Ubuntu Lucid), and tried that again:
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: ERROR: <script>:
BEFORE UAC: avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: ERROR: <script>:
AFTER UAC: avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22675]: ERROR: <script>:
DEFAULT REPLY ROUTE: avp(s:testavp) = <null>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: ERROR: <script>:
REPLY ROUTE REPLY_ONE: avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:52 flake /usr/sbin/kamailio[22674]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: ERROR: <script>:
FAILURE ROUTE FAIL_ONE: avp(s:testavp) = ThisIsJustATest
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1328]: p=0x7f04261307f8, flags=0x0113
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1332]: #011#011#011name=<testavp>
Aug 2 09:26:54 flake /usr/sbin/kamailio[22676]: INFO: avpops
[avpops_impl.c:1340]: #011#011#011val_str=<ThisIsJustATest / 15>
Looks exactly as expected. Thanks! I think you can go ahead and
backport it to 3.1.
Best Regards,
Sebastian
--
Dipl.-Inf.
Sebastian Damm - VoIP-Engineer - damm(a)sipgate.de <mailto:damm@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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4859
days inactive
4880
days old
9 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Klaus Darilion -
Sebastian Damm