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
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
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
Hi,
On Fri, Jul 15, 2011 at 9:02 AM, Klaus Darilion 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?
Best regards, Sebastian
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@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
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@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@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
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
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 OFROUTE 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:5160http://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 UACREQUEST ....................................\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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
thanks for looking into it again.
On Mon, Aug 1, 2011 at 2:51 PM, Daniel-Constantin Mierla miconda@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@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 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=08798a6d...
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@gmail.com mailto:miconda@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:5160http://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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Klaus Darilion -
Sebastian Damm