[SR-Users] AVPs missing in onreply_route

Sebastian Damm damm at sipgate.de
Thu Jul 28 16:57:43 CEST 2011 

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";
                $uac_req(furi)="sip:kamailio 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";
                $uac_req(furi)="sip:kamailio 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 T=sip:0211XXXXXXXX at 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 at sipgate.de T=sip:0211XXXXXXXXX at 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 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>  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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110728/094940a1/attachment.htm>

More information about the sr-users mailing list