[SR-Users] AVPs missing in onreply_route
Daniel-Constantin Mierla
miconda at gmail.com
Mon Aug 1 14:51:13 CEST 2011
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 at 172.20.21.3:5160
> <http://sip:store@172.20.21.3:5160>";
> $uac_req(furi)="sip:kamailio at sipgate.net
> <mailto:sip%3Akamailio at 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 at 172.20.21.3:5160
> <http://sip:store@172.20.21.3:5160>";
> $uac_req(furi)="sip:kamailio at sipgate.net
> <mailto:sip%3Akamailio at 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 at sipgate.de
> <mailto:sip%3Aanonymous at sipgate.de> T=sip:0211XXXXXXXX at sipgate.de
> <mailto:sip%3A0211XXXXXXXX at 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 at sipgate.de
> <mailto:sip%3Aanonymous at sipgate.de> T=sip:0211XXXXXXXXX at sipgate.de
> <mailto:sip%3A0211XXXXXXXXX at 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 at gmail.com <mailto:miconda at 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 at pernau.at
> <mailto:klaus.mailinglists at 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 at sipgate.de <mailto:damm at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110801/6472cd91/attachment.htm>
More information about the sr-users
mailing list